linux-kernel - librseq: update to support upcoming glibc 2.35

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Dec 2021 16:47:13 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     libc-alpha <libc-alpha@...rceware.org>,
        Peter Zijlstra <peterz@...radead.org>,
        paulmck <paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: librseq: update to support upcoming glibc 2.35

Hi,

I've made a few updates to librseq to support the upcoming glibc 2.35.
My goal is to provide rseq support when linked against older glibc
(without rseq support) and use glibc's rseq registration when it is
available.

In order to achieve this, librseq now exposes 3 symbols:

- rseq_offset,
- rseq_size,
- rseq_flags.

It looks up for glibc's __rseq_offset, __rseq_size, and __rseq_flags
symbols in its library constructor with dlsym(3). If those are found,
then their values are copied into the variables exposed by librseq's
public symbols. Else, if glibc symbols are not found, librseq rely on
an initial-exec model TLS to keep its rseq per-thread ABI. It relies
on the fact that a initial-exec model TLS has a constant offset from the
thread pointer.

librseq's public headers now use librseq's own rseq_offset, rseq_size, and
rseq_flags symbols.

You can find the development branch implementing this here:

https://github.com/compudj/librseq/tree/prep-glibc-2.35

After we agree on the approach, I plan to upstream this code into the
Linux kernel selftests so they become compatible with glibc-2.35.

Comments are welcome.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com