On Fri, May 05, 2023, Micka�l Sala�n wrote: > > 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? Host userspace, a.k.a. the VMM. Definitely not guest userspace. > 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? I think we're on the same page, the VMM (host userspace) would need to ack any changes. FWIW, SMM is another wart as entry to SMM clobbers CRs. Now that CONFIG_KVM_SMM is a thing, the easiest solution would be to disallow coexistence with SMM, though that might not be an option for many use cases (IIUC, QEMU-based deployments use SMM to implement secure boot). > > 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? Host userspace. Guest configures a device buffer in write-protected memory, gets a host (synthetic) device to write into the memory.
