| 2023-08-29 17:30:36 |
Adrien Nader |
bug |
|
|
added bug |
| 2023-08-29 17:30:46 |
Adrien Nader |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-08-29 17:30:46 |
Adrien Nader |
bug task added |
|
openssl (Ubuntu Lunar) |
|
| 2023-08-29 17:30:46 |
Adrien Nader |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-08-29 17:30:46 |
Adrien Nader |
bug task added |
|
openssl (Ubuntu Jammy) |
|
| 2023-08-29 17:31:12 |
Adrien Nader |
openssl (Ubuntu Lunar): assignee |
|
Adrien Nader (adrien-n) |
|
| 2023-08-29 17:31:17 |
Adrien Nader |
openssl (Ubuntu Jammy): milestone |
|
ubuntu-22.04.4 |
|
| 2023-08-29 17:31:22 |
Adrien Nader |
openssl (Ubuntu Jammy): milestone |
ubuntu-22.04.4 |
jammy-updates |
|
| 2023-08-29 17:35:13 |
Adrien Nader |
openssl (Ubuntu Lunar): assignee |
Adrien Nader (adrien-n) |
|
|
| 2023-08-29 17:35:15 |
Adrien Nader |
openssl (Ubuntu Jammy): assignee |
|
Adrien Nader (adrien-n) |
|
| 2023-08-29 17:35:19 |
Adrien Nader |
openssl (Ubuntu Jammy): importance |
Undecided |
Medium |
|
| 2023-08-29 17:35:32 |
Adrien Nader |
openssl (Ubuntu Jammy): status |
New |
In Progress |
|
| 2023-08-29 17:35:35 |
Adrien Nader |
openssl (Ubuntu Lunar): status |
New |
Fix Released |
|
| 2023-09-29 20:46:54 |
Adrien Nader |
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. |
=== 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. |
|
| 2023-09-30 07:57:30 |
Adrien Nader |
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. |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-01 23:49:37 |
Rafael Lopez |
bug |
|
|
added subscriber Rafael Lopez |
| 2023-10-02 08:55:08 |
Adrien Nader |
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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 08:55:17 |
Adrien Nader |
description |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 08:56:17 |
Adrien Nader |
description |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 09:00:41 |
Adrien Nader |
attachment added |
|
openssl_3.0.2-0-ubuntu1.10-to-1.11.diff https://bugs.launchpad.net/ubuntu/jammy/+source/openssl/+bug/2033422/+attachment/5705861/+files/openssl_3.0.2-0-ubuntu1.10-to-1.11.diff |
|
| 2023-10-02 09:04:04 |
Adrien Nader |
description |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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.
[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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 11:16:23 |
Adrien Nader |
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:
- #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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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. 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 11:29:16 |
Adrien Nader |
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:
- #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 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. 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 #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.
[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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 11:30:00 |
Adrien Nader |
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
[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
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.
[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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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.
[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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 11:36:00 |
Adrien Nader |
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
[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.
[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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 12:34:43 |
Adrien Nader |
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
[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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-02 14:36:58 |
Adrien Nader |
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
[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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-03 12:53:09 |
Adrien Nader |
bug |
|
|
added subscriber Ubuntu Sponsors |
| 2023-10-06 11:26:20 |
Adrien Nader |
attachment 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 |
|
| 2023-10-16 13:19:42 |
Adrien Nader |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2023-10-25 20:33:56 |
Adrien Nader |
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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-26 10:59:56 |
Adrien Nader |
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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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:
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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-26 13:31:40 |
Adrien Nader |
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 .
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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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.
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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-26 13:32:19 |
Adrien Nader |
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 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.
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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-26 19:01:27 |
Adrien Nader |
attachment 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 |
|
| 2023-10-26 19:11:58 |
Adrien Nader |
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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-27 15:47:50 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Simon Chopin |
| 2023-10-31 13:14:14 |
Adrien Nader |
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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 ( #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 (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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-10-31 22:16:08 |
Nathan Stratton Treadway |
bug |
|
|
added subscriber Nathan Stratton Treadway |
| 2023-11-01 18:05:18 |
Adrien Nader |
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 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 (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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-11-16 04:26:14 |
Nathan Stratton Treadway |
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 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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
=== 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 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&id=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&id=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&id=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&id=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&id=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&id=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&id=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. |
|
| 2023-12-14 11:40:51 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber Mauricio Faria de Oliveira |
| 2024-01-04 11:00:50 |
Adrien Nader |
attachment 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 |
|
| 2024-01-04 13:41:15 |
Adrien Nader |
bug |
|
|
added subscriber Ubuntu Sponsors |
| 2024-01-04 13:44:25 |
Simon Chopin |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2024-01-04 13:44:33 |
Simon Chopin |
openssl (Ubuntu Jammy): assignee |
Adrien Nader (adrien-n) |
Simon Chopin (schopin) |
|
| 2024-01-09 13:50:24 |
Adrien Nader |
attachment 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 |
|
| 2024-01-18 18:47:00 |
Simon Déziel |
bug |
|
|
added subscriber Simon Déziel |
| 2024-01-19 23:32:50 |
Steve Langasek |
openssl (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2024-01-19 23:32:52 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-01-19 23:32:55 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2024-01-19 23:32:59 |
Steve Langasek |
tags |
|
verification-needed verification-needed-jammy |
|
| 2024-01-20 19:01:30 |
Simon Déziel |
tags |
verification-needed verification-needed-jammy |
verification-done verification-done-jammy |
|
| 2024-01-25 11:28:47 |
Launchpad Janitor |
openssl (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-01-25 11:28:57 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
