[Bug 221841] KVM: nested VMX eVMCS VMPTRLD/VMPTRST causes infinite VM-Exit loop due to missing RIP advance

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221841

vkuznets@redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vkuznets@redhat.com

--- Comment #2 from vkuznets@redhat.com ---
(In reply to Sean Christopherson from comment #1)

> > 
> > A malicious L1 guest can continuously trigger VM-Exit handling and consume
> > host CPU resources, resulting in denial of service.
> 
> No, it doesn't.  There are no "host CPU" vs. "guest CPU" resources, it's all
> just physical CPU resources.  Whether the CPU is running guest code or host
> code
> is irrelevant.  What matters is that KVM honors NEED_RESCHED (especially on
> non-preemptible kernels, i.e. before PREEMPT_LAZY came along), which it very
> much does in the slow path VM-Entry/VM-Exit loop.
> 
> > The issue affects availability only.
> 
> Only the availibility of the L1 hypervisor.

Yes, basically, misbehaving L1 hypervisor can shoot itself in the foot.

> 
> > Technical analysis:
> > 
> > The eVMCS path should behave similarly to other unsupported nested VMX
> > instructions.
> 
> Only if the TLFS allows it.  I assume it just says "unsupported" or
> "undefined behavior", i.e. KVM can probably do whatever it wants.  Vitaly?

VMREAD/VMWRITE with eVMCS are explicitly called 'unsupported' in the TLFS:

"Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
unsupported and can result in unexpected behavior.". 

As for VMPTRLD, we only have
"No VMPTRLD instruction must be executed to make an enlightened VMCS active or
current." but there's nothing about the expected result there. VMPTRST is not
mentioned. 

So I guess we can do whatever we want in KVM and skipping the instruction is
not a bad thing. Ideally, we can try and see what genuine Hyper-V gives us in
this situation (by e.g. running an instrumented version of KVM there). It does
not seem that we have an extreme urgency here so I can put it to my backlog and
try to get to it some time next week -- unless someone beats me to it of
course!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.