[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
This bug was fixed in the package openssl - 3.0.2-0ubuntu1.13 --- openssl (3.0.2-0ubuntu1.13) jammy; urgency=medium * Fix (upstream): crash when using an engine for ciphers used by DRBG (LP: #2023545) - lp2023545/0001-Release-the-drbg-in-the-global-default-context-befor.patch * Fix (upstream): do not ignore return values for S/MIME signature (LP: #1994165) - lp1994165/0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch * Perf (upstream): don't empty method stores and provider synchronization records when flushing the query cache (LP: #2033422) - lp2033422/0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch - lp2033422/0002-Refactor-method-construction-pre-and-post-condition.patch - lp2033422/0003-Don-t-empty-the-method-store-when-flushing-the-query.patch - lp2033422/0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch - lp2033422/0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch - lp2033422/0006-For-child-libctx-provider-don-t-count-self-reference.patch - lp2033422/0007-Add-method-store-cache-flush-and-method-removal-to-n.patch -- Adrien Nader Tue, 09 Jan 2024 11:42:50 +0100 ** Changed in: openssl (Ubuntu Jammy) Status: Fix Committed => Fix Released -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: Fix Released Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Thanks a lot for the verification Simon! I looked at the test results and I believe failed tests are all fine: - diffoscope: pyhon "ModuleNotFoundError: No module named 'tests.utils'" - dotnet*: complains that this dotnet is not tested for 24.04 (yes, 24.04); this system of keeping a matrix of host/targets compatibility is being removed upstream due to being impossible to maintain (confirmed by Dominik) - ganeti: same failure as with the iptables SRU - linux-*: timed out building the kernel - ruby3.0: expired certificates in testsuite For the following packages, I re-tried the tests and they succeeded: - puma: retried twice and passed; at least one occurrence of the same failure - python-bonsai: retried; passing now; there have been various errors in this package that disappear on re-try - seqkit: retried; and passing I guess since it disappeared; there's a (long) history of this test failing - systemd: retried; timeouts which don't really seem to be related to openssl, or at least I couldn't spot an error, same issues can be seen in several other logs -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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.
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Using a fast HTTPS server (same LAN as client), the `main.py` tests goes from ~8s to ~2.5s: # time python3 /tmp/main.py Distro: Ubuntu 22.04.3 LTS Python Version: 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] OpenSSL Version: OpenSSL 3.0.2 15 Mar 2022 0 1 2 3 ... 99 real0m8.163s user0m16.041s sys 0m3.474s # apt-get install -t jammy-proposed libssl3 Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be upgraded: libssl3 1 upgraded, 0 newly installed, 0 to remove and 38 not upgraded. Need to get 1,902 kB of archives. After this operation, 1,024 B of additional disk space will be used. # time python3 /tmp/main.py Distro: Ubuntu 22.04.3 LTS Python Version: 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] OpenSSL Version: OpenSSL 3.0.2 15 Mar 2022 0 1 2 3 ... 99 real0m2.533s user0m9.188s sys 0m0.096s Upgrading the server side (NGINX) didn't make a measurable difference. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done verification-done-jammy -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Hello Adrien, or anyone else affected, Accepted openssl into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.13 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: openssl (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-jammy -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Thanks for the review and upload. I have a similar take on the patches in this series and I believe it would be very difficult and riskier to try to skip some of the patches in this series which has seen real-world use as a whole, starting with openssl >= 3.0.4 (which we started shipping in lunar). -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Reviewed and uploaded. For the particular patch series attached to this very bug, I'm seeing the patchset as two distincts parts. First are a few optimization patches by being more selective in flushing some caches, whereas the second part are behaviour changes that belong more in the realm of fixes than optimization. Given the nature of those fixes (e.g. "Complete the cleanup of an algorithm in OSSL_METHOD_STORE"), I'm *assuming* that they were hidden by the previous aggressive flushing, especially since they originate from the same PR (https://github.com/openssl/openssl/pull/18151) -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
I'm attaching an updated debdiff. - remove left-over patches for a bug that we decided to not handle as part of this SRU (patches were already unlisted from d/p/series) - added Bug-Ubuntu entries to patches PPA is the same. New build is at https://launchpad.net/~adrien-n/+archive/ubuntu/jammy- openssl-2033422-sru/+sourcepub/15684316/+listing-archive-extra . ** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5737782/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Changed in: openssl (Ubuntu Jammy) Assignee: Adrien Nader (adrien-n) => Simon Chopin (schopin) -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Here is an updated version. I've dropped the extra patch for #1994165 and fixed the changelog where I had swapped comments for two of the patches. I've created a new PPA at https://launchpad.net/~adrien-n/+archive/ubuntu/jammy- openssl-2033422-sru because the version is unchanged (there has been no new openssl security update). ** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5736379/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) - The SRU information has been added to the fthree bug reports and I am + The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture- dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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. [Patches] The patches come directly from
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] - This bug is part of a series of four bugs for a single SRU. + This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. - This SRU addresses four issues with Jammy's openssl version: + This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) - The SRU information has been added to the four bug reports and I am - attaching the debdiff here only for all four. + The SRU information has been added to the fthree bug reports and I am + attaching the debdiff here only for all three. 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). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture- dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] - This SRU contains FOUR changes which are listed in the section below. + This SRU contains THREE changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections + - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) 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). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture- dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
A version containing a fix for this has been uploaded to the Jammy queue to be processed by the SRU team. Thanks, Adrien :) -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . - Using this, I get the following numbers for ten runs on my laptop: + + To test, follow these steps: + - run "time python3 main.py" # using the aforementioned main.py script + - apt install -t jammy-proposed libssl3 + - run "time python3 main.py" + - compare the runtimes for the two main.py runs + + You can run this on x86_64, Raspberry Pi 4 or any machine, and get a + very large speed-up in all cases. The improvements are not architecture- + dependant. + + Using this changeset, I get the following numbers for ten runs on my + laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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. [Patches] The patches come directly from upstream and apply cleanly.
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Forgot to upload the latest debdiff. ** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff" https://bugs.launchpad.net/ubuntu/jammy/+source/openssl/+bug/2033422/+attachment/5713594/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . - - Simply run "time python3 main.py". The script does a GET for - https://www.google.com/humans.txt . You can replace this URI in the script with any other resource (I've also used something on my LAN with no timing difference). Since this is a performance change, you need to remember to get performance numbers before updating. You can run this test on any platform: the performance issue is purely logical and not tied to a CPU architecture. The improvement is very large and always reproductible with very little variability on a given machine; there is therefore no need to use a dedicated and fully idle machine using a constant-frequency CPU governor while ensuring temperatures do not cause throttling. - - Using this, I get the following numbers on my x86 laptop: + Using this, I get the following numbers for ten runs on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away.
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . - Using this, I get the following numbers on my laptop: + + Simply run "time python3 main.py". The script does a GET for + https://www.google.com/humans.txt . You can replace this URI in the script with any other resource (I've also used something on my LAN with no timing difference). Since this is a performance change, you need to remember to get performance numbers before updating. You can run this test on any platform: the performance issue is purely logical and not tied to a CPU architecture. The improvement is very large and always reproductible with very little variability on a given machine; there is therefore no need to use a dedicated and fully idle machine using a constant-frequency CPU governor while ensuring temperatures do not cause throttling. + + Using this, I get the following numbers on my x86 laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
In addition, could the test plan maybe be edited to answer the following question? "How can one validate that the package in -proposed addresses the issue?" -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
I am not going to upload this, because I'm widely uncomfortable with bug 1990216 (details there). In addition, I have a few superficial suggestions for aesthetics: * Use lpX subdirectories in d/patches rather than add a prefix to the patchname * Add a Bug-Ubuntu field with a LP URL to each patch to make it even easier to go back to the relevant bug -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === + [ATTENTION] + This SRU contains FOUR changes which are listed in the section below. + [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
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. https://bugs.launchpad.net/bugs/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
(did my mail answer from yesterday get eaten by launchpad?)
Here's an updated debdiff that:
- renames files using the lp- prefix,
- reworks the changelog to a more typical format:
* what (LP: #)
- ${file}
- adds DEP-3 to the patches
I've pushed an updated build on LP at
https://launchpad.net/~adrien-n/+archive/ubuntu/openssl-jammy-sru/+packages
It's still building unfortunately and I noticed typos in the changelog
which I corrected but didn't upload to the PPA due to how long it takes
to build. The differences are very minor (first level of the lsit in
d/changelog used - rather than *).
** Patch added: "openssl_3.0.2-0-ubuntu1.10-to-1.11.diff"
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5707350/+files/openssl_3.0.2-0-ubuntu1.10-to-1.11.diff
--
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/2033422
Title:
openssl: backport to jammy "clear method store / query cache
confusion"
Status in openssl package in Ubuntu:
New
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released
Bug description:
=== SRU information ===
[Meta]
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
debdiff.
This SRU addresses four issues with Jammy's openssl version:
- http://pad.lv/1990216: Blowfish OFB/CFB decryption
- http://pad.lv/1994165: ignored SMIME signature errors
- http://pad.lv/2023545: imbca engine dumps core
- http://pad.lv/2033422: 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).
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
sru
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
implemented.
[Impact]
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
updates.
[Test plan]
Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
.
Using this, I get the following numbers on my laptop:
3.0.2:
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 http://pad.lv/2009544 , 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Thanks for the contribution, Adrien. I find the naming scheme you chose for the patches a bit confusing. For example, you're using the prefix "jammy-sru-0001-" on several patches that are actually not strictly related. You also don't mention any patch explicitly in the d/changelog entry, which forces the reader to open d/p/series and look at the comments there. Moreover, the patches are missing DEP-3 headers (which, in this case, would be very useful when trying to understand the context when looking at a single patch). Could you please address the concerns above before we proceed with the upload? Thanks. -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru + + 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 implemented. [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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 http://pad.lv/2009544 , 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 https://www.google.com/humans.txt 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. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: 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. [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. + [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - - #1990216: Blowfish OFB/CFB decryption - - #1994165: ignored SMIME signature errors - - #2023545: imbca engine dumps core - - #2033422: very high CPU usage for concurrent TLS connections + - http://pad.lv/1990216: Blowfish OFB/CFB decryption + - http://pad.lv/1994165: ignored SMIME signature errors + - http://pad.lv/2023545: imbca engine dumps core + - http://pad.lv/2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks in #2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: - real 2m5.567s - user 4m3.948s - sys 2m0.233s + real 2m5.567s + user 4m3.948s + sys 2m0.233s this SRU: - real 0m23.966s - user 2m35.687s - sys 0m1.920s + 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. [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. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] 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 debdiff. This SRU addresses four issues with Jammy's openssl version: - #1990216: Blowfish OFB/CFB decryption - #1994165: ignored SMIME signature errors - #2023545: imbca engine dumps core - #2033422: 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). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] 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 updates. [Test plan] - Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. + Rafael Lopez has shared a simple benchmarks in #2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . + Using this, I get the following numbers on my laptop: + + 3.0.2: + 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. [Where problems could occur] - The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. + 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. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Attaching debdiff for openssl from 3.0.2-0ubuntu1.10 to 3.0.2-0ubuntu1.11 ** Description changed: === SRU information === + [Meta] + This bug is part of a series of four bugs for a single SRU. + The "central" bug with the global information and debdiff is #2033422 + + This SRU addresses four issues with Jammy's openssl version: + - #1990216: Blowfish OFB/CFB decryption + - #1994165: ignored SMIME signature errors + - #2023545: imbca engine dumps core + - #2033422: 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). + + https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- + sru [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0007-Add-method-store-cache-flush-and-method-removal-to-n.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . 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. ** Description changed: ** Description changed: === SRU information === [Meta] This bug is part of a series of four bugs for a single SRU. The "central" bug with the global information and debdiff is
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. + [Patches] + The patches come directly from upstream and apply cleanly. + + https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 + + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0007-Add-method-store-cache-flush-and-method-removal-to-n.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + === Original description === This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . 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. -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: + === SRU information === + + [Impact] + 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 updates. + + [Test plan] + Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. + + [Where problems could occur] + The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. + + === Original description === + This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . 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. -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Impact] 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 updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. === Original description === This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . 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: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
I've created a PPA for Jammy that incorporates the fix mentionned. The details are available at https://launchpad.net/~adrien-n/+archive/ubuntu/openssl-jammy-sru . Could you test it and confirm your issue is solved? -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . 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: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
