linux-kernel - rseq/s390: choosing code signature

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:   Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     heiko carstens <heiko.carstens@...ibm.com>,
        schwidefsky <schwidefsky@...ibm.com>, gor <gor@...ux.ibm.com>
Cc:     libc-alpha <libc-alpha@...rceware.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Carlos O'Donell <carlos@...hat.com>
Subject: rseq/s390: choosing code signature

Hi,

We are about to include the code signature required prior to restartable
sequences abort handlers into glibc, which will make this ABI choice final.
We need architecture maintainer input on that signature value.

That code signature is placed before each abort handler, so the kernel can
validate that it is indeed jumping to an abort handler (and not some
arbitrary attacker-chosen code). The signature is never executed.

The current discussion thread on the glibc mailing list leads us towards
using a trap with uncommon immediate operand, which simplifies integration
with disassemblers, emulators, makes it easier to debug if the control
flow gets redirected there by mistake, and is nicer for some architecture's
speculative execution.

We can have different signatures for each sub-architecture, as long as they
don't have to co-exist within the same process. We can special-case with
#ifdef for each sub-architecture and endianness if need be. If the architecture
has instruction set extensions that can co-exist with the architecture
instruction set within the same process, we need to take into account to which
instruction the chosen signature value would map (and possibly decide if we
need to extend rseq to support many signatures).

Here is an example of rseq signature definition template:

/*
 * TODO: document trap instruction objdump output on each sub-architecture
 * instruction sets, as well as instruction set extensions.
 */
#define RSEQ_SIG 0x########

Ideally we'd need a patch on top of the Linux kernel
tools/testing/selftests/rseq/rseq-s390.h file that updates
the signature value, so I can then pick it up for the glibc
patchset.

Thanks!

Mathieu

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