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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 15 Apr 2019 09:22:37 -0400 (EDT)
From:   Mathieu Desnoyers <>
To:     Florian Weimer <>
Cc:     Will Deacon <>,
        libc-alpha <>,
        linux-kernel <>,
        carlos <>
Subject: Re: 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.

Powered by blists - more mailing lists