mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome