[CentOS-devel] glibc-2.34-37.el9 enables rseq by default

Thu Jun 9 16:22:58 UTC 2022
Fabian Arrotin <arrfab at centos.org>

On 09/06/2022 10:54, Florian Weimer wrote:
> We are going to enable rseq registration in glibc by default starting
> with glibc-2.34-37.el9 (already built in Koji).  To facilitate
> integration with other rseq users, we have backported the GLIBC_2.35
> symbol set for rseq integration.  Such an ABI update during a major
> release is not entirely unprecedented for glibc, but hasn't happened in
> recent times.  If an application links against the symbols, RPM will
> generate the appropriate dependencies, forcing an upgrade to a
> compatible glibc version.  This is unlikely to happen soon because the
> interface is glibc-specific and has only been added in glibc 2.35, so
> applications would have to be written specifically for this interface.
> As a side effect, criu needs to be updated to criu-3.17-2.el9 to remain
> functional.
> The background is that rseq is required to implement a useful version of
> sched_getcpu on AArch64.  Previously, a system call had to be used, and
> with rseq, execution can remain in userspace.  The benefit is less on
> other architectures, but still there (e.g., on x86-64, an obscure LSL
> instruction is replaced with a memory load).  And once glibc registers
> its rseq area, nothing else in the process can register it again, which
> is why we need some interface to rseq-using applications.  Rather than
> coming up with our own interface, we decided to just use the upstream
> interface.  Not entirely by accident, the GLIBC_2.35 symbol set for
> ld.so consists precisely of the rseq symbols, so RPM dependency
> management should interoperate well with this change.  (Our RPM version
> requires backporting such symbol sets in their entirety, we do not have
> per-symbol package versioning information like Debian in our package
> builds.)
> Due to a kernel bug on the CentOS builders, sched_getcpu may return the
> wrong values during package builds.  I requested a builder kernel update
> here:
>    Please upgrade c9s builders to an 8.4 or later kernel
>    <https://issues.redhat.com/browse/CS-1129>
> Downstream, we have plans for maintaining ABI compatibility with RHEL
> 9.0: backporting the symbol set there as well, without registering rseq
> by default.
> I don't know yet if we are going to backport further symbol sets to
> CentOS 9 Stream.  The requirement to backport full symbol sets could be
> quite onerous.  Historically, the main driver for such backports has
> been to enable running applications on CentOS that have been built on
> other distributions.  I suspect the glibc incompatibility is simply the
> first problem people saw, and we don't know what problems would have
> come next after had we eliminated the glibc obstacle.  Applications
> for CentOS should really be built and tested on CentOS.
> Thanks,
> Florian

Hi Florian,

If there is already an internal ticket for this, let's track it there, 
and eventually see if we also need to apply this for other architectures.
Also then worth doing that on the cbs.centos.org infra (or at least 
checking which running kernel it has, as there is daily update on that 
servers fleet, but reboot are either "on demand" or "scheduled" 
depending on the need)

Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA25DBAFB17F3B7A1.asc
Type: application/pgp-keys
Size: 12767 bytes
Desc: OpenPGP public key
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20220609/321aac51/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20220609/321aac51/attachment-0003.sig>