Re: [Xen-devel] [PATCH 4/4] x86/pv: Expose RDTSCP to PV guests

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.11.18 at 12:29, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 20/11/2018 11:06, Jan Beulich wrote:
>>>>> On 15.11.18 at 22:47, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> The final remnanat of PVRDTSCP is that we would emulate RDTSCP even on
>>> hardware which lacked the instruction.  RDTSCP is available on almost all
>>> 64-bit x86 hardware.
>>>
>>> Remove this emulation, drop the TSC_MODE_PVRDTSCP constant, and allow RDTSCP
>>> in a PV guest's CPUID policy.
>> Why would we not want to emulate the insn when unavailable, when
>> it's generally useful to guests?
> 
> For exactly the same kind of safety reasons as for why we don't tolerate
> doing this in HVM guests in general.

But imo we should start doing so for certain features. In particular
I think we had agreed to try to support UMIP even on incapable
hardware. You had merely asked to postpone my patch to this
effect until more of the CPUID infrastructure was in place (which
afaict it still isn't).

> As it stands, it is an unnecessary attack surface, and if we were to
> re-introduce the functionality (not that I can see a valid reason to),
> it should use x86_emulate() rather than opencoding the logic.

How much larger is the attack surface of emulate_invalid_rdtscp()
compared to emulate_forced_invalid_op()?

Jan



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