Re: [RFC PATCH] x86/cpu: Fix MSR value truncation issue

[Andy Lutomirski]

On Wed, Nov 11, 2015 at 4:31 AM, Borislav Petkov <bp@xxxxxxxxx> 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
--
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/