[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1 4/9] KVM: x86: Add new hypercall to set EPT permissions
- To: "Mickaël Salaün" <mic@xxxxxxxxxxx>
- From: Sean Christopherson <seanjc@xxxxxxxxxx>
- Date: Fri, 5 May 2023 09:44:52 -0700
- Cc: Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, "H . Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>, Wanpeng Li <wanpengli@xxxxxxxxxxx>, Alexander Graf <graf@xxxxxxxxxx>, Forrest Yuan Yu <yuanyu@xxxxxxxxxx>, James Morris <jamorris@xxxxxxxxxxxxxxxxxxx>, John Andersen <john.s.andersen@xxxxxxxxx>, Liran Alon <liran.alon@xxxxxxxxxx>, "Madhavan T . Venkataraman" <madvenka@xxxxxxxxxxxxxxxxxxx>, Marian Rotariu <marian.c.rotariu@xxxxxxxxx>, "Mihai Donțu" <mdontu@xxxxxxxxxxxxxxx>, "Nicușor Cîțu" <nicu.citu@xxxxxxxxxx>, Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>, Thara Gopinath <tgopinath@xxxxxxxxxxxxx>, Will Deacon <will@xxxxxxxxxx>, Zahra Tarkhani <ztarkhani@xxxxxxxxxxxxx>, "Ștefan Șicleru" <ssicleru@xxxxxxxxxxxxxxx>, dev@xxxxxxxxxxxxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx, linux-hardening@xxxxxxxxxxxxxxx, linux-hyperv@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-security-module@xxxxxxxxxxxxxxx, qemu-devel@xxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Fri, 05 May 2023 16:45:08 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
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".
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 .
|