[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |