All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Vlasenko <dvlasenk@redhat.com>
To: Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Denys Vlasenko <vda.linux@googlemail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Brian Gerst <brgerst@gmail.com>, Ingo Molnar <mingo@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Alexei Starovoitov <ast@plumgrid.com>,
	Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue
Date: Mon, 27 Apr 2015 12:07:14 +0200	[thread overview]
Message-ID: <553E0A52.7070400@redhat.com> (raw)
In-Reply-To: <20150427085305.GB6774@pd.tnic>

On 04/27/2015 10:53 AM, Borislav Petkov wrote:
> On Sun, Apr 26, 2015 at 04:39:38PM -0700, Andy Lutomirski wrote:
>>> +#define X86_BUG_CANONICAL_RCX  X86_BUG(8) /* SYSRET #GPs when %RCX non-canonical */
>>
>> I think that "sysret" should appear in the name.
> 
> Yeah, I thought about it too, will fix.
> 
>> Oh no!  My laptop is currently bug-free, and you're breaking it! :)
> 
> Muahahahhahaha...
> 
>>> +
>>> +       /*
>>> +        * On Intel CPUs, SYSRET with non-canonical RCX/RIP will #GP
>>> +        * in kernel space.  This essentially lets the user take over
>>> +        * the kernel, since userspace controls RSP.
>>> +        */
>>> +       ALTERNATIVE "jmp 1f", "", X86_BUG_CANONICAL_RCX
>>> +
>>
>> I know it would be ugly, but would it be worth saving two bytes by
>> using ALTERNATIVE "jmp 1f", "shl ...", ...?
>>
>>>         /* Change top 16 bits to be the sign-extension of 47th bit */
>>>         shl     $(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
>>>         sar     $(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
>>> @@ -432,6 +436,7 @@ syscall_return:
>>>         cmpq    %rcx, %r11
>>>         jne     opportunistic_sysret_failed
> 
> You want to stick all 4 insns in the alternative? Yeah, it should work
> but it might even more unreadable than it is now.
> 
> Btw, we can do this too:
> 
> 	ALTERNATIVE "",
> 		    "shl     $(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx \
> 		     sar     $(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx \
> 		     cmpq    %rcx, %r11 \
> 		     jne     opportunistic_sysret_failed"
> 		     X86_BUG_SYSRET_CANONICAL_RCX
> 
> which will replace the 2-byte JMP with a lot of NOPs on AMD.

The instructions you want to NOP out are translated to these bytes:

     2c2:       48 c1 e1 10             shl    $0x10,%rcx
     2c6:       48 c1 f9 10             sar    $0x10,%rcx
     2ca:       49 39 cb                cmp    %rcx,%r11
     2cd:       75 5f                   jne    32e <opportunistic_sysret_failed>

According to http://instlatx64.atw.hu/
CPUs from both AMD and Intel are happy to eat "66,66,66,90" NOPs
with maximum throughput; more than three 66 prefixes slow decode down,
sometimes horrifically (from 3 insns per cycle to one insn per ~10 cycles).

Probably doing something like this

	/* Only three 0x66 prefixes for NOP for fast decode on all CPUs */
	ALTERNATIVE	".byte 0x66,0x66,0x66,0x90 \
			.byte 0x66,0x66,0x66,0x90 \
			.byte 0x66,0x66,0x66,0x90",
			"shl	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx \
			sar	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx \
			cmpq	%rcx, %r11 \
			jne	opportunistic_sysret_failed"
			X86_BUG_SYSRET_CANONICAL_RCX

would be better than letting ALTERNATIVE to generate 13 one-byte NOPs.

-- 
vda


  reply	other threads:[~2015-04-27 10:07 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24  2:15 [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue Andy Lutomirski
2015-04-24  2:18 ` Andy Lutomirski
2015-04-26 12:34   ` Denys Vlasenko
2015-04-24  3:58 ` Brian Gerst
2015-04-24  9:59 ` Denys Vlasenko
2015-04-24 10:59   ` Borislav Petkov
2015-04-24 19:58     ` Borislav Petkov
2015-04-24 11:27 ` Denys Vlasenko
2015-04-24 12:00   ` Brian Gerst
2015-04-24 16:25     ` Linus Torvalds
2015-04-24 17:33       ` Brian Gerst
2015-04-24 17:41         ` Linus Torvalds
2015-04-24 17:57           ` Brian Gerst
2015-04-24 20:21 ` Andy Lutomirski
2015-04-24 20:46   ` Denys Vlasenko
2015-04-24 20:50     ` Andy Lutomirski
2015-04-24 21:45       ` H. Peter Anvin
2015-04-24 21:45       ` H. Peter Anvin
2015-04-24 21:45       ` H. Peter Anvin
2015-04-24 21:45       ` H. Peter Anvin
2015-04-24 21:45       ` H. Peter Anvin
2015-04-24 21:45       ` H. Peter Anvin
2015-04-25  2:17       ` Denys Vlasenko
2015-04-26 23:36         ` Andy Lutomirski
2015-04-24 20:53   ` Linus Torvalds
2015-04-25 21:12 ` Borislav Petkov
2015-04-26 11:22   ` perf numbers (was: Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue) Borislav Petkov
2015-04-26 23:39   ` [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue Andy Lutomirski
2015-04-27  8:53     ` Borislav Petkov
2015-04-27 10:07       ` Denys Vlasenko [this message]
2015-04-27 10:09         ` Borislav Petkov
2015-04-27 11:35       ` Borislav Petkov
2015-04-27 12:08         ` Denys Vlasenko
2015-04-27 12:48           ` Borislav Petkov
2015-04-27 14:57         ` Linus Torvalds
2015-04-27 15:06           ` Linus Torvalds
2015-04-27 15:35             ` Borislav Petkov
2015-04-27 15:46           ` Borislav Petkov
2015-04-27 15:56             ` Andy Lutomirski
2015-04-27 16:04               ` Brian Gerst
2015-04-27 16:10                 ` Denys Vlasenko
2015-04-27 16:00             ` Linus Torvalds
2015-04-27 16:40               ` Borislav Petkov
2015-04-27 18:14                 ` Linus Torvalds
2015-04-27 18:38                   ` Borislav Petkov
2015-04-27 18:47                     ` Linus Torvalds
2015-04-27 18:53                       ` Borislav Petkov
2015-04-27 19:59                         ` H. Peter Anvin
2015-04-27 20:03                           ` Borislav Petkov
2015-04-27 20:14                             ` H. Peter Anvin
2015-04-28 15:55                               ` Borislav Petkov
2015-04-28 16:28                                 ` Linus Torvalds
2015-04-28 16:58                                   ` Borislav Petkov
2015-04-28 17:16                                     ` Linus Torvalds
2015-04-28 18:38                                       ` Borislav Petkov
2015-04-30 21:39                                         ` H. Peter Anvin
2015-04-30 23:23                                           ` H. Peter Anvin
2015-05-01  9:03                                             ` Borislav Petkov
2015-05-03 11:51                                           ` Borislav Petkov
2015-04-27 19:11                     ` Borislav Petkov
2015-04-27 19:21                       ` Denys Vlasenko
2015-04-27 19:45                         ` Borislav Petkov
2015-04-28 13:40                           ` Borislav Petkov
2015-04-27 16:12           ` Denys Vlasenko
2015-04-27 18:12             ` Linus Torvalds
2015-04-27 18:47               ` Borislav Petkov
2015-04-27 14:39     ` Borislav Petkov

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=553E0A52.7070400@redhat.com \
    --to=dvlasenk@redhat.com \
    --cc=ast@plumgrid.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    --cc=wad@chromium.org \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.