lkml.org 
[lkml]   [2015]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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


\
 
 \ /
  Last update: 2015-11-11 17:01    [W:0.069 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site