linux-kernel - Re: [PATCH v1 4/9] KVM: x86: Add new hypercall to set EPT permissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 May 2023 10:17:59 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     "Mickaël Salaün" <mic@...ikod.net>
Cc:     Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Alexander Graf <graf@...zon.com>,
        Forrest Yuan Yu <yuanyu@...gle.com>,
        James Morris <jamorris@...ux.microsoft.com>,
        John Andersen <john.s.andersen@...el.com>,
        Liran Alon <liran.alon@...cle.com>,
        "Madhavan T . Venkataraman" <madvenka@...ux.microsoft.com>,
        Marian Rotariu <marian.c.rotariu@...il.com>,
        "Mihai Donțu" <mdontu@...defender.com>,
        "Nicușor Cîțu" <nicu.citu@...oud.com>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Thara Gopinath <tgopinath@...rosoft.com>,
        Will Deacon <will@...nel.org>,
        Zahra Tarkhani <ztarkhani@...rosoft.com>,
        "Ștefan Șicleru" <ssicleru@...defender.com>,
        dev@...ts.cloudhypervisor.org, kvm@...r.kernel.org,
        linux-hardening@...r.kernel.org, linux-hyperv@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, qemu-devel@...gnu.org,
        virtualization@...ts.linux-foundation.org, x86@...nel.org,
        xen-devel@...ts.xenproject.org
Subject: Re: [PATCH v1 4/9] KVM: x86: Add new hypercall to set EPT permissions

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.