[lkml]   [2019]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: rseq/arm32: choosing rseq code signature
----- On Apr 11, 2019, at 8:24 AM, Florian Weimer 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.



Mathieu Desnoyers
EfficiOS Inc.

 \ /
  Last update: 2019-04-15 15:22    [W:0.056 / U:11.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site