Reducing the footprint of a simple application

[Jakob Bohm]

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 KBsand 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 
> <https://gcc.gnu.org/onlinedocs/gcc-9.4.0/gcc/Optimize-Options.html#Optimize-Options> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210914/b83dd3c3/attachment-0001.html>