linux-kernel - Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary

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]

Message-ID: <CA+55aFybpw3TiaojBi0HeTP1VtX1ZnGYVu3EF3-iATRw6uiiCw@mail.gmail.com>
Date:	Thu, 23 Apr 2015 09:05:07 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Brian Gerst <brgerst@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>, 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>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary

On Thu, Apr 23, 2015 at 8:50 AM, Andy Lutomirski <luto@...capital.net> wrote:
> On Thu, Apr 23, 2015 at 8:22 AM, Linus Torvalds
>>
>> It is a bit scary to me that apparently we leak %ss values between
>> processes, so that while we run in the kernel we can randomly have the
>> ss descriptor either be 0 or __KERNEL_DS.  That sounds like an
>> information leak to me, even in 64-bit mode. The value of %ss may not
>> *matter* in 64-bit mode, but leaking that difference between processes
>> sounds nasty. I can't offhand thing of any way to actually read the
>> present bit in the cached descriptor (I was thinking something like
>> the "LSL" instruction, but that takes a new segment selector, not the
>> segment itself), but it just smells odd to me.
>
> How about, in 64-bit code: syscall; long jump to a 32-bit cs; mov with
> ss override (or push or pop).

Yeah. That sounds likely. Something that doesn't reload SS, but gets
us to a point where the present bit matters.

So basically it would allow an "attacker" to see whether it got
scheduled away and an interrupt happened elsewhere.

Which doesn't exactly sound like much of an information leak ("just
read /proc/interrupts instead"), so I guess from a security standpoint
this really doesn't matter.  But I could see how it could break odd
code.

So I think even the 64-bit sysret path has this problem, it's just
that any *sane* 64-bit user will never care. But insane ones could.

And presumably Intel doesn't have this problem, because Intel's sysret
properly loads the whole cached ss descriptor (that's certainly what
the Intel documentation says: "However, the CS and SS descriptor
caches are not loaded from the descriptors (in GDT or LDT) referenced
by those selectors. Instead, the descriptor caches are loaded with
fixed values").

So it sounds very much like an AMD bug/misfeature. Because sysret
*should* reset the descriptor cache. Do we know whether this affects
*all* AMD CPU's or just a subset?

                      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/