| 2023-02-16 17:39:26 |
bugproxy |
bug |
|
|
added bug |
| 2023-02-16 17:39:28 |
bugproxy |
tags |
|
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 |
|
| 2023-02-16 17:39:29 |
bugproxy |
ubuntu: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2023-02-16 17:39:31 |
bugproxy |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2023-02-16 17:39:32 |
bugproxy |
bug |
|
|
added subscriber CDE Administration |
| 2023-02-16 17:39:33 |
bugproxy |
bug |
|
|
added subscriber Boris Barth |
| 2023-02-16 17:51:33 |
Frank Heimes |
affects |
linux (Ubuntu) |
glibc (Ubuntu) |
|
| 2023-02-16 17:51:57 |
Frank Heimes |
bug task added |
|
ubuntu-z-systems |
|
| 2023-02-16 17:52:11 |
Frank Heimes |
ubuntu-z-systems: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2023-02-16 17:52:13 |
Frank Heimes |
ubuntu-z-systems: importance |
Undecided |
High |
|
| 2023-02-16 17:52:15 |
Frank Heimes |
glibc (Ubuntu): importance |
Undecided |
High |
|
| 2023-02-21 10:00:43 |
Frank Heimes |
ubuntu-z-systems: status |
New |
Triaged |
|
| 2023-02-21 10:00:46 |
Frank Heimes |
glibc (Ubuntu): status |
New |
Triaged |
|
| 2023-02-21 13:28:37 |
Simon Chopin |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-02-21 13:28:37 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu Jammy) |
|
| 2023-02-21 13:28:45 |
Simon Chopin |
glibc (Ubuntu Jammy): status |
New |
Triaged |
|
| 2023-02-21 13:29:02 |
Simon Chopin |
glibc (Ubuntu Jammy): importance |
Undecided |
High |
|
| 2023-02-27 06:39:12 |
Frank Heimes |
glibc (Ubuntu Jammy): status |
Triaged |
Confirmed |
|
| 2023-02-27 06:39:15 |
Frank Heimes |
glibc (Ubuntu): status |
Triaged |
Confirmed |
|
| 2023-02-27 06:39:18 |
Frank Heimes |
ubuntu-z-systems: status |
Triaged |
Confirmed |
|
| 2023-03-15 16:09:14 |
Simon Chopin |
glibc (Ubuntu): status |
Confirmed |
In Progress |
|
| 2023-03-15 17:02:26 |
Frank Heimes |
information type |
Private |
Public |
|
| 2023-03-16 10:22:53 |
Frank Heimes |
ubuntu-z-systems: status |
Confirmed |
In Progress |
|
| 2023-03-27 09:30:18 |
Launchpad Janitor |
glibc (Ubuntu): status |
In Progress |
Fix Released |
|
| 2023-03-27 09:30:18 |
Launchpad Janitor |
cve linked |
|
2023-25139 |
|
| 2023-05-31 12:01:22 |
Simon Chopin |
glibc (Ubuntu Jammy): status |
Confirmed |
In Progress |
|
| 2023-05-31 12:02:14 |
Simon Chopin |
description |
Feature Description:
In glibc there are a lot of IFUNC-optimized functions, where we have different implementations for e.g. z13, z14, z15, ... . At runtime the best implementation is chosen depending on the available HWCAP-/STFLE-bits.
We need to have a mechanism to influence this decision. There already exists such a mechanism for x86 which is documented here:
GLIBC_TUNABLE: glibc.cpu.hwcaps (x86 variant)
https://www.gnu.org/software/libc/manual/html_node/Hardware-Capability-Tunables.html
Therefore we've developed the commit
"S390: Influence hwcaps/stfle via GLIBC_TUNABLES." (https://sourceware.org/git/?p=glibc.git;a=commit;h=41f67ccbe92b4fd09e1062b383e55e407ae5bfa1)
as part of our maintenance work. The s390-variant of the mentioned tunable is able to add/remove specific HWCAP-/STFLE-bits used by the IFUNC-resolvers inside glibc. Furthermore we can set the architecture-level like z13 to influence multiple bits at once.
One can query if the feature is available with (useful to check if this feature is also backported to current distro or not):
$ /lib/ld64.so.1 --list-tunables |
SRU Justification:
==================
[Business Case]
The Eclipse OpenJ9 project is developing an "InstantOn" technology that leverages Linux's Checkpoint/Restore In Userspace (CRIU) feature. By restoring the JVM process from an existing CRIU snapshot, application can start-up up to 18x faster, without any compromises to throughput or JVM capabilities. This technology is ideal for serverless computing and scaling micro services in containerized deployments.
IBM WebSphere Liberty is one of the first exploiters of OpenJ9 InstantOn technology and have measured 10x faster start-up. In a 2021 survey with Java customers on IBM Z, 80% of users ranked initial start-up / ramp-up performance as an important metric. Other Java-based middleware and libraries can also take advantage of this technology for the significant start-up improvements. This GLIBC patch addresses a functional portability issue that is encountered when users create a container image with a CRIU snapshot on a newer hardware level and deploy this image against older hardware. GLIBC caches hardware facilities, which may not be available on the older deployment target, resulting in potential illegal instructions. With GLIBC_TUNABLES fixed to influence hwcaps and stfle bits on s390x, it allows the snapshot environment to mimic older hardware levels for the snapshot.
[Impact]
* This in a hardware enablement SRU, and mainly adds support for CryptoExpress 8S adapters to the s390-tools package.
* With that the new options 'show_serialnumbers', '--accelonly', '--ccaonly' and '--ep11only' are introduced to the lszcrypt tool.
* In addition lszcrypt now supports the checkstop state of a crypto card, that is provided by the 'chkstop' attribute in the sysfs of newer kernels.
* And lszcrypt now shows the AP bus msg size limit capability, which is needed for new adapter cards.
* New codes for zcryptstats are needed as well.
[Test Plan]
* Prepare an IBM z16 LPAR with Ubuntu 22.04 (incl. this patch) that has an CryptoExpress 8S adapter attached to it and at least one crypto domain online and available.
* Call 'lszcrypt -V' and check the 2nd column called 'type' and the last column called 'driver'.
* If both have entries that start with "cex8..." then the new CryptoExpress 8S driver is active and the new card is detected and can be used (and the new features exploited).
* If the driver listed there is older than 'cex8', than the new card is probably detected as an older type and it runs in toleration mode only.
* Try and test the new options.
* Run zcryptstats and with that make use of the new codes (which actually means add CEX8S support for zcryptstats).
* And finally extending lszcrypt's capabilities and make it aware of CEX8S.
[Where problems could occur]
* The new declarations, initializations or the scan for the serial numbers of the devices could fail, which would lead to a non-working or even erroneous new '-s' option.
* The new filter mechanism could be broken and now incorrect resources, but this would be limited to the new options '--cardonly' and '--queueonly'.
* The same applies to the new options '--accelonly', '--ccaonly' and '--ep11only'.
* The handling of the new chkstop state can be confusing or might be broken, which may lead to wrong state representations.
* The new AP bus msg size limit might be incorrectly calculated, which leads to a wrong size and with that certain feature not to work.
* The new zcryptstats might come with wrong or mixed codes, which would lead to wrong and misleading statistics, or even break zcryptstats.
* Regarding the lszcrypt capability extension there is no danger since an existing case statement is extended and the case content reused unchanged.
* All this is s390x specific, and only affects the handling for CryptoExpress 8S adapters. It won't have an impact on CPACF.
[Original report]
Feature Description:
In glibc there are a lot of IFUNC-optimized functions, where we have different implementations for e.g. z13, z14, z15, ... . At runtime the best implementation is chosen depending on the available HWCAP-/STFLE-bits.
We need to have a mechanism to influence this decision. There already exists such a mechanism for x86 which is documented here:
GLIBC_TUNABLE: glibc.cpu.hwcaps (x86 variant)
https://www.gnu.org/software/libc/manual/html_node/Hardware-Capability-Tunables.html
Therefore we've developed the commit
"S390: Influence hwcaps/stfle via GLIBC_TUNABLES." (https://sourceware.org/git/?p=glibc.git;a=commit;h=41f67ccbe92b4fd09e1062b383e55e407ae5bfa1)
as part of our maintenance work. The s390-variant of the mentioned tunable is able to add/remove specific HWCAP-/STFLE-bits used by the IFUNC-resolvers inside glibc. Furthermore we can set the architecture-level like z13 to influence multiple bits at once.
One can query if the feature is available with (useful to check if this feature is also backported to current distro or not):
$ /lib/ld64.so.1 --list-tunables |
|
| 2023-05-31 12:03:47 |
Simon Chopin |
description |
SRU Justification:
==================
[Business Case]
The Eclipse OpenJ9 project is developing an "InstantOn" technology that leverages Linux's Checkpoint/Restore In Userspace (CRIU) feature. By restoring the JVM process from an existing CRIU snapshot, application can start-up up to 18x faster, without any compromises to throughput or JVM capabilities. This technology is ideal for serverless computing and scaling micro services in containerized deployments.
IBM WebSphere Liberty is one of the first exploiters of OpenJ9 InstantOn technology and have measured 10x faster start-up. In a 2021 survey with Java customers on IBM Z, 80% of users ranked initial start-up / ramp-up performance as an important metric. Other Java-based middleware and libraries can also take advantage of this technology for the significant start-up improvements. This GLIBC patch addresses a functional portability issue that is encountered when users create a container image with a CRIU snapshot on a newer hardware level and deploy this image against older hardware. GLIBC caches hardware facilities, which may not be available on the older deployment target, resulting in potential illegal instructions. With GLIBC_TUNABLES fixed to influence hwcaps and stfle bits on s390x, it allows the snapshot environment to mimic older hardware levels for the snapshot.
[Impact]
* This in a hardware enablement SRU, and mainly adds support for CryptoExpress 8S adapters to the s390-tools package.
* With that the new options 'show_serialnumbers', '--accelonly', '--ccaonly' and '--ep11only' are introduced to the lszcrypt tool.
* In addition lszcrypt now supports the checkstop state of a crypto card, that is provided by the 'chkstop' attribute in the sysfs of newer kernels.
* And lszcrypt now shows the AP bus msg size limit capability, which is needed for new adapter cards.
* New codes for zcryptstats are needed as well.
[Test Plan]
* Prepare an IBM z16 LPAR with Ubuntu 22.04 (incl. this patch) that has an CryptoExpress 8S adapter attached to it and at least one crypto domain online and available.
* Call 'lszcrypt -V' and check the 2nd column called 'type' and the last column called 'driver'.
* If both have entries that start with "cex8..." then the new CryptoExpress 8S driver is active and the new card is detected and can be used (and the new features exploited).
* If the driver listed there is older than 'cex8', than the new card is probably detected as an older type and it runs in toleration mode only.
* Try and test the new options.
* Run zcryptstats and with that make use of the new codes (which actually means add CEX8S support for zcryptstats).
* And finally extending lszcrypt's capabilities and make it aware of CEX8S.
[Where problems could occur]
* The new declarations, initializations or the scan for the serial numbers of the devices could fail, which would lead to a non-working or even erroneous new '-s' option.
* The new filter mechanism could be broken and now incorrect resources, but this would be limited to the new options '--cardonly' and '--queueonly'.
* The same applies to the new options '--accelonly', '--ccaonly' and '--ep11only'.
* The handling of the new chkstop state can be confusing or might be broken, which may lead to wrong state representations.
* The new AP bus msg size limit might be incorrectly calculated, which leads to a wrong size and with that certain feature not to work.
* The new zcryptstats might come with wrong or mixed codes, which would lead to wrong and misleading statistics, or even break zcryptstats.
* Regarding the lszcrypt capability extension there is no danger since an existing case statement is extended and the case content reused unchanged.
* All this is s390x specific, and only affects the handling for CryptoExpress 8S adapters. It won't have an impact on CPACF.
[Original report]
Feature Description:
In glibc there are a lot of IFUNC-optimized functions, where we have different implementations for e.g. z13, z14, z15, ... . At runtime the best implementation is chosen depending on the available HWCAP-/STFLE-bits.
We need to have a mechanism to influence this decision. There already exists such a mechanism for x86 which is documented here:
GLIBC_TUNABLE: glibc.cpu.hwcaps (x86 variant)
https://www.gnu.org/software/libc/manual/html_node/Hardware-Capability-Tunables.html
Therefore we've developed the commit
"S390: Influence hwcaps/stfle via GLIBC_TUNABLES." (https://sourceware.org/git/?p=glibc.git;a=commit;h=41f67ccbe92b4fd09e1062b383e55e407ae5bfa1)
as part of our maintenance work. The s390-variant of the mentioned tunable is able to add/remove specific HWCAP-/STFLE-bits used by the IFUNC-resolvers inside glibc. Furthermore we can set the architecture-level like z13 to influence multiple bits at once.
One can query if the feature is available with (useful to check if this feature is also backported to current distro or not):
$ /lib/ld64.so.1 --list-tunables |
SRU Justification:
==================
[Business Case]
The Eclipse OpenJ9 project is developing an "InstantOn" technology that leverages Linux's Checkpoint/Restore In Userspace (CRIU) feature. By restoring the JVM process from an existing CRIU snapshot, application can start-up up to 18x faster, without any compromises to throughput or JVM capabilities. This technology is ideal for serverless computing and scaling micro services in containerized deployments.
IBM WebSphere Liberty is one of the first exploiters of OpenJ9 InstantOn technology and have measured 10x faster start-up. In a 2021 survey with Java customers on IBM Z, 80% of users ranked initial start-up / ramp-up performance as an important metric. Other Java-based middleware and libraries can also take advantage of this technology for the significant start-up improvements. This GLIBC patch addresses a functional portability issue that is encountered when users create a container image with a CRIU snapshot on a newer hardware level and deploy this image against older hardware. GLIBC caches hardware facilities, which may not be available on the older deployment target, resulting in potential illegal instructions. With GLIBC_TUNABLES fixed to influence hwcaps and stfle bits on s390x, it allows the snapshot environment to mimic older hardware levels for the snapshot.
[Impact]
* For IFUNC'ed functions within glibc, the decision can now be influenced with GLIBC_TUNABLE: glibc.cpu.hwcaps
* This can be used as test vehicle
* This is a prerequisite for Eclipse OpenJ9 projects "InstantOn" technology which speeds up start-up times by factors.
[Test Plan]
* Prepare an IBM z15 LPAR with Ubuntu (incl. this patch)
* Check if patch is applied by running command "/usr/lib/s390x-linux-gnu/ld64.so.1 --list-tunables" and check if the new tunable "glibc.cpu.hwcaps" is listed
* Prepare a small test-program calling IFUNC-optimized functions: memmem, strstr and memmove.
* Start a gdb session and break at __memmem_vx, __memmem_arch13, __strstr_vx, __strstr_arch13, __memmove_z13 and __memmove_arch13. Run the program and you should always stop in the arch13=z15 functions. Now use gdb-command "set environment GLIBC_TUNABLES glibc.cpu.hwcaps=z13" and run again. Now you should always stop in the vx=z13 functions.
[Original report]
Feature Description:
In glibc there are a lot of IFUNC-optimized functions, where we have different implementations for e.g. z13, z14, z15, ... . At runtime the best implementation is chosen depending on the available HWCAP-/STFLE-bits.
We need to have a mechanism to influence this decision. There already exists such a mechanism for x86 which is documented here:
GLIBC_TUNABLE: glibc.cpu.hwcaps (x86 variant)
https://www.gnu.org/software/libc/manual/html_node/Hardware-Capability-Tunables.html
Therefore we've developed the commit
"S390: Influence hwcaps/stfle via GLIBC_TUNABLES." (https://sourceware.org/git/?p=glibc.git;a=commit;h=41f67ccbe92b4fd09e1062b383e55e407ae5bfa1)
as part of our maintenance work. The s390-variant of the mentioned tunable is able to add/remove specific HWCAP-/STFLE-bits used by the IFUNC-resolvers inside glibc. Furthermore we can set the architecture-level like z13 to influence multiple bits at once.
One can query if the feature is available with (useful to check if this feature is also backported to current distro or not):
$ /lib/ld64.so.1 --list-tunables |
|
| 2023-06-01 16:05:43 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Simon Chopin |
| 2023-06-06 08:21:21 |
Simon Chopin |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-06-06 08:21:21 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu Kinetic) |
|
| 2023-06-06 08:21:21 |
Simon Chopin |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-06-06 08:21:21 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu Lunar) |
|
| 2023-06-06 08:21:28 |
Simon Chopin |
glibc (Ubuntu Kinetic): status |
New |
Won't Fix |
|
| 2023-06-06 08:21:32 |
Simon Chopin |
glibc (Ubuntu Lunar): status |
New |
Fix Released |
|
| 2023-06-06 19:54:20 |
Brian Murray |
glibc (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2023-06-06 19:54:22 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-06-06 19:54:24 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2023-06-06 19:54:28 |
Brian Murray |
tags |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 verification-needed verification-needed-jammy |
|
| 2023-06-06 20:09:51 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Fix Committed |
|
| 2023-06-12 11:59:35 |
bugproxy |
tags |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 verification-needed verification-needed-jammy |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 verification-done verification-done-jammy |
|
| 2023-07-28 18:36:42 |
Brian Murray |
tags |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 verification-done verification-done-jammy |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 verification-needed verification-needed-jammy |
|
| 2023-08-09 08:57:55 |
Frank Heimes |
attachment added |
|
hwcaps_existence_test.txt https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2007599/+attachment/5691284/+files/hwcaps_existence_test.txt |
|
| 2023-08-09 08:58:31 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 verification-needed verification-needed-jammy |
architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 verification-done verification-done-jammy |
|
| 2023-09-12 15:48:24 |
Launchpad Janitor |
glibc (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-09-12 15:48:52 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-09-12 15:59:00 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
Fix Released |
|
