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

[Andy Lutomirski]

On Thu, Apr 23, 2015 at 11:52 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> On Thu, Apr 23, 2015 at 11:24:14AM -0700, Andy Lutomirski wrote:
>> That nails it.  We really do leak segment limits to other tasks on AMD
>> chips.  I see at least two questions we should answer before fixing
>> this:
>
> Ok, WTF is going on?! Even this trivial test case causes a Bus Error:
>
> ---
> static unsigned short GDT3(int idx)
> {
>         return (idx << 3) | 3;
> }
>
> static void *threadproc(void *ctx)
> {
>         printf("Hello world\n");
>         return NULL;
> }
>
> int main()
> {
>         pthread_t thread;
>         if (pthread_create(&thread, 0, threadproc, 0) != 0)
>                 err(1, "pthread_create");
>
>         while (1) {
>                 usleep(1);
>         }
>
>         return 0;
> }
> ---
>
> $ make sysret_ss_attrs_32
> gcc -m32 -o sysret_ss_attrs_32 -O2 -g -std=gnu99 -pthread -Wall  sysret_ss_attrs.c -lrt -ldl
> sysret_ss_attrs.c:23:23: warning: âGDT3â defined but not used [-Wunused-function]
>  static unsigned short GDT3(int idx)
>                        ^
> $ taskset -c 0 ./sysret_ss_attrs_32
> Hello world
> Bus error
>
> in dmesg:
>
> [  583.389368] traps: sysret_ss_attrs[2135] trap stack segment ip:f7784b87 sp:ffb640c0 error:0
>
> This is insane.
>
>> 1. Do we consider this to be enough of a security issue that we want
>> to fix it for 64-bit userspace as well?
>>
>> 2. Do we fix it at sysret time (at the cost of an ss read even in the
>> best case on AMD chips) or at context switch time (with the risk of
>> more ss writes than necessary)?
>>
>> I slightly favor fixing it at sysret time for both the 32-bit and
>> 64-bit paths., but I'm not really convinced.
>
> Yeah, a "call amd_fixup_ss" which gets NOPped out on Intel with
> alternatives sounds nice and clean to me.
>
> Pending we have an explanation WTH is going on...

Huh, what?  Maybe interrupt delivery on AMD CPUs actually blows away
the descriptor cache completely.

On VMX, at least, it's possible to read the descriptor cache directly.
I wonder whether the KVM SVM code could be instrumented to do
something similar.

--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/