linux-hardening - Re: [RFC PATCH v3 3/5] KVM: x86: Add notifications for Heki policy configuration and violation

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]

Message-ID: <ZjTuqV-AxQQRWwUW@google.com>
Date: Fri, 3 May 2024 07:03:21 -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>, 
	Rick P Edgecombe <rick.p.edgecombe@...el.com>, Alexander Graf <graf@...zon.com>, 
	Angelina Vu <angelinavu@...ux.microsoft.com>, 
	Anna Trikalinou <atrikalinou@...rosoft.com>, Chao Peng <chao.p.peng@...ux.intel.com>, 
	Forrest Yuan Yu <yuanyu@...gle.com>, James Gowans <jgowans@...zon.com>, 
	James Morris <jamorris@...ux.microsoft.com>, John Andersen <john.s.andersen@...el.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>, Thara Gopinath <tgopinath@...rosoft.com>, 
	Trilok Soni <quic_tsoni@...cinc.com>, Wei Liu <wei.liu@...nel.org>, 
	Will Deacon <will@...nel.org>, Yu Zhang <yu.c.zhang@...ux.intel.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: [RFC PATCH v3 3/5] KVM: x86: Add notifications for Heki policy
 configuration and violation

On Fri, May 03, 2024, Mickaël Salaün wrote:
> Add an interface for user space to be notified about guests' Heki policy
> and related violations.
> 
> Extend the KVM_ENABLE_CAP IOCTL with KVM_CAP_HEKI_CONFIGURE and
> KVM_CAP_HEKI_DENIAL. Each one takes a bitmask as first argument that can
> contains KVM_HEKI_EXIT_REASON_CR0 and KVM_HEKI_EXIT_REASON_CR4. The
> returned value is the bitmask of known Heki exit reasons, for now:
> KVM_HEKI_EXIT_REASON_CR0 and KVM_HEKI_EXIT_REASON_CR4.
> 
> If KVM_CAP_HEKI_CONFIGURE is set, a VM exit will be triggered for each
> KVM_HC_LOCK_CR_UPDATE hypercalls according to the requested control
> register. This enables to enlighten the VMM with the guest
> auto-restrictions.
> 
> If KVM_CAP_HEKI_DENIAL is set, a VM exit will be triggered for each
> pinned CR violation. This enables the VMM to react to a policy
> violation.
> 
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Dave Hansen <dave.hansen@...ux.intel.com>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Madhavan T. Venkataraman <madvenka@...ux.microsoft.com>
> Cc: Paolo Bonzini <pbonzini@...hat.com>
> Cc: Sean Christopherson <seanjc@...gle.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Vitaly Kuznetsov <vkuznets@...hat.com>
> Cc: Wanpeng Li <wanpengli@...cent.com>
> Signed-off-by: Mickaël Salaün <mic@...ikod.net>
> Link: https://lore.kernel.org/r/20240503131910.307630-4-mic@digikod.net
> ---
> 
> Changes since v1:
> * New patch. Making user space aware of Heki properties was requested by
>   Sean Christopherson.

No, I suggested having userspace _control_ the pinning[*], not merely be notified
of pinning.

 : 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.

I stand by that suggestion, because I don't see a sane way to handle things like
kexec() and reboot without having a _much_ more sophisticated policy than would
ever be acceptable in KVM.

I think that can be done without KVM having any awareness of CR pinning whatsoever.
E.g. userspace just needs to ability to intercept CR writes and inject #GPs.  Off
the cuff, I suspect the uAPI could look very similar to MSR filtering.  E.g. I bet
userspace could enforce MSR pinning without any new KVM uAPI at all.

[*] https://lore.kernel.org/all/ZFUyhPuhtMbYdJ76@google.com