[Bug 2058017] [NEW] openssl is not LTO-safe

[Adrien Nader]

Public bug reported:

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.

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)
- 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.

** Affects: openssl (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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 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.

  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)
  - 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+subscriptions