<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi fellow sufferer,<br>
</p>
<p>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).</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
On 2021-09-12 19:34, Reinier Torenbeek wrote:<br>
<blockquote type="cite"
cite="mid:CAEdtfJv2RhMuRmdrO-kZ-Nr4PhgHc=AFkJbuDL=sMGDcOrhVqQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">Hi,<br>
<div><br>
</div>
<div>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<span class="gmail-Apple-converted-space"> </span>and I
would like to understand the reasons for OpenSSL's size
better. I am on Linux, 64 bits, using gcc 9.3.0.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 <a
href="https://gcc.gnu.org/onlinedocs/gcc-9.4.0/gcc/Optimize-Options.html#Optimize-Options"
moz-do-not-send="true">3.10 Options That Control
Optimization</a> 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Reinier</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
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</pre>
</body>
</html>