RFC on Jammy SRU with OpenSSL 3.0 backports for performance

[Steve Langasek]

Hi Mauricio,

On Tue, Aug 15, 2023 at 10:20:50AM -0300, Mauricio Faria de Oliveira wrote:
> Hey,

> I'd like to request input (initially thinking of involved teams: SRU,
> Foundations)
> on backports of some performance improvement patches to OpenSSL in Jammy.
> (Please feel free to comment and include others as appropriate.)

With my SRU Team hat on, I would be willing to consider such performance
fixes in an SRU for jammy.  Modern systems spend a lot of time in crypto
routines, so performance certainly matters here!  And while with glibc we
have to worry about whether performance improvements for one chip are going
to regress them for another, when we're talking about questions of whether
hardware AES support is being exploited by openssl vs not (as I saw was the
case for one of the referenced commits), it's a lot more straightforward.

We also have a precedent of "hardware enablement" performance improvements
on jammy for a number of server packages, to get them built with compiler
options that significantly improve performance on particular arm64 server
hardware.

Caveat: I have not reviewed the actual commits that you are proposing to
backport, I am only speaking for whether this is ok for SRU in principle.  I
would prefer to save a more in-depth review for the SRU unapproved queue.

> SEG has a customer support ticket about it, which allows us to put in the work,
> but of course, it is OpenSSL, an SRU, thus agreement beforehand is needed.

> ...

> The context is OpenSSL 3.0 has known, significant performance regressions [0]
> from OpenSSL 1.1.1, which has been addressed / still in-progress upstream:
> 1) some patches in the 3.0 stable branch
> 2) some patches in the master branch (ie, not backported to 3.0)
> 3) some issues still open
> 
> To offset regression risk, there are benefits; e.g.,
> 1) Performance: some improvement
> 2) Security: smaller delta to 3.0 branch (may help with CVE fix backports)
> 3) Community: possibly help with mentions of Ubuntu 22.04 in regressions
> 
> IMHO, backports should be restricted to the 3.0 branch (so not to defeat 2).
> 
> ...
> 
> There are statements in this thread [1] that suggest we only backport bug
> and security fixes, certainly understandable, but considering the numbers,
> _perhaps_ we should consider it -- that's why I ask your opinion on this.
> 
> For example, the test in bug [2]:
> 
> 1) Focal, OpenSSL 1.1.1: 1.5 seconds
> 2) Jammy, OpenSSL 3.0.2: 30 seconds (20x slower)
> 3) Jammy, 7 cherrypicks: 5 seconds  (3x slower) (PPA [3])
> 
> So, these 7 clean cherry-picks from 3.0 branch [4] help significantly,
> for this customer's test-case, but we (SEG) would only analyze in more
> detail (and possibly propose such changes) based on input from other
> involved teams. (SRU, Foundations, and Security later.)
> 
> Please let us know your thoughts.
> 
> Thanks!
> Mauricio
> 
> [0] https://github.com/openssl/openssl/issues/17627#issuecomment-1060123659
> [1] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2023-May/019532.html
> [2] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544
> [3] https://launchpad.net/~mfo/+archive/ubuntu/lp2009544
> [4] https://github.com/openssl/openssl/pull/18151
> 
> -- 
> Mauricio Faria de Oliveira
> 
> -- 
> Ubuntu-release mailing list
> Ubuntu-release at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20230815/46f63498/attachment.sig>