[23.04 FEAT] [GNU2223] glibc - Influence hwcaps/stfle via GLIBC_TUNABLES glibc.cpu.hwcaps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
High
|
Skipper Bug Screeners | ||
glibc (Ubuntu) |
Fix Released
|
High
|
Skipper Bug Screeners | ||
Jammy |
Fix Released
|
High
|
Unassigned | ||
Kinetic |
Won't Fix
|
Undecided
|
Unassigned | ||
Lunar |
Fix Released
|
Undecided
|
Unassigned |
Bug 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]
* 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/
* 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.
[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:/
Therefore we've developed the commit
"S390: Influence hwcaps/stfle via GLIBC_TUNABLES." (https:/
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
CVE References
tags: | added: architecture-s39064 bugnameltc-201645 severity-high targetmilestone-inin2304 |
Changed in ubuntu: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
affects: | ubuntu → linux (Ubuntu) |
affects: | linux (Ubuntu) → glibc (Ubuntu) |
Changed in ubuntu-z-systems: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
importance: | Undecided → High |
Changed in glibc (Ubuntu): | |
importance: | Undecided → High |
Changed in ubuntu-z-systems: | |
status: | New → Triaged |
Changed in glibc (Ubuntu): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Jammy): | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in glibc (Ubuntu Jammy): | |
status: | Triaged → Confirmed |
Changed in glibc (Ubuntu): | |
status: | Triaged → Confirmed |
Changed in ubuntu-z-systems: | |
status: | Triaged → Confirmed |
Changed in glibc (Ubuntu): | |
status: | Confirmed → In Progress |
information type: | Private → Public |
Changed in ubuntu-z-systems: | |
status: | Confirmed → In Progress |
Changed in glibc (Ubuntu Jammy): | |
status: | Confirmed → In Progress |
description: | updated |
description: | updated |
Changed in ubuntu-z-systems: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-z-systems: | |
status: | Fix Committed → Fix Released |
This seems reasonable to add as an HWE feature, I'll include the patch in my next upload to lunar.
I'm not opposed to backporting it further down in the LTS SRUs, but I'd like a test plan a bit more involved than the `--list-tunables` if you don't mind?