Removed ~ubuntu-sponsors for a few days while a few things settle.

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.

  openssl: backport to jammy "clear method store / query cache

Status in openssl package in Ubuntu:
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  This bug is part of a series of four bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 

  This SRU addresses four issues with Jammy's openssl version:
  - Blowfish OFB/CFB decryption
  - ignored SMIME signature errors
  - imbca engine dumps core
  - very high CPU usage for concurrent TLS connections

  The SRU information has been added to the four bug reports and I am
  attaching the debdiff here only for all four.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  The patch related to blowfish presents an annoying situation: jammy's openssl 
creates incompatible files and cannot read other files but fixing it will lead 
to files created on jammy so far to become unreadable. Fortunately, blowfish is 
long-deprecated and applications can be improved to handle this situation if 
the need arises in practice.
  This is stated in the SRU information in the bug and in d/changelog.
  The current situation in Jammy could be a security issue but due to the 
aforementioned deprecation, the low usage of blowfish and the fact that 
upstream didn't consider this worthy of a security notice, we (this includes 
the security team) chose not to pursue that path either.

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 

  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in with
  Using this, I get the following numbers on my laptop:

      real  2m5.567s
      user  4m3.948s
      sys   2m0.233s

  this SRU:
      real  0m23.966s
      user  2m35.687s
      sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. Results on a given machine vary also very little across
  runs (less than 2% variation on runs of size 10). They are also very
  similar on a Raspberry Pi 4 (8GB).

  The benchmark uses which takes
  around 130ms to download on my machine but I modified the script to
  download something only 20ms away. Results are so close to the ones
  using humans.txt that they are within the error margin. This is
  consistent with the high-concurrency in the benchmark which both
  saturates CPU, and "hides" latencies that are relatively low.

  Finally, there are positive reports on github. Unfortunately they are
  not always completely targeted at these patches only and therefore I
  will not link directly to them but they have also been encouraging.

  [Where problems could occur]
  The change is spread over several patches which touch the internals of 
openssl. As such, the engine and provider functionality could be broken by 
these changes. Fortunately, in addition to upstream's code review, these 
patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue 
related to these changes was reported on launchpad or upstream.

  However, it is possible that there were more patch dependencies than
  these in either 3.0.3 or 3.0.4. In that case there could be problems.

  The patches come directly from upstream and apply cleanly.


  === Original description ===

  This is about SRU'ing to Jammy the patches at
  . They're purely performance but their impact is large. They have been
  released as part of openssl 3.0.4 (they're among the first after
  3.0.3) which has been included in Kinetic.

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to