Comment 6 for bug 1674399

Revision history for this message
Eric Desrochers (slashd) wrote :

[For SRU Verification team]

Context :
Previous IRC discussion with apw/rbasak about this case :
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1674399/comments/2

AMD released a new CPU called "Ryzen" that now support "Intel SHA extensions" technology.

In current Ubuntu openssl package sha extension are masked on Ryzen CPU. Ryzen is available in 64-bit only CPU (Confimed with AMD representative).

There are upstream patches that solve this situation and my test revealed that openssl has significant performance increase on a AMD CPU with sha extension capability.

The upstream patches "f8418d8" & "1aed5e1" fix the situation by moving the extended feature detection from Label (.Lintel) to Label (.Lgeneric) in both 64-bit(crypto/x86_64cpuid.pl) & 32-bit (crypto/x86cpuid.pl) code where it should belongs now that non-intel CPU can also have the capability. I cannot strictly isolate the fix for Ryzen CPU only, meaning that this feature will enable sha extension for all CPUa that support the functionality, where prior this patch it was strictly reserved for Intel CPU only.

Since I don't forsee a lot of users using the 32-bit package of opensssl on a 64-bit CPU with sha extension enabled and putting myself in a SRU mindset, I proposed the following :

- SRU the 64-bit and 32-bit patch in development release (Artful/17.10)
- SRU the 64 bit only in Stable release (Xenial/Zesty)
  - 32-bit code : Remain the same, thus no behavioural change
  - 64-bit code : Enable sha extension for 64-bit CPU that has the capabilities.

The test that I proposed before "verification-done" (while package is in -proposed)

-> Do a performance test using openssl speed[1] & generate a checksum on a big file[2] (e.g. 5GB) and capture the metric to compare before and after the patch on a 64-bit AMD system WITH sha extension capability (Ryzen).
-> Do a performance test using openssl speed[1] & generate a checksum on a big file[2] (e.g. 5GB) and capture the metric to compare before and after the patch on a 64-bit AMD system WITHOUT sha extension capability.
-> Do a performance test using openssl speed[1] & generate a checksum on a big file[2] (e.g. 5GB) and capture the metric to compare before and after the patch on a 64-bit Intel system WITH sha extension capability.
-> Do a performance test using openssl speed[1] & generate a checksum on a big file[2] (e.g. 5GB) and capture the metric to compare before and after the patch on a 64-bit Intel system WITHOUT sha extension capability.
-> In all the above tests, using perf record/annotate could also be done to validate if the sha instructions has been used or not depending on the above scenarios to conclude everything is working as expected.

No extra testing will be needed for 32-bit package since no 32-bit code will be modified.
On the other hand, if a user for some reason want to use openssl in 32-bit on a 64-bit with sha extension CPU capabilities, then this user won't have all the performance benefit of the 64-bit code fix.

Considering that this request is a "HW enablement", thus not a bugfix and the above notes... Is this would be eligible for SRU in Stable Release ?

[1] - Openssl speed measurement using sha1
$ openssl speed sha1

[2] - Measure time performance of generating a checksum of a big file (e.g. 5GB)
$ time openssl dgst -sha256 /var/tmp/5Gfile