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

[Linus Torvalds]

On Thu, Apr 23, 2015 at 8:50 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/