linux-kernel - Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Apr 2015 13:53:37 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor
 attribute issue

On Fri, Apr 24, 2015 at 1:21 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> 2. SYSRETQ.  The only way that I know of to see the problem is SYSRETQ
> followed by a far jump or return.  This is presumably *extremely*
> rare.
>
> What if we fixed #2 up in do_stack_segment.  We should double-check
> the docs, but I think that this will only ever manifest as #SS(0) with
> regs->ss == __USER_DS and !user_mode_64bit(regs).

Hmm. It smells a bit "too clever" for me, and in particular, I think
you need a good test-case for this. But yeah, I guess that gets things
out of any possibly critical paths.

That said, I wouldn't even be sure about the SS(0). The rules about
when you get SS and when you get GP are odd.

Also, you need to check what happens when somebody does something like

    movl $-1,%eax
    ss ; movl (%eax),%eax

because I think that gets a #DB(0) too with the situation you expect
to be "unique", because the address wraps.. I dunno.

So care and testing needed. I think the scheduler approach is a *lot*
more obvious, quite frankly.

                      Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/