On Wed, Oct 20, 2021, Brijesh Singh wrote:
On 10/15/21 2:50 PM, Sean Christopherson wrote:
quoted
And digging through the guest patches, this gives the guest _full_ control over
the VMSA contents. That is bonkers. At _best_ it gives the guest the ability to
fuzz VMRUN ucode by stuffing garbage into the VMSA.
If guest puts garbage in VMSA then VMRUN will fail. I am sure ucode is
doing all kind of sanity checks to ensure that VMSA does not contain
invalid value before the run.
Oh, I'm well aware of the number of sanity checks that are in VM-Enter ucode, and
that's precisely why I'm of the opinion that letting the guest fuzz VMRUN is a
non-trivial security risk for the host. I know of at least at least two VMX bugs
(one erratum that I could find, one that must have been fixed with a ucode patch?)
where ucode failed to detect invalid state. Those were "benign" in that they
caused a missed VM-Fail but didn't corrupt CPU state, but it's not a stretch to
imagine a ucode bug that leads to corruption of CPU state and a system crash.
The sheer number of checks involved, combined with the fact that there likely
hasn't been much fuzzing of VM-Enter outside of the hardware vendor's own
validation, means I'm not exactly brimming with confidence that VMRUN's ucode
is perfect.
I fully acknowledge that the host kernel obviously "trusts" CPU ucode to a great
extent. My point here is that the design exposes the host to unnecessary risk.