| 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
| ||
|
Message-ID: <aQRyyieyDrZZMpIt@yzhao56-desk.sh.intel.com>
Date: Fri, 31 Oct 2025 16:26:50 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Marc Zyngier <maz@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>,
Tianrui Zhao <zhaotianrui@...ngson.cn>, Bibo Mao <maobibo@...ngson.cn>,
Huacai Chen <chenhuacai@...nel.org>, Madhavan Srinivasan
<maddy@...ux.ibm.com>, Anup Patel <anup@...infault.org>, Paul Walmsley
<pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
<aou@...s.berkeley.edu>, Christian Borntraeger <borntraeger@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>, Claudio Imbrenda
<imbrenda@...ux.ibm.com>, Paolo Bonzini <pbonzini@...hat.com>, "Kirill A.
Shutemov" <kas@...nel.org>, <linux-arm-kernel@...ts.infradead.org>,
<kvmarm@...ts.linux.dev>, <kvm@...r.kernel.org>, <loongarch@...ts.linux.dev>,
<linux-mips@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
<kvm-riscv@...ts.infradead.org>, <linux-riscv@...ts.infradead.org>,
<x86@...nel.org>, <linux-coco@...ts.linux.dev>,
<linux-kernel@...r.kernel.org>, Ira Weiny <ira.weiny@...el.com>, Kai Huang
<kai.huang@...el.com>, Binbin Wu <binbin.wu@...ux.intel.com>, Michael Roth
<michael.roth@....com>, Vishal Annapurve <vannapurve@...gle.com>, "Rick
Edgecombe" <rick.p.edgecombe@...el.com>, Ackerley Tng
<ackerleytng@...gle.com>
Subject: Re: [PATCH v4 26/28] KVM: TDX: Guard VM state transitions with "all"
the locks
On Thu, Oct 30, 2025 at 01:09:49PM -0700, Sean Christopherson wrote:
> Acquire kvm->lock, kvm->slots_lock, and all vcpu->mutex locks when
> servicing ioctls that (a) transition the TD to a new state, i.e. when
> doing INIT or FINALIZE or (b) are only valid if the TD is in a specific
> state, i.e. when initializing a vCPU or memory region. Acquiring "all"
> the locks fixes several KVM_BUG_ON() situations where a SEAMCALL can fail
> due to racing actions, e.g. if tdh_vp_create() contends with either
> tdh_mr_extend() or tdh_mr_finalize().
>
> For all intents and purposes, the paths in question are fully serialized,
> i.e. there's no reason to try and allow anything remotely interesting to
> happen. Smack 'em with a big hammer instead of trying to be "nice".
>
> Acquire kvm->lock to prevent VM-wide things from happening, slots_lock to
> prevent kvm_mmu_zap_all_fast(), and _all_ vCPU mutexes to prevent vCPUs
s/kvm_mmu_zap_all_fast/kvm_mmu_zap_memslot
> from interefering. Use the recently-renamed kvm_arch_vcpu_unlocked_ioctl()
> to service the vCPU-scoped ioctls to avoid a lock inversion problem, e.g.
> due to taking vcpu->mutex outside kvm->lock.
>
> See also commit ecf371f8b02d ("KVM: SVM: Reject SEV{-ES} intra host
> migration if vCPU creation is in-flight"), which fixed a similar bug with
> SEV intra-host migration where an in-flight vCPU creation could race with
> a VM-wide state transition.
>
> Define a fancy new CLASS to handle the lock+check => unlock logic with
> guard()-like syntax:
>
> CLASS(tdx_vm_state_guard, guard)(kvm);
> if (IS_ERR(guard))
> return PTR_ERR(guard);
>
> to simplify juggling the many locks.
>
> Note! Take kvm->slots_lock *after* all vcpu->mutex locks, as per KVM's
> soon-to-be-documented lock ordering rules[1].
>
> Link: https://lore.kernel.org/all/20251016235538.171962-1-seanjc@google.com [1]
> Reported-by: Yan Zhao <yan.y.zhao@...el.com>
> Closes: https://lore.kernel.org/all/aLFiPq1smdzN3Ary@yzhao56-desk.sh.intel.com
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
> arch/x86/kvm/vmx/tdx.c | 59 +++++++++++++++++++++++++++++++++++-------
> 1 file changed, 49 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 57dfddd2a6cf..8bcdec049ac6 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -2653,6 +2653,46 @@ static int tdx_read_cpuid(struct kvm_vcpu *vcpu, u32 leaf, u32 sub_leaf,
> return -EIO;
> }
>
> +typedef void *tdx_vm_state_guard_t;
> +
> +static tdx_vm_state_guard_t tdx_acquire_vm_state_locks(struct kvm *kvm)
> +{
> + int r;
> +
> + mutex_lock(&kvm->lock);
> +
> + if (kvm->created_vcpus != atomic_read(&kvm->online_vcpus)) {
> + r = -EBUSY;
> + goto out_err;
> + }
> +
> + r = kvm_lock_all_vcpus(kvm);
> + if (r)
> + goto out_err;
> +
> + /*
> + * Note the unintuitive ordering! vcpu->mutex must be taken outside
> + * kvm->slots_lock!
> + */
> + mutex_lock(&kvm->slots_lock);
> + return kvm;
> +
> +out_err:
> + mutex_unlock(&kvm->lock);
> + return ERR_PTR(r);
> +}
> +
> +static void tdx_release_vm_state_locks(struct kvm *kvm)
> +{
> + mutex_unlock(&kvm->slots_lock);
> + kvm_unlock_all_vcpus(kvm);
> + mutex_unlock(&kvm->lock);
> +}
> +
> +DEFINE_CLASS(tdx_vm_state_guard, tdx_vm_state_guard_t,
> + if (!IS_ERR(_T)) tdx_release_vm_state_locks(_T),
> + tdx_acquire_vm_state_locks(kvm), struct kvm *kvm);
> +
> static int tdx_td_init(struct kvm *kvm, struct kvm_tdx_cmd *cmd)
> {
> struct kvm_tdx_init_vm __user *user_data = u64_to_user_ptr(cmd->data);
> @@ -2764,8 +2804,6 @@ static int tdx_td_finalize(struct kvm *kvm, struct kvm_tdx_cmd *cmd)
> {
> struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm);
>
> - guard(mutex)(&kvm->slots_lock);
> -
> if (!is_hkid_assigned(kvm_tdx) || kvm_tdx->state == TD_STATE_RUNNABLE)
> return -EINVAL;
>
> @@ -2809,7 +2847,9 @@ int tdx_vm_ioctl(struct kvm *kvm, void __user *argp)
> if (tdx_cmd.id == KVM_TDX_CAPABILITIES)
> return tdx_get_capabilities(&tdx_cmd);
>
> - guard(mutex)(&kvm->lock);
> + CLASS(tdx_vm_state_guard, guard)(kvm);
> + if (IS_ERR(guard))
> + return PTR_ERR(guard);
>
> switch (tdx_cmd.id) {
> case KVM_TDX_INIT_VM:
> @@ -3113,8 +3153,6 @@ static int tdx_vcpu_init_mem_region(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *c
> if (tdx->state != VCPU_TD_STATE_INITIALIZED)
> return -EINVAL;
>
> - guard(mutex)(&kvm->slots_lock);
> -
> /* Once TD is finalized, the initial guest memory is fixed. */
> if (kvm_tdx->state == TD_STATE_RUNNABLE)
> return -EINVAL;
> @@ -3170,7 +3208,8 @@ static int tdx_vcpu_init_mem_region(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *c
>
> int tdx_vcpu_unlocked_ioctl(struct kvm_vcpu *vcpu, void __user *argp)
> {
> - struct kvm_tdx *kvm_tdx = to_kvm_tdx(vcpu->kvm);
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm);
reverse xmas tree ?
> struct kvm_tdx_cmd cmd;
> int r;
>
> @@ -3178,12 +3217,13 @@ int tdx_vcpu_unlocked_ioctl(struct kvm_vcpu *vcpu, void __user *argp)
> if (r)
> return r;
>
> + CLASS(tdx_vm_state_guard, guard)(kvm);
> + if (IS_ERR(guard))
> + return PTR_ERR(guard);
> +
> if (!is_hkid_assigned(kvm_tdx) || kvm_tdx->state == TD_STATE_RUNNABLE)
> return -EINVAL;
>
> - if (mutex_lock_killable(&vcpu->mutex))
> - return -EINTR;
> -
> vcpu_load(vcpu);
>
> switch (cmd.id) {
> @@ -3200,7 +3240,6 @@ int tdx_vcpu_unlocked_ioctl(struct kvm_vcpu *vcpu, void __user *argp)
>
> vcpu_put(vcpu);
>
> - mutex_unlock(&vcpu->mutex);
> return r;
> }
>
> --
> 2.51.1.930.gacf6e81ea2-goog
>
Powered by blists - more mailing lists