[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190410065417.GU11158@hirez.programming.kicks-ass.net>
Date: Wed, 10 Apr 2019 08:54:17 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...capital.net>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
libc-alpha <libc-alpha@...rceware.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Carlos O'Donell <carlos@...hat.com>, x86 <x86@...nel.org>
Subject: Re: rseq/x86: choosing rseq code signature
On Tue, Apr 09, 2019 at 04:43:42PM -0400, Mathieu Desnoyers wrote:
> +/*
> + * 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)
> + */
Right, and the alternative is: 0f b9 3d $SIG, which decodes to:
UD1 $SIG(%rip),%edi
which will trap unconditionally. The only problem is that gas will not
actually assemble it, but since we're .byte coding it, it doesn't
matter.
UD1 is specified by both AMD and Intel to take a ModR/M, unlike UD0
where they disagree on the ModR/M.
Powered by blists - more mailing lists