Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/05/2018 08:03, Jan Beulich wrote:
>>>> On 04.05.18 at 19:28, <andrew.cooper3@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
>>          return X86EMUL_OKAY;
>>  
>>      case MSR_EFER:
>> -        *val = read_efer();
>> +        /* Hide unknown bits, and unconditionally hide SVME from guests. */
>> +        *val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
>> +        /* Hide the 64-bit features from 32-bit guests. */
>>          if ( is_pv_32bit_domain(currd) )
>>              *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
> Wouldn't it be better then to also move the LMSLE hiding up?

Actually, on second consideration, LMSLE shouldn't be hidden.  If LMSLE
is actually active, then segment descriptors behave differently whether
the guest knows about it or not.

> And what about SCE?

Rather more difficult to say, given its cross-vendor behaviour.  It
should probably be clobbered if 32bit && Intel, but 32bit AMD can use
SYSCALL if it wishes.

>  PV guests not being allowed to write EFER, I would think they shouldn't
> see bits they aren't supposed to care about and aren't able to set. If we
> were to allow such writes, I assume it would only be NX and maybe FFXSE
> which we'd permit the guest to control. Obviously (I think) LME and LMA ought
> to be seen set by 64-bit guests.

I don't see any value in letting PV guests write to EFER.  They never
have been able to in the past, and letting them play with NX has a
direct safety impact on Xen when XPTI is not in use.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel