Re: Reducing the footprint of a simple application

Jakob Bohm via openssl-users <openssl-users@xxxxxxxxxxx> · Tue, 14 Sep 2021 11:58:49 +0200



    Hi fellow sufferer,

    
    I used to do a lot of manual patching of OpenSSL 1.0.x to remove
      the insane object interdependencies (such as objects named
      foolib.c being nexus points that bring in tonnes of irrelevant
      code because someone was too unfamiliar with basic library
      concepts to make an actual library instead of a monolithic file).
    However the rush to repeatedly rewrite and deprecate everything
      after the new people joined the OpenSSL project made maintaining
      the needed patches too time consuming.

    
    Some day, I will have to start over turning the 3.0.x code into
      an actual library while removing linker mishandling, low security
      RNGs and other antifeatures.

    
    On 2021-09-12 19:34, Reinier Torenbeek wrote:

    
      Hi,

        
        I have a simple application that uses OpenSSL 3.0.0 for
          AES-GCM encryption and decryption only. Looking at the size of
          the binary on disc, I see it's a few KBs when linking
          dynamically with libcrypto, and  4.8 MB when linking
          statically. Although I know the large footprint of OpenSSL is
          considered "a fact of life", this seems excessive. From
          experience with other crypto implementations, I know that the
          *actual* crypto functionality that I am using can fit in 10s
          of KBs and I
          would like to understand the reasons for OpenSSL's size
          better. I am on Linux, 64 bits, using gcc 9.3.0.
        

        Some analysis of the binary reveals (not surprisingly) that
          it contains many OpenSSL symbols that have nothing to do with
          the functionality that I am using. Those seem to get pulled in
          because objects get linked in as a whole and apparently the
          layout of the object contents are such that the symbols needed
          for my functionality are spread out over many different
          objects.
        

        It was my hope that I could mitigate this by compiling
          OpenSSL and my application with the flags -ffunction-sections,
          -fdata-sections, -Os and -flto and using --gc-sections and
          -flto when linking. (See 3.10 Options That Control
            Optimization of GCC's documentation).  This did reduce
          the binary size by 2 MB, leaving me with almost 3 MB. Almost
          90% of that was in the text section and a bit over 10% in the
          data section. I do not have sufficient experience with these
          options to assess how well the optimizations worked in this
          case, I think the resulting binary is still pretty large.
        

        I have not tried disabling any of the features when
          building OpenSSL. I suspect that may help a little bit because
          it may result in a decrease in size of (some) objects, but I
          have seen people reporting disappointing results of
          that on the web. Also, it does not seem to be a workable
          approach in general to have to figure out which build options
          to use and to have to rebuild OpenSSL for every type of
          application that I create.
        

        Did any people here try similar things, with better
          results? Does anybody have any other suggestions as to what I
          could try? And what is the explanation (or justification) for
          this excessive footprint?
        

        Thanks,
        Reinier
      
    
    Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded