This is the mail archive of the
mailing list for the glibc project.
Re: rseq/arm32: choosing rseq code signature
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Will Deacon <will dot deacon at arm dot com>, libc-alpha <libc-alpha at sourceware dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, carlos <carlos at redhat dot com>
- Date: Mon, 15 Apr 2019 09:22:37 -0400 (EDT)
- Subject: Re: rseq/arm32: choosing rseq code signature
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.efficios.com E4EABB7C43
- References: <1050734985.2625.1554838340011.JavaMail.firstname.lastname@example.org> <email@example.com>
----- On Apr 11, 2019, at 8:24 AM, Florian Weimer firstname.lastname@example.org wrote:
> * Mathieu Desnoyers:
>> * TODO: document trap instruction objdump output on each sub-architecture
>> * instruction sets, as well as instruction set extensions.
>> #define RSEQ_SIG 0x########
> Will RSEQ_SIG actually be needed at run time outside the rseq
> implementation library (whether it's glibc or something else)?
Here is how I plan to use it:
- rseq registration performed by glibc,
- rseq critical section abort handlers:
- inlined into applications,
- inlined into libraries.
I plan that it will be mostly used through librseq headers, but inlined
into applications/libraries, which really makes this a fixed ABI once it's
published through public headers.
> Actually rseq users will emit the signature directly into the text
> section, right? They never have to load it into a register, I assume.
The user-space libraries defining rseq critical sections only emit this
signature into their text section. However, the kernel will load that
signature and compare its value before moving the instruction pointer to
the abort handler. So it gets eventually loaded into a register and
compared by the kernel, not by user-space.
> My concern is that on some architectures, the very act of referencing
> RSEQ_SIG will put it into the text section, as a non-instruction, which
> is not what we want.
The kernel knows at which address the RSEQ_SIG sits based on the abort_ip
of the current rseq_cs struct. Getting the address of the abort_ip is performed
through an assembler label.
Note that on arm32, I had to use ".arm\n\t.inst 0xNNNNNNNN" rather than ".long 0xNNNNNNNN"
to ensure the assembler emits the signature as an actual instruction rather than
non-instruction "data". This modifies the content of the symbol table .symtab elf section.