On 05/05/2023 18:44, Sean Christopherson wrote:
On Fri, May 05, 2023, Micka�l Sala�n wrote:
Add a new KVM_HC_LOCK_MEM_PAGE_RANGES hypercall that enables a guest to
set EPT permissions on a set of page ranges.
IMO, manipulation of protections, both for memory (this patch) and CPU state
(control registers in the next patch) should come from userspace. I have no
objection to KVM providing plumbing if necessary, but I think userspace needs to
to have full control over the actual state.
By user space, do you mean the host user space or the guest user space?
About the guest user space, I see several issues to delegate this kind
of control:
- These are restrictions only relevant to the kernel.
- The threat model is to protect against user space as early as possible.
- It would be more complex for no obvious gain.
This patch series is an extension of the kernel self-protections
mechanisms, and they are not configured by user space.
One of the things that caused Intel's control register pinning series to stall
out was how to handle edge cases like kexec() and reboot. Deferring to userspace
means the kernel doesn't need to define policy, e.g. when to unprotect memory,
and avoids questions like "should userspace be able to overwrite pinned control
registers".
The idea is to authenticate every changes. For kexec, the VMM (or
something else) would have to authenticate the new kernel. Do you have
something else in mind that could legitimately require such memory or CR
changes?
And like the confidential VM use case, keeping userspace in the loop is a big
beneifit, e.g. the guest can't circumvent protections by coercing userspace into
writing to protected memory .
I don't understand this part. Are you talking about the host user space?
How the guest could circumvent protections?
