[PATCH v4 00/14] RELRO link maps

[Kevin Brodsky]

Hi Florian,

[For folks I've just added in Cc, here is the full series:
https://inbox.sourceware.org/libc-alpha/cover.1738530302.git.fweimer@redhat.com/]

On 04/02/2025 15:55, Florian Weimer wrote:
>> [...]
> This means that AArch64 implements the x86-64 protection key semantics
> for signal handling, and not the POWER semantics: all access rights are
> revoked in signal handlers.  (Signal handlers on POWER inherit the
> access rights from the interrupted context.)

I was not aware that POWER handled its pkey register in this way during
signal delivery. For context, I recently changed the way arm64 handles
its pkey register during signal delivery [1]. Before elaborating, let me
first clarify that there are two pkey register values to consider here:

1. The value used while the kernel writes the signal frame (impacting
uaccess routines like put_user())
2. The value set by the kernel just before invoking the signal handler

The second value remains unchanged: full access to pkey 0 and no access
to other pkeys (in line with x86). What [1] did is to remove any
restriction to the first value, so that pkeys never prevent the kernel
from writing the signal frame. This enables the use of an alternate
signal stack mapped with a pkey that isn't accessible to regular code.
That change aligned arm64 with x86, where a similar series landed
earlier [2]. Hopefully POWER does the same thing for that first value -
I don't think pkeys restriction are useful in that situation.

Now focusing on the second value, which is the one userspace actually
sees, when the signal handler is invoked. Simply inheriting they pkey
register from the interrupted context seems undesirable to me:
considering that an asynchronous signal may interrupt any arbitrary
application code, how could a glibc handler possibly rely on that
context's pkey register value (which could be anything)? A signal
handler most likely needs a well-defined pkey configuration, regardless
of what triggers it.

> [...]
>
> We could reset the access rights to the expected values at the start of
> _dl_fixup, _dl_find_object and other dynamic linker functions used in
> signal handlers.  This should allow us crashes in glibc code.  However,
> it will not help with applications that keep around an link map pointer
> (like the l_name string) and use it from signal handlers, or use
> _r_debug from signal handlers.

This is indeed a concern. This currently requires using some sort of
trampoline (on arm64/x86) to reset the pkey register to the desired
value before invoking the actual signal handler - I appreciate this may
not be an option for arbitrary application code.

Introducing a new kernel-user API to configure the pkey register for
signal handlers does feel desirable, but no consensus has emerged on
what that API should actually look like. A sigaltstack() flag has been
suggested [3], but as noted in [4] this may not be appropriate given
that the alternate signal stack is not the only protected mapping that
could be accessed from a signal handler, and your series proves exactly
this point. An alternative would be a new (generic) prctl command, or
maybe a whole new syscall, if that's really warranted.

It's worth noting that x86 does provide a way to configure the initial
pkey register value (init_pkru_value), but this isn't particularly
helpful - it is a system-wide setting, which defines the pkey register
value on both execve() and signal delivery. We need something more
granular and generic.

> [...]
>
> The good news is that this not an architectural limitation, but a choice
> that can be made based on protection key in the Linux implementation
> (controlled by a pkey_alloc flag if necessary).  I had a working kernel
> patch for x86-64 at one point, but I couldn't get it integrated because
> changes were requested that were beyond my kernel knowledge.

I tried to find that patch on lore.kernel.org but failed, would you have
any link handy?

I am Cc'ing folks who have been involved in related discussions on the
kernel mailing lists (please feel free to Cc anyone I might have
missed). Maybe this use-case is exactly what we needed to focus minds
and settle on a new API!

Thanks,
- Kevin

[1]
https://lore.kernel.org/linux-arm-kernel/20241029144539.111155-2-kevin.brodsky@arm.com/
[2]
https://lore.kernel.org/lkml/20240802061318.2140081-1-aruna.ramakrishna@oracle.com/
[3]
https://lore.kernel.org/lkml/CABi2SkWxNkP2O7ipkP67WKz0-LV33e5brReevTTtba6oKUfHRw@mail.gmail.com/
[4] https://lore.kernel.org/linux-arm-kernel/87plns8owh.fsf@arm.com/