linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Zack Weinberg <zackw@panix.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	libc-alpha <libc-alpha@sourceware.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Carlos O'Donell" <carlos@redhat.com>, x86 <x86@kernel.org>
Subject: Re: rseq/x86: choosing rseq code signature
Date: Tue, 9 Apr 2019 18:57:09 -0700	[thread overview]
Message-ID: <CALCETrUScoGHPP9avQDSWhfJtxrSxFYy0z=AQNM-61ECLUK+PA@mail.gmail.com> (raw)
In-Reply-To: <CAKCAbMi6ZM0ehUrjxNfjR+SV_Xv_x7JkMjvB9nEVH=31JHNEPg@mail.gmail.com>

On Tue, Apr 9, 2019 at 5:51 PM Zack Weinberg <zackw@panix.com> wrote:
>
> On Tue, Apr 9, 2019 at 4:43 PM Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> > ----- On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
> > >
> > > 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.
> > >
> > > Currently, tools/testing/selftests/rseq/rseq-x86.h defines RSEQ_SIG
> > > as 0x53053053, and uses it as an immediate operand to the following
> > > instruction opcodes (as suggested by Andy Lutomirski):
> > >
> > > x86-32:
> > > - .byte 0x0f, 0x1f, 0x05: nopl <sig>
> > >
> > > x86-64:
> > > - .byte 0x0f, 0x1f, 0x05: nopl <sig>(%rip)
> > >
> > > 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.
> ...
> > Peter Zijlstra suggested to use "invlpg" in user-space, which should generate
> > a trap. The only concern would be emulators, but ideally they would not try to
> > decode an instruction that is never executed. This would lead to the following
> > patch. Any objections/ack ?
> ...
> > +/*
> > + * RSEQ_SIG is used with the following privileged instructions, which trap in user-space:
> > + * x86-32:    0f 01 3d 53 30 05 53      invlpg 0x53053053
> > + * x86-64:    0f 01 3d 53 30 05 53      invlpg 0x53053053(%rip)
> > + */
> >  #define RSEQ_SIG       0x53053053
>
> On x86, you have to worry about what happens if control flow gets
> redirected to an arbitrary byte address.  The proposed sequence `0f 01
> 3d 53 30 05 53` is a trap instruction if control lands seven bytes
> before the beginning of the abort handler, but if it lands anywhere
> _else_ within the marker sequence, you get one of these instruction
> sequences, none of which trap, all but one of which will corrupt the
> process state, and three of which will consume three bytes from the
> beginning of the abort handler's code, continuing execution with a
> misaligned PC:
>
>     01 3d 53 30 05 53        add %edi,0x53053053(%rip)
>     3d 53 30 05 53           cmp $0x53053053,%eax
>     53 30 05 53 XX XX XX     push %rbx; xor %al,0xXXXXXX78(%rip)
>     30 05 53 XX XX XX        xor %al,0xXXXXXX78(%rip)
>     05 53 XX XX XX           add $0xXXXXXX53,%eax
>     53                       push %rbx
>
> So I'm going to suggest instead the four-byte sequence CD CF CD CF.
> That's INT $0xCF if control lands either two or four bytes before the
> beginning of the abort handler, and IRET if it lands one or three
> bytes before.  I believe both of these possibilities are currently
> also forbidden in user mode.  It doesn't need to be longer, does it?
>

IRET works in user mode just fine.  Why are you concerned about
landing in the middle of the signature?  A misaligned jump into code
is screwy pretty much no matter what.  It does seem genuinely useful
to trap if you accidentally fall through to the beginning of the
signature, but I don't see the point of worrying about jumping to the
middle.

There's some argument that, for consistency with CET, the last couple
bytes of the signature should match ENDBR.

Mathieu, how many bytes do we have for the signature?

  reply	other threads:[~2019-04-10  1:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 19:32 rseq/x86: choosing rseq code signature Mathieu Desnoyers
2019-04-09 20:43 ` Mathieu Desnoyers
2019-04-10  0:50   ` Zack Weinberg
2019-04-10  1:57     ` Andy Lutomirski [this message]
2019-04-10  4:19       ` Mathieu Desnoyers
2019-04-10  6:54   ` Peter Zijlstra
2019-04-10 15:47     ` Mathieu Desnoyers
2019-04-10 17:57       ` Peter Zijlstra
2019-04-10 18:05         ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrUScoGHPP9avQDSWhfJtxrSxFYy0z=AQNM-61ECLUK+PA@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=carlos@redhat.com \
    --cc=hpa@zytor.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=zackw@panix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).