Re: [PATCH v2 5/5] KVM: x86: Expose Zhaoxin RSA CPUID feature

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Exposing the RSA big-number arithmetic engine to untrusted guests creates a severe local denial-of-service vulnerability (Instruction Time DoS).
- [Low] The newly added X86_FEATURE_RSA and X86_FEATURE_RSA_EN flags were not synchronized to the tools/ directory.
--

commit 39b1d23089ffb8d188fc17bb71d4da69fbf1ff4a
Author: Ewan Hai <ewandevelop@gmail.com>

KVM: x86: Expose Zhaoxin RSA CPUID feature

This patch advertises the Zhaoxin big-number arithmetic engine to guests
by exposing the RSA and RSA_EN CPUID feature flags. It allows guests to
use REP XMODEXP and REP MONTMUL2 instructions for accelerating public-key
operations.

> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 3702d7a30ae61..a769c83588f7c 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -154,6 +154,8 @@
>  #define X86_FEATURE_RNG2_EN		( 5*32+23) /* "rng2_en" RNG2 enabled */
>  #define X86_FEATURE_PHE2		( 5*32+25) /* "phe2" PadLock Hash Engine v2 */
>  #define X86_FEATURE_PHE2_EN		( 5*32+26) /* "phe2_en" PHE2 enabled */
> +#define X86_FEATURE_RSA			( 5*32+27) /* "rsa" Big-number arithmetic */
> +#define X86_FEATURE_RSA_EN		( 5*32+28) /* "rsa_en" RSA enabled */

[Severity: Low]
Should these new flags also be synchronized to
tools/arch/x86/include/asm/cpufeatures.h? 

It looks like check-tools-headers might warn during the build if the tools
header isn't kept in sync with the main cpufeatures.h additions.

[ ... ]

> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 3fb81f7a61076..94ea9abae566d 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1290,6 +1290,8 @@ void kvm_initialize_cpu_caps(void)
>  		F(RNG2_EN),
>  		F(PHE2),
>  		F(PHE2_EN),
> +		F(RSA),
> +		F(RSA_EN),

[Severity: High]
Does exposing these instructions to untrusted guests risk a denial of
service?

Since REP XMODEXP and REP MONTMUL2 are unprivileged and support operands up
to 32768 bits, can a guest user-space application force the physical CPU core
into a prolonged computation?

If the hardware doesn't efficiently yield to external host interrupts during
these massive operations, it seems like this could stall the host, delaying
interrupts and VM-exits, potentially triggering host RCU stalls or watchdog
lockups.

>  	);
>  
>  	/*

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528032234.1322565-1-ewandevelop@gmail.com?part=5