https://bugzilla.kernel.org/show_bug.cgi?id=221841
[email protected] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #2 from [email protected] ---
(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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.