** Description changed:
tl;dr: since it's too much work to make openssl LTO-safe, upstream
doesn't see it as a goal and doesn't test it, and there are probably no
performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing
rules in mind. There are several reports of issues related to LTO. The
openssl technical commitee says "currently we're not going to fix all
the strict aliasing and other LTO problems" and "Fixes raised in pull
requests will be considered."; in other words: if you find a violation,
we'll merge your fixes but we're not going to dedicate time to fixing
them ourselves.
- We don't have specific reports on launchpad at the moment but but we
- cannot rule out that we're already experiencing miscompilations and
- compilers are only pushing this further and further. This is impossible
- to know in advance and even security updates could trigger issues.
+ We don't have specific reports on launchpad at the moment but there has
+ been at least one issue experienced by the FIPS: the compiler decided a
+ 0-filled array could be removed and proceeded to do so. In addition to
+ that, compilers are only pushing this further and further. Issues are
+ impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this
at
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
:
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
strict-aliasing. I don't plan to do the same at least at the moment and
for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- - crypto algorithms are implemented in ASM (funnily, using C implementations
can trigger issues because these can get miscompiled)
+ - crypto algorithms are implemented in ASM (funnily, using C implementations
can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because
source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to
algorithmic/architectural issues, not micro-optimizations and these wouldn't be
noticed
- if LTO-compliance was doable and thought to be useful by upstream, they
would have certainly pushed that forward, especially in the wake of openssl
3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets
17% larger. The corresponding .deb file increases by 2.6% only.
+
+ I will add results of "openssl speed" soon (in a few hours).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/2058017
Title:
openssl is not LTO-safe
Status in openssl package in Ubuntu:
New
Bug description:
tl;dr: since it's too much work to make openssl LTO-safe, upstream
doesn't see it as a goal and doesn't test it, and there are probably
no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with
aliasing rules in mind. There are several reports of issues related to
LTO. The openssl technical commitee says "currently we're not going to
fix all the strict aliasing and other LTO problems" and "Fixes raised
in pull requests will be considered."; in other words: if you find a
violation, we'll merge your fixes but we're not going to dedicate time
to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there
has been at least one issue experienced by the FIPS: the compiler
decided a 0-filled array could be removed and proceeded to do so. In
addition to that, compilers are only pushing this further and further.
Issues are impossible to predict and even security updates could
trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this
at
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
:
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
strict-aliasing. I don't plan to do the same at least at the moment
and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at a
