Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss

[Andy Lutomirski]

On Thu, Apr 23, 2015 at 3:44 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> On Thu, Apr 23, 2015 at 12:26:43PM +0200, Denys Vlasenko wrote:
>> Yes. It loads *selector*. AMD docs say that selector is loaded as you say,
>> but *cached descriptor* of SS (which is a different entity) is not modified.
>>
>> If *cached descriptor* is invalid, in 32-bit mode stack ops
>> will fail. (In 64-bit mode, CPU doesn't do those checks).
>
> So how can that happen with wine? Something's changing the cached
> descriptor and only the write to %ss reloads it with the correct value?
>

I bet that the actual crashing task is a red herring.  How about this theory:

Some *other* Wine program is running either in 16-bit mode or in
32-bit mode with the stack limit != 0xffffffff.  We take an interrupt
and, as an optimization, the CPU doesn't reset the cached SS limit
and/or attributes (what would it reload them to, anyway?).  Now we
context switch to a syscall issues by the dying task and do sysretl,
and we accidentally land back in userspace in segmented mode.

If this theory is right, it explains why we only see this on Wine.  It
also means we may have an info leak on 64-bit syscalls, too (see other
thread).

A test for this would be to run syscalls in a loop in a native 32-bit
process while running dosbox or something like that.

--Andy


> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/