On 5/31/23 04:14, Peter Zijlstra wrote:
On Tue, May 30, 2023 at 08:52:32PM +0200, Peter Zijlstra wrote:
That should really say that a nested #HV should never be raised by the
hypervisor, but if it is, then the guest should detect that and
self-terminate knowing that the hypervisor is possibly being malicious.
I've yet to see code that can do that reliably.
Tom; could you please investigate if this can be enforced in ucode?
Ideally #HV would have an internal latch such that a recursive #HV will
terminate the guest (much like double #MC and tripple-fault).
But unlike the #MC trainwreck, can we please not leave a glaring hole in
this latch and use a spare bit in the IRET frame please?
So have #HV delivery:
- check internal latch; if set, terminate machine
- set latch
- write IRET frame with magic bit set
have IRET:
- check magic bit and reset #HV latch
Hi Peter,
I talked with the hardware team about this and, unfortunately, it is not
practical to implement. The main concerns are that there are already two
generations of hardware out there with the current support and, given
limited patch space, in addition to the ucode support to track and perform
the latch support, additional ucode support would be required to
save/restore the latch information when handling a VMEXIT during #HV
processing.
Thanks,
Tom
