From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 660233B5846 for ; Thu, 6 Aug 2026 14:31:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786026663; cv=none; b=nJy+Lj9Xs1uWaWXpti0LaYmJxX1UCL/oPWf2wYbcsuW0NtVHJJnVsuUERO8xOS0m+L4eRMhOt4gskzvRY+Yd8npjYQKLmuteAh0h/tUOEc63DaTBqSr7SCfbe204nTXYzqNXNWc9fpOMMzVSKeGQ34X7FdmbuhizK+sQkkdBU10= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786026663; c=relaxed/simple; bh=SRzjip+qs2pYzBg8Y6FNsQVxNT+5RUMD0U2OziG0v0g=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Jq4ElWAERUUE+nCD9/tPLLaa86k3OGlf/PpTU//bUtFQ6Y7Ovck4qpYjPb6vCOD6Wd+cvm6tNB4LQzvUc4pRAkiQIDbT+3y0YIaA1gIe8lVGh39B6WlP5ZVveyjy74+7BC9qlF1lDavUighh7L5sWgk9i7kxj71QSnyc8Gkfhfw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=inpK2JYd; arc=none smtp.client-ip=209.85.210.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="inpK2JYd" Received: by mail-pf1-f199.google.com with SMTP id d2e1a72fcca58-8487eb67173so3693458b3a.2 for ; Thu, 06 Aug 2026 07:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786026661; x=1786631461; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Qjt2glL7ixu+FlQa4aMWFeGpCQ+RwktDF7Vh1GaP9Vk=; b=inpK2JYdGouBiIOdobmvyjljaEBIx4n2S5/MgiqfjqZ0kvgz72t7cumP9lKiZaews3 YXe5Af3pWlF7H4gsvDM0bbCdmyc+zsUx0YsxLFX87zGJJArT/d4KnfDoVpCbIDTd/2Za W5ecfJzKxjMNj+TrCV/py3VOvn+TCCsf4Hq4mk+apy1iGy4/8ulVHDi79+kyPEmUhM3R PVgukR6nMxHmPJZ1IesbFUFOe36WgYXL6CRUSXRILa0k6/zjjKyofe+ZNs4uv7B9IIIu gfcOXxa/Hd6sznTNUwkXiu/GIMd+Spzq8BCqDyfcBj0+GYVdoPssxBxw2mCnIOLz8dGb YWYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786026661; x=1786631461; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Qjt2glL7ixu+FlQa4aMWFeGpCQ+RwktDF7Vh1GaP9Vk=; b=QrIl8Uy4vx2HBPppvZ0YSxucoQsNOm4SrCL+IbsirFpocuhmEm8OXuUqT4rwEjUuv8 iC9wy83cDkUVVJalN9igR5cLxx8Dg0ojZwONm7J++oQIXPzj0Lm6D8yMSykYnai/d88P JLABGD8f+1u0/FImYuDIi++PvMKGfF6VtSEFhk9rrWEa4ViJQqYp2sbqalup/IA4DMAT 5OQlC24gFh8LAi0ZEe+9xdzctUGg5JO7xDx0aa1GdPdMGu1RGyc4zaPfcM/cIWwvUNbr pDHP61SHyhldmnoiirWHArrQpjNU8ZOswy8JiK6QO2SQzU5KrqVtoFR3d39eyNWMvzJr KDtQ== X-Forwarded-Encrypted: i=1; AHgh+RoekRBWg8E6Zrz40mZAEgnXj5bjmQl8hqOut2GdXQ/jz4cIzezy9hMoWtd4nsfXttG9x1RZVwwoQZl/VXo=@vger.kernel.org X-Gm-Message-State: AOJu0Yzv78EakU0isRq/PEwjebEZbiATOV5ijRhKX07gx32IKqHfOh7M u/9BBhIpo99Ecom3I3hRst3Ava6PYwUZK3viVyBCWObK93MgCE5Ys1ld9x9xQZ/RWHJc2LnyK9S XDS8Hgg== X-Received: from pfbc4.prod.google.com ([2002:a05:6a00:ad04:b0:848:478d:6efb]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:228e:b0:848:6c1c:17c0 with SMTP id d2e1a72fcca58-84f2e026437mr17017883b3a.19.1786026660993; Thu, 06 Aug 2026 07:31:00 -0700 (PDT) Date: Thu, 6 Aug 2026 07:31:00 -0700 In-Reply-To: <20260806111923.1990562-3-xiaoyao.li@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260806111923.1990562-1-xiaoyao.li@intel.com> <20260806111923.1990562-3-xiaoyao.li@intel.com> Message-ID: Subject: Re: [PATCH 2/3] KVM: x86: Reject enabling KVM_CAP_X86_BUS_LOCK_EXIT when !kvm_caps.has_bus_lock_exit From: Sean Christopherson To: Xiaoyao Li Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Thu, Aug 06, 2026, Xiaoyao Li wrote: > Return -EINVAL to reject the enabling of KVM_CAP_X86_BUS_LOCK_EXIT from > userspace when kvm_caps.has_bus_lock_exit is false. > > For KVM_BUS_LOCK_DETECTION_EXIT, if KVM doesn't support BUS LOCK EXIT, > return error to userspace instead of success. > > For KVM_BUS_LOCK_DETECTION_OFF, it seems OK to allow it when KVM doesn't > support bus_lock_exit. But from an API perspective, it implies > inconsistency that KVM_CAP_X86_BUS_LOCK_EXIT reports 0 but setting > KVM_BUS_LOCK_DETECTION_OFF is allowed. To keep it consistent, also > return error for KVM_BUS_LOCK_DETECTION_OFF when KVM doesn't support > BUS LOCK EXIT. > > Fixes: fe6b6bc802b4 ("KVM: VMX: Enable bus lock VM exit") > Signed-off-by: Xiaoyao Li > --- > --- > arch/x86/kvm/x86.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index d94b59140c45..3d8422d1cd04 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4058,8 +4058,10 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > (cap->args[0] & KVM_BUS_LOCK_DETECTION_EXIT)) > break; > > - if (kvm_caps.has_bus_lock_exit && > - cap->args[0] & KVM_BUS_LOCK_DETECTION_EXIT) > + if (!kvm_caps.has_bus_lock_exit) > + break; Yikes, we really botched this one. KVM unfortunately made KVM_BUS_LOCK_DETECTION_OFF an explicit flag, not an absense of flags, without actually honoring that flag. E.g. doing KVM_BUS_LOCK_DETECTION_OFF after KVM_BUS_LOCK_DETECTION_EXIT doesn't actually turn off detection. I vote to get greedy and try dropping KVM_BUS_LOCK_DETECTION_OFF entirely, and making it so that calling the CAP without any flags turns off detection. Otherwise we have to either rejec that case (also risks breaking userspace) or treat it as "do nothing" (which is just stupid). We'd want to reserve bit 0 to avoid really bad breakage, i.e. so that we don't re-introduce bit 0 as something else, but that's easy enough. I'm thinking this over a few patches: diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 1e64026d7c1e..b7c21675aa81 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8379,7 +8379,6 @@ The valid mask flags are: Valid bits in args[0] are:: - #define KVM_BUS_LOCK_DETECTION_OFF (1 << 0) #define KVM_BUS_LOCK_DETECTION_EXIT (1 << 1) Enabling this capability on a VM provides userspace with a way to select a @@ -8393,8 +8392,8 @@ guest, irrespective whether or not the host has enabled split-lock detection intended to mitigate attacks where a malicious/buggy guest can exploit bus locks to degrade the performance of the whole system. -If KVM_BUS_LOCK_DETECTION_OFF is set, KVM doesn't force guest bus locks to VM -exit, although the host kernel's split-lock #AC detection still applies, if +If KVM_BUS_LOCK_DETECTION_EXIT is not set, KVM doesn't force guest bus locks to +VM exit, although the host kernel's split-lock #AC detection still applies, if enabled. If KVM_BUS_LOCK_DETECTION_EXIT is set, KVM enables a CPU feature that ensures diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1ac60628b4c0..67791d139615 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -150,8 +150,8 @@ EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_host); (KVM_X86_QUIRK_CD_NW_CLEARED | \ KVM_X86_QUIRK_IGNORE_GUEST_PAT) -#define KVM_BUS_LOCK_DETECTION_VALID_MODE (KVM_BUS_LOCK_DETECTION_OFF | \ - KVM_BUS_LOCK_DETECTION_EXIT) +/* Bit 0 is forever reserved to avoid breaking userspace in bad ways. */ +#define KVM_BUS_LOCK_DETECTION_VALID_MASK (KVM_BUS_LOCK_DETECTION_EXIT & ~BIT(0)) #define KVM_X86_NOTIFY_VMEXIT_VALID_BITS (KVM_X86_NOTIFY_VMEXIT_ENABLED | \ KVM_X86_NOTIFY_VMEXIT_USER) @@ -2381,8 +2381,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) break; case KVM_CAP_X86_BUS_LOCK_EXIT: if (kvm_caps.has_bus_lock_exit) - r = KVM_BUS_LOCK_DETECTION_OFF | - KVM_BUS_LOCK_DETECTION_EXIT; + r = KVM_BUS_LOCK_DETECTION_VALID_MASK; else r = 0; break; @@ -4051,17 +4050,18 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, break; case KVM_CAP_X86_BUS_LOCK_EXIT: r = -EINVAL; - if (cap->args[0] & ~KVM_BUS_LOCK_DETECTION_VALID_MODE) + if (!kvm_caps.has_bus_lock_exit) break; - if ((cap->args[0] & KVM_BUS_LOCK_DETECTION_OFF) && - (cap->args[0] & KVM_BUS_LOCK_DETECTION_EXIT)) + if (cap->args[0] & ~KVM_BUS_LOCK_DETECTION_VALID_MASK) break; - if (kvm_caps.has_bus_lock_exit && - cap->args[0] & KVM_BUS_LOCK_DETECTION_EXIT) - kvm->arch.bus_lock_detection_enabled = true; - r = 0; + mutex_lock(&kvm->lock); + if (!kvm->created_vcpus) { + kvm->arch.bus_lock_detection_enabled = cap->args[0] & KVM_BUS_LOCK_DETECTION_EXIT; + r = 0; + } + mutex_unlock(&kvm->lock); break; #ifdef CONFIG_X86_SGX_KVM case KVM_CAP_SGX_ATTRIBUTE: { diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 129d6f630325..08e5fe09e5c8 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1542,7 +1542,6 @@ struct kvm_dirty_gfn { __u64 offset; }; -#define KVM_BUS_LOCK_DETECTION_OFF (1 << 0) #define KVM_BUS_LOCK_DETECTION_EXIT (1 << 1) #define KVM_PMU_CAP_DISABLE (1 << 0) > + > + if (cap->args[0] & KVM_BUS_LOCK_DETECTION_EXIT) > kvm->arch.bus_lock_detection_enabled = true; > r = 0; > break; > -- > 2.43.0 >