Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 11 Nov 2015 07:50:04 -0800 | Subject | Re: [RFC PATCH] x86/cpu: Fix MSR value truncation issue |
| |
On Wed, Nov 11, 2015 at 4:31 AM, Borislav Petkov <bp@alien8.de> wrote: > On Fri, Oct 30, 2015 at 06:28:25PM +0100, Borislav Petkov wrote: >> More specifically, MSR_STAR[31:0] is being set to 0. That field is >> reserved on Intel and on AMD it is 32-bit SYSCALL Target EIP. >> >> I'd strongly guess because Intel doesn't have SYSCALL in compat/legacy >> mode and we're using SYSENTER and INT80 there. And for compat syscalls >> in long mode we use CSTAR. > > So I was wondering what would happen if I used SYSCALL on 32-bit AMD. > > This is what happens on a normal system: > > $ strace -f ./syscall > execve("./syscall", ["./syscall"], [/* 24 vars */]) = 0 > --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x80480e8} --- > +++ killed by SIGILL +++ > Illegal instruction > > Wondering who causes the SIGILL and after some code staring, it is MSR > EFER.SCE which we don't enable on 32-bit. > > And, because I like to cause fire (woahahahah... /me rubs hands and > laughs ominously), I went and toggled that bit. > > Oh well, we bomb out, as expected: >
Not terribly surprising :) Someone (I forget who) told me that 32-bit SYSCALL (native 32-bit, not compat) was so full of errata that it was unusable. Even without errata, I don't really see how it would work well -- there's no MSR_SYSCALL_MASK, so we can't mask off TF when SYSCALL happens, and I don't see how we're expected to handle SYSCALL with TF set on a 32-bit kernel unless we route #DB through a task gate, which I'm reasonably confident no one wants to do.
--Andy
| |