Re: [Xen-devel] [PATCH 2/4] x86/setup: Minor cleanup to host SYSCALL MSR handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/02/17 15:19, Jan Beulich wrote:
>>>> On 13.02.17 at 15:32, <andrew.cooper3@xxxxxxxxxx> wrote:
>> Xen's choice of the MSR_STAR value is constant across all pcpus.  Introduce a
>> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
>> and restore_rest_processor_state().
>>
>> Despite Intel hardware having an MSR_CSTAR register, nothing actually uses it
>> as the SYSCALL instruction raises #UD out of 64bit mode, meaning that
> Did you mean "32-bit"?

SYSCALL on Intel will #UD if CS.L == 0, so you can't even use it from a
compatability mode segment.

>
>> MSR_LSTAR is the only %rip value hardware will use.
>>
>> Therefore, only create a CSTAR trampoline stub, and save/restore the CSTAR
>> value across suspend/resume on AMD hardware.  MSR_CSTAR should now be
>> consistently 0 on Intel hardware.
> It's not documented to be zero when coming out of reset, and
> you never write zero to it.
>
> Plus, if there would be an Intel CPU supporting compat mode
> SYSCALL, we'd end up with PV guests having a way to transfer
> control to ring 0 execution at RIP 0. Sadly the instruction doesn't
> #GP(0) on a null selector found in STAR, so I think we need to
> keep storing a valid pointer into CSTAR as long as we set
> EFER.SCE (which we can't really avoid).

Ok.  All good points.  I will drop this part of the patch and keep it
set up unconditionally.  This doesn't actually affect the rest of the
series.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel