From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80E0A283151; Thu, 20 Nov 2025 06:17:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619471; cv=none; b=BewRGTqwcDul+kXnaIcQa5AIA7daQ2OBK8ZwycgYXj6ET5UEr67goNCaMu+W5qoBP7HL1OAMGgaCL7Vg2tIlmm1vKuB6I+XDoQAszE0J7s8JbosKg5tVjUP13Dv+I5nppWAaSt5q/awXfkvWBQAsuMSAZfFPrNXIYEeEQRj67kI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619471; c=relaxed/simple; bh=Bq9uE0LWCAWuIY6dFFtwrMkiyxhP5MnJZ7cOjR088Ao=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eC4VzACoC4W3fg32IDWbikOSQgyjXY3AX6hNr3uo8E6vLhwVTLeTPq1iBQ4RH/oXZOA1fMxptgWEpTreSH5v5AKU30eryF+VbCPQ5YrxW1rBRxP9dbSKMlg3RJ9QUsYp5sr6dqiWJ3cjuHd2Gm7ygM/ygFE5Ar4ymw0MwZpyJgI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=YVY5ehVi; arc=none smtp.client-ip=192.198.163.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="YVY5ehVi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619470; x=1795155470; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Bq9uE0LWCAWuIY6dFFtwrMkiyxhP5MnJZ7cOjR088Ao=; b=YVY5ehVizW3IBHeJ/cwh4PfZd03j3Z0oLmtng0BQXhfQtBONVBg3KS3G CK6BMkCLioiXMBWEMzrqSw872Xf5zUwZ66XMZtwqWQAeFDhJ1j/iXSt0z mBND0l+ecFEfoCwJmsNEJtDeG/CBo1jBArDQvUwyQTCUZcHHPnr15s+pK 2eAopL31kMN/edlqGqKAZ3ZbotNCjGzq13kO7jqxAOSGmJ7VurBsMCjxT ApUBushXvGpkLvrOTvfzWpZDcj1eXfLaoynz8S4PTLqylLI4KxMdNP7Ob Uuunx/Ir+gbsHncBmp1CkZj21O5HhBxItLcbTVv3PPAMEMm+HVqBKYUAJ A==; X-CSE-ConnectionGUID: dGYmPGVARp+FXtRZ2TA0IQ== X-CSE-MsgGUID: v9aYB4YSTsGh0Rq9Eq6FWg== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="65713253" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="65713253" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:17:49 -0800 X-CSE-ConnectionGUID: v/8w2HgWQNSNBmj5Z1j4vg== X-CSE-MsgGUID: yvVAI3aGTSKak+treGmMNQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="191700467" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:17:48 -0800 Date: Wed, 19 Nov 2025 22:17:48 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 01/11] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop() Message-ID: <20251119-vmscape-bhb-v4-1-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently, BHB clearing sequence is followed by an LFENCE to prevent transient execution of subsequent indirect branches prematurely. However, LFENCE barrier could be unnecessary in certain cases. For example, when kernel is using BHI_DIS_S mitigation, and BHB clearing is only needed for userspace. In such cases, LFENCE is redundant because ring transitions would provide the necessary serialization. Below is a quick recap of BHI mitigation options: On Alder Lake and newer - BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low performance overhead. - Long loop: Alternatively, longer version of BHB clearing sequence on older processors can be used to mitigate BHI. This is not yet implemented in Linux. On older CPUs - Short loop: Clears BHB at kernel entry and VMexit. On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between guest and host. But when affected by the BHI variant of VMSCAPE, a guest's branch history may still influence indirect branches in userspace. This also means the big hammer IBPB could be replaced with a cheaper option that clears the BHB at exit-to-userspace after a VMexit. In preparation for adding the support for BHB sequence (without LFENCE) on newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is executed. This allows callers to decide whether they need the LFENCE or not. This does adds a few extra bytes to the call sites, but it obviates the need for multiple variants of clear_bhb_loop(). Suggested-by: Dave Hansen Signed-off-by: Pawan Gupta Reviewed-by: Nikolay Borisov --- arch/x86/entry/entry_64.S | 5 ++++- arch/x86/include/asm/nospec-branch.h | 4 ++-- arch/x86/net/bpf_jit_comp.c | 2 ++ 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index ed04a968cc7d0095ab0185b2e3b5beffb7680afd..886f86790b4467347031bc27d3d= 761d5cc286da1 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1528,6 +1528,9 @@ SYM_CODE_END(rewind_stack_and_make_dead) * refactored in the future if needed. The .skips are for safety, to ensure * that all RETs are in the second half of a cacheline to mitigate Indirect * Target Selection, rather than taking the slowpath via its_return_thunk. + * + * Note, callers should use a speculation barrier like LFENCE immediately = after + * a call to this function to ensure BHB is cleared before indirect branch= es. */ SYM_FUNC_START(clear_bhb_loop) ANNOTATE_NOENDBR @@ -1562,7 +1565,7 @@ SYM_FUNC_START(clear_bhb_loop) sub $1, %ecx jnz 1b .Lret2: RET -5: lfence +5: pop %rbp RET SYM_FUNC_END(clear_bhb_loop) diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/no= spec-branch.h index 08ed5a2e46a5fd790bcb1b73feb6469518809c06..ec5ebf96dbb9e240f402f39efc6= 929ae45ec8f0b 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -329,11 +329,11 @@ =20 #ifdef CONFIG_X86_64 .macro CLEAR_BRANCH_HISTORY - ALTERNATIVE "", "call clear_bhb_loop", X86_FEATURE_CLEAR_BHB_LOOP + ALTERNATIVE "", "call clear_bhb_loop; lfence", X86_FEATURE_CLEAR_BHB_LOOP .endm =20 .macro CLEAR_BRANCH_HISTORY_VMEXIT - ALTERNATIVE "", "call clear_bhb_loop", X86_FEATURE_CLEAR_BHB_VMEXIT + ALTERNATIVE "", "call clear_bhb_loop; lfence", X86_FEATURE_CLEAR_BHB_VMEX= IT .endm #else #define CLEAR_BRANCH_HISTORY diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index de5083cb1d3747bba00effca3703a4f6eea80d8d..c1ec14c559119b120edfac079ae= b07948e9844b8 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1603,6 +1603,8 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *i= p, =20 if (emit_call(&prog, func, ip)) return -EINVAL; + /* Don't speculate past this until BHB is cleared */ + EMIT_LFENCE(); EMIT1(0x59); /* pop rcx */ EMIT1(0x58); /* pop rax */ } --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 018F2272811; Thu, 20 Nov 2025 06:18:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619486; cv=none; b=Q0E066HQtj0MgVRvvzqp3laPKQATrJoyt2P3QGlnYTVreed7PYuBr0WrwXR0Lcx7PbmPY/8GKuBvOCYIsIqCOt+LB8cUWZrv3TPsAnrMOVgZXywYXlsf+a5hQv4qI+wWb3/RAFQpk5zI+utZfYdukHIp/2UzkVPGcyiYrR7GM9s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619486; c=relaxed/simple; bh=P49D+XNj2FfAb2wrhAl3Poi/xPL/yYF86RGfUVYhWOM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZM7y2QzMCo1Z2siCQUShkXg2xQIw0pQkQWE+2cnpkG96SXsFExA5INQvD+evDi4XRxypRsPyDbC6frDfACfWZ9ueuh4vcfLNsLix0ux3FvYm9ep7TRuFQILvbX/bW2tXLh/gcl7DWyCtE6tzgFaVpQURrGEUm8xH28cNOu0RB5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=X1FiVMuj; arc=none smtp.client-ip=192.198.163.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="X1FiVMuj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619485; x=1795155485; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=P49D+XNj2FfAb2wrhAl3Poi/xPL/yYF86RGfUVYhWOM=; b=X1FiVMujyRvrrph3WkGCKAimDczMsVWEoQms5zhVdYmcqrwvXbg7+4wI QGu1MqBpnDl7kXEbxLRYTs7T0YtdcQY6oBfYiRK2zl7r1sFBS/g59XCYD BZetb7teLuqk4bKSsOcgk9bL51cDJ9TqkrW9r+2FtiUEDeU6rNu8GrPMA SuD4nw7w327MXCc+AS85afqyVQ6bQUBidYpeMwGKND55JF6RToBTQDcPE mCEnYrqr8VILpBO7hyVJfjc27+/HgWNk6JdflwM0+Cey87JvzonBXqLjR Qw0rGLCoarT1wb2AKf8l14H+9bCwf+DHPju0M+lOSXMu+HDIbcVnEP+vI Q==; X-CSE-ConnectionGUID: n3hkYl4lT1ifjKzATynF9g== X-CSE-MsgGUID: GE7y3QNVR9aUFAGoykDpJw== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="65713273" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="65713273" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:05 -0800 X-CSE-ConnectionGUID: T0J2zFqxSISCe+T4tZhNmg== X-CSE-MsgGUID: AyflTvtASfK7TuUBcBlHww== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="191700496" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:04 -0800 Date: Wed, 19 Nov 2025 22:18:03 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 02/11] x86/bhi: Move the BHB sequence to a macro for reuse Message-ID: <20251119-vmscape-bhb-v4-2-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In preparation to make clear_bhb_loop() work for CPUs with larger BHB, move the sequence to a macro. This will allow setting the depth of BHB-clearing easily via arguments. No functional change intended. Signed-off-by: Pawan Gupta Reviewed-by: Nikolay Borisov --- arch/x86/entry/entry_64.S | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 886f86790b4467347031bc27d3d761d5cc286da1..a62dbc89c5e75b955ebf6d84f20= d157d4bce0253 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1499,11 +1499,6 @@ SYM_CODE_END(rewind_stack_and_make_dead) * from the branch history tracker in the Branch Predictor, therefore remo= ving * user influence on subsequent BTB lookups. * - * It should be used on parts prior to Alder Lake. Newer parts should use = the - * BHI_DIS_S hardware control instead. If a pre-Alder Lake part is being - * virtualized on newer hardware the VMM should protect against BHI attack= s by - * setting BHI_DIS_S for the guests. - * * CALLs/RETs are necessary to prevent Loop Stream Detector(LSD) from enga= ging * and not clearing the branch history. The call tree looks like: * @@ -1532,10 +1527,7 @@ SYM_CODE_END(rewind_stack_and_make_dead) * Note, callers should use a speculation barrier like LFENCE immediately = after * a call to this function to ensure BHB is cleared before indirect branch= es. */ -SYM_FUNC_START(clear_bhb_loop) - ANNOTATE_NOENDBR - push %rbp - mov %rsp, %rbp +.macro CLEAR_BHB_LOOP_SEQ movl $5, %ecx ANNOTATE_INTRA_FUNCTION_CALL call 1f @@ -1545,15 +1537,16 @@ SYM_FUNC_START(clear_bhb_loop) * Shift instructions so that the RET is in the upper half of the * cacheline and don't take the slowpath to its_return_thunk. */ - .skip 32 - (.Lret1 - 1f), 0xcc + .skip 32 - (.Lret1_\@ - 1f), 0xcc ANNOTATE_INTRA_FUNCTION_CALL 1: call 2f -.Lret1: RET +.Lret1_\@: + RET .align 64, 0xcc /* - * As above shift instructions for RET at .Lret2 as well. + * As above shift instructions for RET at .Lret2_\@ as well. * - * This should be ideally be: .skip 32 - (.Lret2 - 2f), 0xcc + * This should ideally be: .skip 32 - (.Lret2_\@ - 2f), 0xcc * but some Clang versions (e.g. 18) don't like this. */ .skip 32 - 18, 0xcc @@ -1564,8 +1557,24 @@ SYM_FUNC_START(clear_bhb_loop) jnz 3b sub $1, %ecx jnz 1b -.Lret2: RET +.Lret2_\@: + RET 5: +.endm + +/* + * This should be used on parts prior to Alder Lake. Newer parts should us= e the + * BHI_DIS_S hardware control instead. If a pre-Alder Lake part is being + * virtualized on newer hardware the VMM should protect against BHI attack= s by + * setting BHI_DIS_S for the guests. + */ +SYM_FUNC_START(clear_bhb_loop) + ANNOTATE_NOENDBR + push %rbp + mov %rsp, %rbp + + CLEAR_BHB_LOOP_SEQ + pop %rbp RET SYM_FUNC_END(clear_bhb_loop) --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DD84255F52; Thu, 20 Nov 2025 06:18:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619501; cv=none; b=QT9TbeQkm+/kdXGfygXF1UfDi6X53Qxr1xgu7J/iekx6pdb+MbrpzkxYwH7Fp5Rz/q08b8TuDUiJn8JjUWX+YUjIvSnrwUoyoCXWcgQ4GGODtQlhgoz5n13SU+MOeU3g7U7fCSaC0SLw1T4k+9MeT8mCNgnOanXbKwYgSd9ETfU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619501; c=relaxed/simple; bh=mqr1DwsjC/lR8ZMpgT6YDiIITwyIWzvkQ5wM7nXl0pc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hPribgMG7yEzJAfHJr5KbhCOJFi5AqN+6Ni3tXsyygebOnEd2riRpiorxLoTRGhTW5L4EZ2E7HVBegwq6UfggFt3pKzsJlJaoXXtAD4yQt4M1UhOvONADJ6XfGk9xdejujPyibBpEj5UTBTPciRR36FYJdnQn+4zPJKvfrF7/00= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=aehQqYlD; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="aehQqYlD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619500; x=1795155500; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mqr1DwsjC/lR8ZMpgT6YDiIITwyIWzvkQ5wM7nXl0pc=; b=aehQqYlDG9+JhoxD0ATd9+WTKRmQVXYD6IcENFi+xVSztldjFYf1qZ2y I5HZXaBUCLm5Wb3OmRJYpG8Fjf/AJ2Zk3ltiL5sT2k12QK9uf2MbLJF+l 4VDOvnvH5EFuClypHOZgums1Grd9B92QLLtOhWhMmYoMVSLpeCD4flkvX 8ZEE5vHDvcnOxUKGvUw3+emXOUmYVFJu4SkgKe4gWT+MwMJwAMrFBqv8d nvJmXBn24XWKWv8dr/zoXQbiqvJyHQRRpswv/OVodE7Bdo3eof1mATguP rtbZsnln8K+VpFM+2twTYQDmSB1RA6p4j/6AdPBTIIuhrctD3QSda4R+b Q==; X-CSE-ConnectionGUID: 1t4BNa4PQSWgE7QmA0wt3Q== X-CSE-MsgGUID: OYvAR1g1Tam2xL335CxshA== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="76005173" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="76005173" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:20 -0800 X-CSE-ConnectionGUID: DImX4dMmSG+++TKqikwyWA== X-CSE-MsgGUID: lWvM0eECSQubid+VD+EnZQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="221918802" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:20 -0800 Date: Wed, 19 Nov 2025 22:18:19 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 03/11] x86/bhi: Make the depth of BHB-clearing configurable Message-ID: <20251119-vmscape-bhb-v4-3-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The BHB clearing sequence has two nested loops that determine the depth of BHB to be cleared. Introduce an argument to the macro to allow the loop count (and hence the depth) to be controlled from outside the macro. Signed-off-by: Pawan Gupta Reviewed-by: Nikolay Borisov --- arch/x86/entry/entry_64.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index a62dbc89c5e75b955ebf6d84f20d157d4bce0253..a2891af416c874349c065160708= 752c41bc6ba36 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1527,8 +1527,8 @@ SYM_CODE_END(rewind_stack_and_make_dead) * Note, callers should use a speculation barrier like LFENCE immediately = after * a call to this function to ensure BHB is cleared before indirect branch= es. */ -.macro CLEAR_BHB_LOOP_SEQ - movl $5, %ecx +.macro CLEAR_BHB_LOOP_SEQ outer_loop_count:req, inner_loop_count:req + movl $\outer_loop_count, %ecx ANNOTATE_INTRA_FUNCTION_CALL call 1f jmp 5f @@ -1550,7 +1550,7 @@ SYM_CODE_END(rewind_stack_and_make_dead) * but some Clang versions (e.g. 18) don't like this. */ .skip 32 - 18, 0xcc -2: movl $5, %eax +2: movl $\inner_loop_count, %eax 3: jmp 4f nop 4: sub $1, %eax @@ -1573,7 +1573,7 @@ SYM_FUNC_START(clear_bhb_loop) push %rbp mov %rsp, %rbp =20 - CLEAR_BHB_LOOP_SEQ + CLEAR_BHB_LOOP_SEQ 5, 5 =20 pop %rbp RET --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 523E5255F52; Thu, 20 Nov 2025 06:18:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619517; cv=none; b=fInFDcv5jUtMTMEHQ5HQKTuaizSDilWTtI+e6FnNIf0KYFpY3DzZmqXo4R8IREX4Y2gPmKmXp0GEXuHqncoOClyJSRMgr9e3yfs3YWYrlH8RnxtCh6JPfYMSwycxe1y2q/vNS7fmi3D6P3ENK99+cIo1Lf8xPKNHtOEYyzi9E7E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619517; c=relaxed/simple; bh=A078uDWWBxMpCRyZUtp0NO+vlPMBgGrOzAyzm3kgiPQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X3TYgL6ZewebjwVfdCg5BLiSl2wljihrGosolPCEWwKEtGL6N1JIee/I2RXThEROsmc6Lay9aj9RPFMIVbzS2WLettUef0xg26DClMv3Yx3PvKUR9oRSsDnszuDHKvDMqU8qfDZVGmCVU7MFpoyOCw71yBs3hK1o9QO8uARDEEs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=d/qI+mR/; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="d/qI+mR/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619515; x=1795155515; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=A078uDWWBxMpCRyZUtp0NO+vlPMBgGrOzAyzm3kgiPQ=; b=d/qI+mR/xLYx/XoDIAIefeathDGYrMCYJMKl0s1Br1ZSuvD0cSwwW3Fd sjNBlnK6y8U8ByzGd0SOhNWFG9gH168Cmr1Ycup7yfeiCBQ5jTaFefiW0 z9EN8knoN4YrLZKZp81SIR7h2WEqSpS/hZhxBUlmg58jZEF6p0+5Hd7iG KX3mG0c1b5Y2+vVtjjo91H+EnwhjW2G/UyAnsF+j6AOPvG5OGwMI6UbtE mZZdMZLBevrUagYyzberUgRXyZTsqfJYgrzAPuvFsRDWQhvsXFB1XsUGk LQUQtyWbOfyKS93ACaJEVDk6AZ7n7XBs5OoYHi9BFvv5r7S1Ro3OZNbe9 Q==; X-CSE-ConnectionGUID: WPTKKm7PR66tVFq2vfmTYg== X-CSE-MsgGUID: VaQ/Jxw/QBSIJCtEkfjcoQ== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="76005220" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="76005220" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:35 -0800 X-CSE-ConnectionGUID: 4FP6WjdZTOGn59peiLV6NA== X-CSE-MsgGUID: m/UcgTrUTreYBTaJHo39hA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="221918826" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:35 -0800 Date: Wed, 19 Nov 2025 22:18:34 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 04/11] x86/bhi: Make clear_bhb_loop() effective on newer CPUs Message-ID: <20251119-vmscape-bhb-v4-4-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" As a mitigation for BHI, clear_bhb_loop() executes branches that overwrites the Branch History Buffer (BHB). On Alder Lake and newer parts this sequence is not sufficient because it doesn't clear enough entries. This was not an issue because these CPUs have a hardware control (BHI_DIS_S) that mitigates BHI in kernel. BHI variant of VMSCAPE requires isolating branch history between guests and userspace. Note that there is no equivalent hardware control for userspace. To effectively isolate branch history on newer CPUs, clear_bhb_loop() should execute sufficient number of branches to clear a larger BHB. Dynamically set the loop count of clear_bhb_loop() such that it is effective on newer CPUs too. Use the hardware control enumeration X86_FEATURE_BHI_CTRL to select the appropriate loop count. Suggested-by: Dave Hansen Signed-off-by: Pawan Gupta Reviewed-by: Nikolay Borisov --- arch/x86/entry/entry_64.S | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index a2891af416c874349c065160708752c41bc6ba36..6cddd7d6dc927704357d97346fc= bb34559608888 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1563,17 +1563,20 @@ SYM_CODE_END(rewind_stack_and_make_dead) .endm =20 /* - * This should be used on parts prior to Alder Lake. Newer parts should us= e the - * BHI_DIS_S hardware control instead. If a pre-Alder Lake part is being - * virtualized on newer hardware the VMM should protect against BHI attack= s by - * setting BHI_DIS_S for the guests. + * For protecting the kernel against BHI, this should be used on parts pri= or to + * Alder Lake. Although the sequence works on newer parts, BHI_DIS_S hardw= are + * control has lower overhead, and should be used instead. If a pre-Alder = Lake + * part is being virtualized on newer hardware the VMM should protect agai= nst + * BHI attacks by setting BHI_DIS_S for the guests. */ SYM_FUNC_START(clear_bhb_loop) ANNOTATE_NOENDBR push %rbp mov %rsp, %rbp =20 - CLEAR_BHB_LOOP_SEQ 5, 5 + /* loop count differs based on CPU-gen, see Intel's BHI guidance */ + ALTERNATIVE __stringify(CLEAR_BHB_LOOP_SEQ 5, 5), \ + __stringify(CLEAR_BHB_LOOP_SEQ 12, 7), X86_FEATURE_BHI_CTRL =20 pop %rbp RET --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A36D0245008; Thu, 20 Nov 2025 06:18:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619532; cv=none; b=THoD3sU1Ph/5jU04o3vsR+NUqOF+vBIpxfVsSA0osRLhJLuKDYLEHlAf9sIau/gJkl1SvxDwQ0q5gQB84Pt2yOU/9QErgd6bh0GJ9InCwOgDQMkq6zIuUsV4699qlWQq6XWBnRytsylx1Og2IlpOrqzDjOu593YZX/nUgaCApPA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619532; c=relaxed/simple; bh=2kDP/h5XKk2d311MudSRurGHQf2qIocU+MeMeTbQRcE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KT3MCCu6vhp5kocpU3kqHMClx3MuMhePH9oyJbGhTTHeeereyfivyvBRRixoKFdEepaSXSvi0HkOsM7krFpa36aZuykfsM/yElVNDB1GWh57YuLyU8RmujAGZddCc21n27zW6m+6MIaTzUIN8JZe2sDTUxI9EUYYIRObnKCLlPE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=F5FEP72l; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="F5FEP72l" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619530; x=1795155530; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=2kDP/h5XKk2d311MudSRurGHQf2qIocU+MeMeTbQRcE=; b=F5FEP72lQsEitc9gZ00uqwJmAd68vpkgxaTt0PWX8StNiQGgA8UdXaQT C+GR9/mcm1HShtkPRCXv4Z5fAIUqHiNqrsFs77HZFLywzY35djVvcLvD2 +wvKJ5+sYx1aoVvgq7wz0tTSDm6zQV1P3BtiSY22wUdjgudih4UsG1mRI FccPXkSLRBbzmtP8W+NVy+laYN4KpzFDKpx0GiVF9Uf6Xp6awm4e1NL0Y D0EGcr8cPe5qT8dljmlp8WxzkuLWsSOLE/fTzgVAXgg8tvcGJi+YfwENa oTmRkaGj1f6pLwrS9MMEzqA9GiRvq7abnURsPDRgE77jzOri71IC0WS69 Q==; X-CSE-ConnectionGUID: mDZGSMuPQbuVtM7+y6I9dA== X-CSE-MsgGUID: tOSetZHBShG0NapbN8mL3g== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="76354629" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="76354629" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:50 -0800 X-CSE-ConnectionGUID: 9FbUK+DwTNOMexSW/bdARw== X-CSE-MsgGUID: 9B4PCwOaS0+sh3c938fvJA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="191400585" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:18:50 -0800 Date: Wed, 19 Nov 2025 22:18:49 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 05/11] x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user Message-ID: <20251119-vmscape-bhb-v4-5-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With the upcoming changes x86_ibpb_exit_to_user will also be used when BHB clearing sequence is used. Rename it cover both the cases. No functional change. Signed-off-by: Pawan Gupta --- arch/x86/include/asm/entry-common.h | 6 +++--- arch/x86/include/asm/nospec-branch.h | 2 +- arch/x86/kernel/cpu/bugs.c | 4 ++-- arch/x86/kvm/x86.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/ent= ry-common.h index ce3eb6d5fdf9f2dba59b7bad24afbfafc8c36918..c45858db16c92fc1364fb818185= fba7657840991 100644 --- a/arch/x86/include/asm/entry-common.h +++ b/arch/x86/include/asm/entry-common.h @@ -94,11 +94,11 @@ static inline void arch_exit_to_user_mode_prepare(struc= t pt_regs *regs, */ choose_random_kstack_offset(rdtsc()); =20 - /* Avoid unnecessary reads of 'x86_ibpb_exit_to_user' */ + /* Avoid unnecessary reads of 'x86_predictor_flush_exit_to_user' */ if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) && - this_cpu_read(x86_ibpb_exit_to_user)) { + this_cpu_read(x86_predictor_flush_exit_to_user)) { indirect_branch_prediction_barrier(); - this_cpu_write(x86_ibpb_exit_to_user, false); + this_cpu_write(x86_predictor_flush_exit_to_user, false); } } #define arch_exit_to_user_mode_prepare arch_exit_to_user_mode_prepare diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/no= spec-branch.h index ec5ebf96dbb9e240f402f39efc6929ae45ec8f0b..df60f9cf51b84e5b75e5db70713= 188d2e6ad0f5d 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -531,7 +531,7 @@ void alternative_msr_write(unsigned int msr, u64 val, u= nsigned int feature) : "memory"); } =20 -DECLARE_PER_CPU(bool, x86_ibpb_exit_to_user); +DECLARE_PER_CPU(bool, x86_predictor_flush_exit_to_user); =20 static inline void indirect_branch_prediction_barrier(void) { diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index d7fa03bf51b4517c12cc68e7c441f7589a4983d1..1e9b11198db0fe2483bd17b1327= bcfd44a2c1dbf 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -113,8 +113,8 @@ EXPORT_PER_CPU_SYMBOL_GPL(x86_spec_ctrl_current); * be needed to before running userspace. That IBPB will flush the branch * predictor content. */ -DEFINE_PER_CPU(bool, x86_ibpb_exit_to_user); -EXPORT_PER_CPU_SYMBOL_GPL(x86_ibpb_exit_to_user); +DEFINE_PER_CPU(bool, x86_predictor_flush_exit_to_user); +EXPORT_PER_CPU_SYMBOL_GPL(x86_predictor_flush_exit_to_user); =20 u64 x86_pred_cmd __ro_after_init =3D PRED_CMD_IBPB; =20 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c9c2aa6f4705e1ae257bf94572967a5724a940a7..60123568fba85c8a445f9220d3f= 4a1d11fd0eb77 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11397,7 +11397,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) * may migrate to. */ if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER)) - this_cpu_write(x86_ibpb_exit_to_user, true); + this_cpu_write(x86_predictor_flush_exit_to_user, true); =20 /* * Consume any pending interrupts, including the possible source of --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97F9F238C3B; Thu, 20 Nov 2025 06:19:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619547; cv=none; b=AONUq/mamxjO3pyy+SChlQcURVIIHU2JWDnB4Byf461JGG+oX+cGnMBzhu5oPLn2TSDXBf+5m94+nweJq3PJ8Cho3+TDJxkE5stV2eBsNu03mHEKTtUamWZZizieiqxzc7NEt0Uqn7sg1X06YTTgqxDwxXTZ5cF0iivhXtyxCok= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619547; c=relaxed/simple; bh=dMz6zekRJxMgHvVGRAsdGPLDZGboXMTY5OevNzqM73Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ae7VREQoKMU8pLYYVXwAVZtooMjdspUSNvTWo6CVP1mDd+LdrtxnwrhSUaLK/NSg/GgmJ8p4L2SDdgEeTiuVhmYVTHGlVwQ9M1sBktfTkJUI7vx14e+Y93Rps/F1xvu7xW82qeu7MX7YyfYjRX0FrhBCYZGOiLF6Y3KI3yke7LQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VrGaTiRZ; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VrGaTiRZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619545; x=1795155545; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=dMz6zekRJxMgHvVGRAsdGPLDZGboXMTY5OevNzqM73Y=; b=VrGaTiRZq8LXhYQuEi3hMhMmK5dv+D9R075ZY2nsMpOXMtE7x/Nqi41E D8ceTrQNfogFSZEdES66+YU4Bs7AvDUl1Av8EG/cH7+IY7IntlYU4eulr t7WqaRofHttJVORP7fIt6NGhTXmUIhQEXI6Gs00jLKgzAIpkd5gnLlwW3 ZTRN7ODxpOLaOfdM8LZBHaiDdREHtmwHzlmo5ePlIjalBrQeSLjOrJLSH 1IC82okDYhQtLa0JF7yjRqCCFc2sNT21giTinycVvxaxVSlRwzbHIL8YF XAc9+IfhAQVxhFsKpJEx0/TjXmduFySfEeCg9jSk0WlaKl18/vecPZMtY Q==; X-CSE-ConnectionGUID: u3x+BhBFRXKOhevtPGwq/Q== X-CSE-MsgGUID: gqQhKEthRHS1QlKS7bIv7A== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="76354645" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="76354645" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:05 -0800 X-CSE-ConnectionGUID: u2RymnzIRtmpHHqhqK/06Q== X-CSE-MsgGUID: qcXT9DXvROmdqECQgUQHYA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="191400650" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:05 -0800 Date: Wed, 19 Nov 2025 22:19:04 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 06/11] x86/vmscape: Move mitigation selection to a switch() Message-ID: <20251119-vmscape-bhb-v4-6-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This ensures that all mitigation modes are explicitly handled, while keeping the mitigation selection for each mode together. This also prepares for adding BHB-clearing mitigation mode for VMSCAPE. Signed-off-by: Pawan Gupta --- arch/x86/kernel/cpu/bugs.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 1e9b11198db0fe2483bd17b1327bcfd44a2c1dbf..233594ede19bf971c999f4d3cc0= f6f213002c16c 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -3231,17 +3231,31 @@ early_param("vmscape", vmscape_parse_cmdline); =20 static void __init vmscape_select_mitigation(void) { - if (!boot_cpu_has_bug(X86_BUG_VMSCAPE) || - !boot_cpu_has(X86_FEATURE_IBPB)) { + if (!boot_cpu_has_bug(X86_BUG_VMSCAPE)) { vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; return; } =20 - if (vmscape_mitigation =3D=3D VMSCAPE_MITIGATION_AUTO) { - if (should_mitigate_vuln(X86_BUG_VMSCAPE)) + if ((vmscape_mitigation =3D=3D VMSCAPE_MITIGATION_AUTO) && + !should_mitigate_vuln(X86_BUG_VMSCAPE)) + vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; + + switch (vmscape_mitigation) { + case VMSCAPE_MITIGATION_NONE: + break; + + case VMSCAPE_MITIGATION_IBPB_ON_VMEXIT: + case VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER: + if (!boot_cpu_has(X86_FEATURE_IBPB)) + vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; + break; + + case VMSCAPE_MITIGATION_AUTO: + if (boot_cpu_has(X86_FEATURE_IBPB)) vmscape_mitigation =3D VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER; else vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; + break; } } =20 --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A849E274B42; Thu, 20 Nov 2025 06:19:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619563; cv=none; b=Sg/LZbrLKodZ6+SMScUtZcs6gkbVkoJbVVOqEMWJo3ZuQpNQxI5ZrhYE9vnCeZ/vaj0BJqEBr73jCdJRnSAR5JVzjPIpXsHV1fHjd24Cpbb3A89DbcZ3qFQHKxeSEZIxiyirqVg3DBW0+XM8LktJiUyD62Dw+U6NlU0k08Vob20= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619563; c=relaxed/simple; bh=ZQ2tXtjYQpLw/tK7Ozi2ZUDvtQLKAQOdV+P5M2kZF6s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SUa5nRFPZxY+n/X2aO9EStMB2Xv/m3HgeFP6EkElJxQV5W6K7z6kDoPdrv99uKKCGMtbt4W4jyT8To3Jc0D6kjsqQtBSZuDVM/C63GG+eSL8fmYP3y+VOWQP3zANCWbgfQd1UGZ6sMrW2CpRn///AEf2rZbYmBeYhY4H+Y5tISU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=j6MHKJpU; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="j6MHKJpU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619561; x=1795155561; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ZQ2tXtjYQpLw/tK7Ozi2ZUDvtQLKAQOdV+P5M2kZF6s=; b=j6MHKJpUywh0c5GaFk0xTYP25GN9F4BtwoTz+oWRlBRiFCgUit00maRf +0mrtEdClKZS3ZEEadY3K5lbnQ3DHc3mrn+HY8LhQZHTW6+V8priF9RZU J0JWRk8A8gf4hPS/qLoTwsUgfefHVdwx+QoJiXcp8KlyVD4nEsaBRCt8o 7ugztSyiC4Vi5mNh25WjaF/AVxvT5erz7QJxZUmGJwKoUOTeWnO7lukUm BKbS+h8zZtJnHpo9tmGrDG1Bqyofek3zqnFDsi2RAZ/6Y0f6UjP1AZNdS 8ga34yeBxOS+3e1qj8uRbeQC6hD0OeLY15sCqvla/BZAxZJB2gfiG72Ai g==; X-CSE-ConnectionGUID: 9NqK+2EPSVCOsXkc1Fcv0Q== X-CSE-MsgGUID: LuYNPyOzQBG3yhZK3m1Ojg== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="65706184" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="65706184" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:21 -0800 X-CSE-ConnectionGUID: eeoVeduwTzG6Xgwn1R7tlw== X-CSE-MsgGUID: 2lnfAHWMT26nQnPpneFmfg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="196234830" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:20 -0800 Date: Wed, 19 Nov 2025 22:19:19 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 07/11] x86/vmscape: Use write_ibpb() instead of indirect_branch_prediction_barrier() Message-ID: <20251119-vmscape-bhb-v4-7-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" indirect_branch_prediction_barrier() is a wrapper to write_ibpb(), which also checks if the CPU supports IBPB. For VMSCAPE, call to indirect_branch_prediction_barrier() is only possible when CPU supports IBPB. Simply call write_ibpb() directly to avoid unnecessary alternative patching. Suggested-by: Dave Hansen Signed-off-by: Pawan Gupta Reviewed-by: Nikolay Borisov --- arch/x86/include/asm/entry-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/ent= ry-common.h index c45858db16c92fc1364fb818185fba7657840991..78b143673ca72642149eb2dbf3e= 3e31370fe6b28 100644 --- a/arch/x86/include/asm/entry-common.h +++ b/arch/x86/include/asm/entry-common.h @@ -97,7 +97,7 @@ static inline void arch_exit_to_user_mode_prepare(struct = pt_regs *regs, /* Avoid unnecessary reads of 'x86_predictor_flush_exit_to_user' */ if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) && this_cpu_read(x86_predictor_flush_exit_to_user)) { - indirect_branch_prediction_barrier(); + write_ibpb(); this_cpu_write(x86_predictor_flush_exit_to_user, false); } } --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80CD4283151; Thu, 20 Nov 2025 06:19:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619579; cv=none; b=ia1IhF9TS8z12e07hWtSZIAsRvetYJF6ssBFKV/icnFZCTPgYBjspVmE0czempozwzlN1g/4uGZ4i5q7Wf1sSC3+lUrOnjkyDym8ztVgAv3QpYovEQUEGK3HEggUWYi4OgZ0EY7xWiQe9RNcqb6u2XOorwljs265UlCDCRMk1VQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619579; c=relaxed/simple; bh=Z/nsdGQiF6DtXgACWfa5M2hYz2xzZefNlC797ixTlDQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WWFnoCgJGfzQ8wM5ayfyG3uLvHcPpPR5jteFBRomVKtQoG/vAnrpgDUkxlEItc/z0uESUJPvh+bW/wvUhUNznCybcwuOxQU9VB4ofycwexQej0y60MWsmbxlvkQmK9DH48lyL7n9spQ/4iYFE2SnC2M8R49VS7y+LJ/OaEldgrw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jCzd2iC/; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jCzd2iC/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619578; x=1795155578; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Z/nsdGQiF6DtXgACWfa5M2hYz2xzZefNlC797ixTlDQ=; b=jCzd2iC/DnH81yaMDJ+mq2LRdy1XYjvPS350hGweah2oNM5FA25KeM0A NqzUGND8znjaOoiBW6RRUREgA7lw+5HH5BW0RM3AQ9VUjxhqymNFM+6ka +alffEChGhWE68RrXMY5sT34zkrq5oqcYSPMVBlj/QIcjBDZhMUqGw/fB +jdFuPu/SVumiAaKBYZ6Smig9AsM9rd0ZMhn1FgWqfbis62Sx4wsbM0Vo mMGpdzh/prwe08f/FPoy2wHOKrz5AgRhKRDXixgFObVxiIl29JptBhDSm m0MmD96bZhtRBMyV3nR5oR82irEt39iu9RJdfmxapcx70YY3ubJMGW6Gk Q==; X-CSE-ConnectionGUID: rSQe/8APSEWgiQofTFt/XA== X-CSE-MsgGUID: VN6/pYkKQ1S5wOksHC48zQ== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="77142854" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="77142854" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:37 -0800 X-CSE-ConnectionGUID: wnL8x1ToQLuE3c7kZHiu6g== X-CSE-MsgGUID: w95QrIpHQOayypOvUuPJ3g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="195570824" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:36 -0800 Date: Wed, 19 Nov 2025 22:19:36 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 08/11] x86/vmscape: Use static_call() for predictor flush Message-ID: <20251119-vmscape-bhb-v4-8-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Adding more mitigation options at exit-to-userspace for VMSCAPE would usually require a series of checks to decide which mitigation to use. In this case, the mitigation is done by calling a function, which is decided at boot. So, adding more feature flags and multiple checks can be avoided by using static_call() to the mitigating function. Replace the flag-based mitigation selector with a static_call(). This also frees the existing X86_FEATURE_IBPB_EXIT_TO_USER. Suggested-by: Dave Hansen Signed-off-by: Pawan Gupta --- arch/x86/Kconfig | 1 + arch/x86/include/asm/cpufeatures.h | 2 +- arch/x86/include/asm/entry-common.h | 7 +++---- arch/x86/include/asm/nospec-branch.h | 3 +++ arch/x86/kernel/cpu/bugs.c | 5 ++++- arch/x86/kvm/x86.c | 2 +- 6 files changed, 13 insertions(+), 7 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fa3b616af03a2d50eaf5f922bc8cd4e08a284045..066f62f15e67e85fda0f3fd66ac= abad9a9794ff8 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2706,6 +2706,7 @@ config MITIGATION_TSA config MITIGATION_VMSCAPE bool "Mitigate VMSCAPE" depends on KVM + select HAVE_STATIC_CALL default y help Enable mitigation for VMSCAPE attacks. VMSCAPE is a hardware security diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpuf= eatures.h index 4091a776e37aaed67ca93b0a0cd23cc25dbc33d4..02871318c999f94ec8557e5fb0b= 8fb299960d454 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -496,7 +496,7 @@ #define X86_FEATURE_TSA_SQ_NO (21*32+11) /* AMD CPU not vulnerable to TSA= -SQ */ #define X86_FEATURE_TSA_L1_NO (21*32+12) /* AMD CPU not vulnerable to TSA= -L1 */ #define X86_FEATURE_CLEAR_CPU_BUF_VM (21*32+13) /* Clear CPU buffers using= VERW before VMRUN */ -#define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14) /* Use IBPB on exit-to-us= erspace, see VMSCAPE bug */ +/* Free */ #define X86_FEATURE_ABMC (21*32+15) /* Assignable Bandwidth Monitoring Co= unters */ #define X86_FEATURE_MSR_IMM (21*32+16) /* MSR immediate form instructions= */ =20 diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/ent= ry-common.h index 78b143673ca72642149eb2dbf3e3e31370fe6b28..783e7cb50caeb6c6fc68e0a5c75= ab43e75e37116 100644 --- a/arch/x86/include/asm/entry-common.h +++ b/arch/x86/include/asm/entry-common.h @@ -4,6 +4,7 @@ =20 #include #include +#include =20 #include #include @@ -94,10 +95,8 @@ static inline void arch_exit_to_user_mode_prepare(struct= pt_regs *regs, */ choose_random_kstack_offset(rdtsc()); =20 - /* Avoid unnecessary reads of 'x86_predictor_flush_exit_to_user' */ - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) && - this_cpu_read(x86_predictor_flush_exit_to_user)) { - write_ibpb(); + if (unlikely(this_cpu_read(x86_predictor_flush_exit_to_user))) { + static_call_cond(vmscape_predictor_flush)(); this_cpu_write(x86_predictor_flush_exit_to_user, false); } } diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/no= spec-branch.h index df60f9cf51b84e5b75e5db70713188d2e6ad0f5d..15a2fa8f2f48a066e102263513e= ff9537ac1d25f 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -540,6 +540,9 @@ static inline void indirect_branch_prediction_barrier(v= oid) :: "rax", "rcx", "rdx", "memory"); } =20 +#include +DECLARE_STATIC_CALL(vmscape_predictor_flush, write_ibpb); + /* The Intel SPEC CTRL MSR base value cache */ extern u64 x86_spec_ctrl_base; DECLARE_PER_CPU(u64, x86_spec_ctrl_current); diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 233594ede19bf971c999f4d3cc0f6f213002c16c..cbb3341b9a19f835738eda72263= 23d88b7e41e52 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -200,6 +200,9 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_cond_l1d_flush); DEFINE_STATIC_KEY_FALSE(cpu_buf_vm_clear); EXPORT_SYMBOL_GPL(cpu_buf_vm_clear); =20 +DEFINE_STATIC_CALL_NULL(vmscape_predictor_flush, write_ibpb); +EXPORT_STATIC_CALL_GPL(vmscape_predictor_flush); + #undef pr_fmt #define pr_fmt(fmt) "mitigations: " fmt =20 @@ -3274,7 +3277,7 @@ static void __init vmscape_update_mitigation(void) static void __init vmscape_apply_mitigation(void) { if (vmscape_mitigation =3D=3D VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER) - setup_force_cpu_cap(X86_FEATURE_IBPB_EXIT_TO_USER); + static_call_update(vmscape_predictor_flush, write_ibpb); } =20 #undef pr_fmt diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 60123568fba85c8a445f9220d3f4a1d11fd0eb77..7e55ef3b3203a26be1a138c8fa8= 38a8c5aae0125 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11396,7 +11396,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) * set for the CPU that actually ran the guest, and not the CPU that it * may migrate to. */ - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER)) + if (static_call_query(vmscape_predictor_flush)) this_cpu_write(x86_predictor_flush_exit_to_user, true); =20 /* --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A130283151; Thu, 20 Nov 2025 06:19:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619594; cv=none; b=FSwHvQLWLrzEDW2k+7p1AA6JmCBEZHtD683W49JM0jAi70mylytZkj4P9fIvaAYohsa2arXIaLkbLjJX/iSBsN9c0v1cdmeqV83u19GEIHnUEbZ2eGqwkMKJrUn1F4KZncQMI6LGLnmLIoiT7MQV+81V9Sa03n8kWasFJP1X5r4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619594; c=relaxed/simple; bh=4OBFa8zHl9kgcuvI+bHoW6Hl8dCdjOsBYEoZlk3N8Sw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LpjLU7486kfPoUP8igAR2Y1oCrb4W4op6ICyxfg+E4K849lS74SMSvxTpN8PhhrFT4id9miCS63QZd5q+qccCkI7133UQKx2bYoC3aBzQaDrQFOnJYnIaKyEdI4kM6Qt11SxtKS+TeLW3RbJQh6xoHTOjsN6VL8fmbVQIapcOvY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=UnxgP/sy; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="UnxgP/sy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619593; x=1795155593; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=4OBFa8zHl9kgcuvI+bHoW6Hl8dCdjOsBYEoZlk3N8Sw=; b=UnxgP/syKkS1rsSDG/5suxofZHaMgy4llR6S/3Bl9esh7n/JLk7C3LMA RnHdQH2+H5LBP9WAfgGQ+ZbQULyZDHna0UfPCiv3EwV8PkYauQjN5aU3H Fy558DTKuq1uHoYSe0nLOvSYk+vRyMuavamaOUkkj9EqGlbysQY1ViUIq tjhZrHSLdTXmNqA6ZySFcj1eOIIIAsMaUR3evbsStwGleyQFdSrDVkcQd IFAXyBHPxv75v2BaL9oMqAVeKE/0iSPA4Lo1+WsDKSvEnGZmuYeFCb/bP fjSkfYjZMSrc2rMZ7AOIp6kl/7d3Ktqi/0OBwCUF4J2ca++TghHhc8xnt A==; X-CSE-ConnectionGUID: q8dHsykUSUWyQLwhulJtyA== X-CSE-MsgGUID: 1m2EWpklRZ6nh6IVro+ROw== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="69529208" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="69529208" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:52 -0800 X-CSE-ConnectionGUID: G0BMLFTHRSyS4Ev+t7wZnQ== X-CSE-MsgGUID: 5Vjmmqq5SqOPVRODL9rzqg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="195395054" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:19:52 -0800 Date: Wed, 19 Nov 2025 22:19:51 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 09/11] x86/vmscape: Deploy BHB clearing mitigation Message-ID: <20251119-vmscape-bhb-v4-9-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" IBPB mitigation for VMSCAPE is an overkill on CPUs that are only affected by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides indirect branch isolation between guest and host userspace. However, branch history from guest may also influence the indirect branches in host userspace. To mitigate the BHI aspect, use clear_bhb_loop(). Signed-off-by: Pawan Gupta --- Documentation/admin-guide/hw-vuln/vmscape.rst | 4 ++++ arch/x86/include/asm/nospec-branch.h | 2 ++ arch/x86/kernel/cpu/bugs.c | 30 ++++++++++++++++++++---= ---- 3 files changed, 29 insertions(+), 7 deletions(-) diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst b/Documentation/= admin-guide/hw-vuln/vmscape.rst index d9b9a2b6c114c05a7325e5f3c9d42129339b870b..dc63a0bac03d43d1e295de0791d= d6497d101f986 100644 --- a/Documentation/admin-guide/hw-vuln/vmscape.rst +++ b/Documentation/admin-guide/hw-vuln/vmscape.rst @@ -86,6 +86,10 @@ The possible values in this file are: run a potentially malicious guest and issues an IBPB before the first exit to userspace after VM-exit. =20 + * 'Mitigation: Clear BHB before exit to userspace': + + As above, conditional BHB clearing mitigation is enabled. + * 'Mitigation: IBPB on VMEXIT': =20 IBPB is issued on every VM-exit. This occurs when other mitigations like diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/no= spec-branch.h index 15a2fa8f2f48a066e102263513eff9537ac1d25f..1e8c26c37dbed4256b35101fb41= c0e1eb6ef9272 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -388,6 +388,8 @@ extern void write_ibpb(void); =20 #ifdef CONFIG_X86_64 extern void clear_bhb_loop(void); +#else +static inline void clear_bhb_loop(void) {} #endif =20 extern void (*x86_return_thunk)(void); diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index cbb3341b9a19f835738eda7226323d88b7e41e52..d12c07ccf59479ecf5909356073= 94492c988b2ff 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -109,9 +109,8 @@ DEFINE_PER_CPU(u64, x86_spec_ctrl_current); EXPORT_PER_CPU_SYMBOL_GPL(x86_spec_ctrl_current); =20 /* - * Set when the CPU has run a potentially malicious guest. An IBPB will - * be needed to before running userspace. That IBPB will flush the branch - * predictor content. + * Set when the CPU has run a potentially malicious guest. Indicates that a + * branch predictor flush is needed before running userspace. */ DEFINE_PER_CPU(bool, x86_predictor_flush_exit_to_user); EXPORT_PER_CPU_SYMBOL_GPL(x86_predictor_flush_exit_to_user); @@ -3200,13 +3199,15 @@ enum vmscape_mitigations { VMSCAPE_MITIGATION_AUTO, VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER, VMSCAPE_MITIGATION_IBPB_ON_VMEXIT, + VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER, }; =20 static const char * const vmscape_strings[] =3D { - [VMSCAPE_MITIGATION_NONE] =3D "Vulnerable", + [VMSCAPE_MITIGATION_NONE] =3D "Vulnerable", /* [VMSCAPE_MITIGATION_AUTO] */ - [VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] =3D "Mitigation: IBPB before exit = to userspace", - [VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] =3D "Mitigation: IBPB on VMEXIT", + [VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] =3D "Mitigation: IBPB before exit= to userspace", + [VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] =3D "Mitigation: IBPB on VMEXIT", + [VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER] =3D "Mitigation: Clear BHB be= fore exit to userspace", }; =20 static enum vmscape_mitigations vmscape_mitigation __ro_after_init =3D @@ -3253,8 +3254,19 @@ static void __init vmscape_select_mitigation(void) vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; break; =20 + case VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER: + if (!boot_cpu_has(X86_FEATURE_BHI_CTRL)) + vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; + break; case VMSCAPE_MITIGATION_AUTO: - if (boot_cpu_has(X86_FEATURE_IBPB)) + /* + * CPUs with BHI_CTRL(ADL and newer) can avoid the IBPB and use BHB + * clear sequence. These CPUs are only vulnerable to the BHI variant + * of the VMSCAPE attack and does not require an IBPB flush. + */ + if (boot_cpu_has(X86_FEATURE_BHI_CTRL)) + vmscape_mitigation =3D VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER; + else if (boot_cpu_has(X86_FEATURE_IBPB)) vmscape_mitigation =3D VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER; else vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; @@ -3278,6 +3290,9 @@ static void __init vmscape_apply_mitigation(void) { if (vmscape_mitigation =3D=3D VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER) static_call_update(vmscape_predictor_flush, write_ibpb); + else if (vmscape_mitigation =3D=3D VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_U= SER && + IS_ENABLED(CONFIG_X86_64)) + static_call_update(vmscape_predictor_flush, clear_bhb_loop); } =20 #undef pr_fmt @@ -3369,6 +3384,7 @@ void cpu_bugs_smt_update(void) break; case VMSCAPE_MITIGATION_IBPB_ON_VMEXIT: case VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER: + case VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER: /* * Hypervisors can be attacked across-threads, warn for SMT when * STIBP is not already enabled system-wide. --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64A9C2E719B; Thu, 20 Nov 2025 06:20:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619609; cv=none; b=d22VtDTHpH7w8tKwr7FMRn0cR793hmscyaR84TaYT9Hg7qFICGLA4ck8PCK1kOWdnHQ8z1htCarbMqncjmg4CUEX/DAR+63hUmbkfNBwT0ySILcYAad/CUCllUK1ENNFd/5nVx//awi81BMFT6gTEZ00ZjNJ1wwVjqiKapvk7NI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619609; c=relaxed/simple; bh=IO/M7Bwqr9leiXpGsKiN4bu0IMpZ39ScvP/BSECK4QY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fyZJnuaVfy9M3LKuQIn+e8WxUItg7Y6XPEN2xeQBektlSYW1vyQJdQuAErKG0QJs4qRfzQNWjbPqpxVQlhcYUwQcE7Ax/SSWemIN9idG52sT8zt/7tThUO8a3htS75w1tUsXzpOJoTNsaDYwkphd6J3ZCGdSDMpAhGbc29aqoog= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VkbgvXpE; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VkbgvXpE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619608; x=1795155608; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IO/M7Bwqr9leiXpGsKiN4bu0IMpZ39ScvP/BSECK4QY=; b=VkbgvXpEqaBUD2xG1weRsXbcd80rS9l4UUj8E8pV/iJ1ltq4yg7oEs5x kqHL+Jvc/eYGEZyJDFp5eUHKDVKYQrJluaQTODRmwU8K43dRiLZSnL55B e5dkvk9khYLLVIT/Pg4b/DO2NOjabtvpjz6v1OYkPygoDRJRrhBzcOHd0 Q+YPmXH8AkcMWzk1iP1TBc6fH7o0p9G7VGTzE3NWdSUfWtCcYF6OUQWta d5CyhR+1ND4TuEhbuszBeCD8k641Og8S34axPMnxXoXNKdXEnzLbJXdwY vy+JjxZXJXo11qjH5DY0hSy3FlgG1A3+phVMZHH/Od/8xF4ImAMlIwreI w==; X-CSE-ConnectionGUID: YZBTu1LiRN+/lsYn3rnraw== X-CSE-MsgGUID: rwEuckU4QZyVnySXASCrmg== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="69529246" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="69529246" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:20:07 -0800 X-CSE-ConnectionGUID: EJGWwmTIQROSc6JjREdW9g== X-CSE-MsgGUID: 2PGNOXGsROyYVw5FQugdSQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="195395121" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:20:07 -0800 Date: Wed, 19 Nov 2025 22:20:06 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 10/11] x86/vmscape: Override conflicting attack-vector controls with =force Message-ID: <20251119-vmscape-bhb-v4-10-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vmscape=3Dforce option currently defaults to AUTO mitigation. This is not correct because attack-vector controls override a mitigation when in AUTO mode. This prevents a user from being able to force VMSCAPE mitigation when it conflicts with attack-vector controls. Kernel should deploy a forced mitigation irrespective of attack vectors. Instead of AUTO, use VMSCAPE_MITIGATION_ON that wins over attack-vector controls. Signed-off-by: Pawan Gupta Reviewed-by: Nikolay Borisov --- arch/x86/kernel/cpu/bugs.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index d12c07ccf59479ecf590935607394492c988b2ff..81b0db27f4094c90ebf4704c74f= 5e7e6b809560f 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -3197,6 +3197,7 @@ static void __init srso_apply_mitigation(void) enum vmscape_mitigations { VMSCAPE_MITIGATION_NONE, VMSCAPE_MITIGATION_AUTO, + VMSCAPE_MITIGATION_ON, VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER, VMSCAPE_MITIGATION_IBPB_ON_VMEXIT, VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER, @@ -3205,6 +3206,7 @@ enum vmscape_mitigations { static const char * const vmscape_strings[] =3D { [VMSCAPE_MITIGATION_NONE] =3D "Vulnerable", /* [VMSCAPE_MITIGATION_AUTO] */ + /* [VMSCAPE_MITIGATION_ON] */ [VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] =3D "Mitigation: IBPB before exit= to userspace", [VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] =3D "Mitigation: IBPB on VMEXIT", [VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER] =3D "Mitigation: Clear BHB be= fore exit to userspace", @@ -3224,7 +3226,7 @@ static int __init vmscape_parse_cmdline(char *str) vmscape_mitigation =3D VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER; } else if (!strcmp(str, "force")) { setup_force_cpu_bug(X86_BUG_VMSCAPE); - vmscape_mitigation =3D VMSCAPE_MITIGATION_AUTO; + vmscape_mitigation =3D VMSCAPE_MITIGATION_ON; } else { pr_err("Ignoring unknown vmscape=3D%s option.\n", str); } @@ -3259,6 +3261,7 @@ static void __init vmscape_select_mitigation(void) vmscape_mitigation =3D VMSCAPE_MITIGATION_NONE; break; case VMSCAPE_MITIGATION_AUTO: + case VMSCAPE_MITIGATION_ON: /* * CPUs with BHI_CTRL(ADL and newer) can avoid the IBPB and use BHB * clear sequence. These CPUs are only vulnerable to the BHI variant @@ -3381,6 +3384,7 @@ void cpu_bugs_smt_update(void) switch (vmscape_mitigation) { case VMSCAPE_MITIGATION_NONE: case VMSCAPE_MITIGATION_AUTO: + case VMSCAPE_MITIGATION_ON: break; case VMSCAPE_MITIGATION_IBPB_ON_VMEXIT: case VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER: --=20 2.34.1 From nobody Tue Dec 2 02:05:01 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13DB321B9C9; Thu, 20 Nov 2025 06:20:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619625; cv=none; b=CO4GB8ps2WkH0snBB9yFNkTQYqVLNCgOUSWFqOB0CqoT8zu+wap4Kd02aWuGAi1FDw5+t7n1ZZdKv0ClW0TndCdTRdTRLEC4KLb9Mrd/YbrPioMLvpMpDemKXZ5q/lyRXnTv/T8ikc8V/jz5JxJyXoP9G/ZTP+SE2pkWziQ6+zY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763619625; c=relaxed/simple; bh=INqMWYBufujJ7ZizDNzVH0AGCMPDyTIep9RLCXhm1NQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QfpBfcXKa+axGoX0POfDfHCvgAdwx/buQ+UvnCuzGaObe8SswZtfFMZ09DiJaVm3Uy/MmDTyWIOz/M9XXclJhrKeA9RSQnNc5VXHMHb297/0iSzQ9raffOOant7cNYXKaDPHTYBOUd0T2TF+eiy9kQvQ+IMsiM+hOsajOM9SN00= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=FrpAaQ7e; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="FrpAaQ7e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763619624; x=1795155624; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=INqMWYBufujJ7ZizDNzVH0AGCMPDyTIep9RLCXhm1NQ=; b=FrpAaQ7eorVzD7Rd5al07vkQkMoRSaYdvbPosIv171cCbF+F5V+ZRV7O kHgiua8mZcCawWbyTlG9MHbl9nOwr5J/5kfyfJ8CTV+xfOYqq15elsWrK EGCVdf+SCHNWGNE6jjrp8kH9yDW0HMwW6MMxN6tD58RhoBRmOXK30DOLc c2/4HhppEb+t9mDo+fzXdAX6uMlWCzReRwqTSN3j3ESo1PheOednkVFUv T9+DNi0A8giUNfZygdtqBxVTzn7kEvioHHO3ehwS+L//BcjIKkO7aJFCA ASZhp/bo2RWjR26B7jfANYcqmx/orPq2nQf/7lCDjK3Ax4C4sG9Y6h9bV g==; X-CSE-ConnectionGUID: vzTwRKNgSCeTdRabg9eXkQ== X-CSE-MsgGUID: 60BgPbFGSYypc8lcC+R21A== X-IronPort-AV: E=McAfee;i="6800,10657,11618"; a="76285298" X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="76285298" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:20:23 -0800 X-CSE-ConnectionGUID: /WV5yCGdT0yz7YoXWKAX9A== X-CSE-MsgGUID: pFcvMdv1RjWybwGFj8nJKA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,317,1754982000"; d="scan'208";a="214632733" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2025 22:20:22 -0800 Date: Wed, 19 Nov 2025 22:20:21 -0800 From: Pawan Gupta To: x86@kernel.org, David Kaplan , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: [PATCH v4 11/11] x86/vmscape: Add cmdline vmscape=on to override attack vector controls Message-ID: <20251119-vmscape-bhb-v4-11-1adad4e69ddc@linux.intel.com> X-Mailer: b4 0.14.2 References: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In general, individual mitigation controls can be used to override the attack vector controls. But, nothing exists to select BHB clearing mitigation for VMSCAPE. The =3Dforce option comes close, but with a side-effect of also forcibly setting the bug, hence deploying the mitigation on unaffected parts too. Add a new cmdline option vmscape=3Don to enable the mitigation based on the VMSCAPE variant the CPU is affected by. Signed-off-by: Pawan Gupta Reviewed-by: Nikolay Borisov --- Documentation/admin-guide/hw-vuln/vmscape.rst | 4 ++++ Documentation/admin-guide/kernel-parameters.txt | 4 +++- arch/x86/kernel/cpu/bugs.c | 2 ++ 3 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst b/Documentation/= admin-guide/hw-vuln/vmscape.rst index dc63a0bac03d43d1e295de0791dd6497d101f986..580f288ae8bfc601ff000d6d95d= 711bb9084459e 100644 --- a/Documentation/admin-guide/hw-vuln/vmscape.rst +++ b/Documentation/admin-guide/hw-vuln/vmscape.rst @@ -112,3 +112,7 @@ The mitigation can be controlled via the ``vmscape=3D``= command line parameter: =20 Force vulnerability detection and mitigation even on processors that are not known to be affected. + + * ``vmscape=3Don``: + + Choose the mitigation based on the VMSCAPE variant the CPU is affected = by. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index 6c42061ca20e581b5192b66c6f25aba38d4f8ff8..4b4711ced5e187495476b5365cd= 7b3df81db893b 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -8104,9 +8104,11 @@ =20 off - disable the mitigation ibpb - use Indirect Branch Prediction Barrier - (IBPB) mitigation (default) + (IBPB) mitigation force - force vulnerability detection even on unaffected processors + on - (default) automatically select IBPB + or BHB clear mitigation based on CPU =20 vsyscall=3D [X86-64,EARLY] Controls the behavior of vsyscalls (i.e. calls to diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 81b0db27f4094c90ebf4704c74f5e7e6b809560f..b4a21434869fcc01c40a2973f98= 6a3f275f92ef2 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -3227,6 +3227,8 @@ static int __init vmscape_parse_cmdline(char *str) } else if (!strcmp(str, "force")) { setup_force_cpu_bug(X86_BUG_VMSCAPE); vmscape_mitigation =3D VMSCAPE_MITIGATION_ON; + } else if (!strcmp(str, "on")) { + vmscape_mitigation =3D VMSCAPE_MITIGATION_ON; } else { pr_err("Ignoring unknown vmscape=3D%s option.\n", str); } --=20 2.34.1