Re: [PATCH 06/60] KVM: SVM: Enable Restricted Injection for an SEV-SNP guest

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] KVM unconditionally advertises Restricted Injection support to the guest via GHCB HV_FEATURES, even when disabled by hardware, module parameter, or QEMU.
- [High] Enabling an IRQ window for a Restricted Injection guest unconditionally sets V_IRQ in the VMCB, causing VMRUN to fail and the guest to crash.
- [Medium] GHCB_HV_FT_SNP_RINJ is incorrectly defined as a multi-bit mask, which will cause bitwise AND checks to yield false positives.

Pre-existing issues:
- [High] Guest-triggerable WARN_ONCE when mapping the Hypervisor Doorbell page fails, leading to host crash.
--

commit d6a1286cdc24170a0933f297e044c76ceede955f
Author: Melody Wang <huibo.wang@amd.com>

KVM: SVM: Enable Restricted Injection for an SEV-SNP guest

Enable Restricted Injection in an SEV-SNP guest by setting the corresponding
bit in the VMSA SEV features field (SEV_FEATURES[3]) from QEMU.

Add Restricted Injection to the supported hypervisor features.

> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
> index 01a6e4dbe4235..ee17a3541b55f 100644
> --- a/arch/x86/include/asm/sev-common.h
> +++ b/arch/x86/include/asm/sev-common.h
> @@ -136,6 +136,7 @@ enum psc_op {
>  
>  #define GHCB_HV_FT_SNP			BIT_ULL(0)
>  #define GHCB_HV_FT_SNP_AP_CREATION	BIT_ULL(1)
> +#define GHCB_HV_FT_SNP_RINJ		(BIT_ULL(2) | GHCB_HV_FT_SNP_AP_CREATION)

[Severity: Medium]
Will this multi-bit mask cause bitwise AND checks to yield false positives?

Because GHCB_HV_FT_SNP_AP_CREATION is BIT_ULL(1), the macro effectively
represents 0x6. A standard feature check like:
    if (features & GHCB_HV_FT_SNP_RINJ)

will evaluate to true if only GHCB_HV_FT_SNP_AP_CREATION is set. Should
AP Creation dependency be enforced during capability aggregation rather
than in the flag definition itself?

>  #define GHCB_HV_FT_SNP_MULTI_VMPL	BIT_ULL(5)
>  
>  /*
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 17168a145d18b..8bdc35ccd0b13 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -39,7 +39,9 @@
>  #define GHCB_VERSION_MAX	2ULL
>  #define GHCB_VERSION_MIN	1ULL
>  
> -#define GHCB_HV_FT_SUPPORTED	(GHCB_HV_FT_SNP | GHCB_HV_FT_SNP_AP_CREATION)
> +#define GHCB_HV_FT_SUPPORTED	(GHCB_HV_FT_SNP |		\
> +				 GHCB_HV_FT_SNP_AP_CREATION |	\
> +				 GHCB_HV_FT_SNP_RINJ)

[Severity: High]
Does this unconditionally advertise Restricted Injection support to the guest?

The GHCB_HV_FT_SUPPORTED macro is returned directly to the guest via
SVM_VMGEXIT_HV_FEATURES and GHCB_MSR_HV_FT_REQ without checking if the host
CPU actually supports X86_FEATURE_RESTRICTED_INJECTION or if it was disabled
via the restricted_injection module parameter.

[ ... ]

> @@ -3223,6 +3229,12 @@ void __init sev_hardware_setup(void)
>  
>  	if (sev_snp_enabled && tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
>  		sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
> +
> +	if (!sev_snp_enabled || !cpu_feature_enabled(X86_FEATURE_RESTRICTED_INJECTION))
> +		sev_snp_restricted_injection_enabled = false;
> +
> +	if (sev_snp_restricted_injection_enabled)
> +		sev_supported_vmsa_features |= SVM_SEV_FEAT_RESTRICTED_INJECTION;

[Severity: High]
This isn't a bug introduced by this patch, but could a malicious guest crash
the host by failing the HVDB page mapping?

When Restricted Injection is active, __sev_snp_inject() maps the
guest-provided Hypervisor Doorbell (HVDB) page using kvm_vcpu_map(). If
this mapping fails (e.g., due to an invalid GPA or host memory pressure),
map_hvdb() returns NULL and triggers a WARN_ONCE. On secure deployments
with panic_on_warn enabled, this could result in a denial of service.

[Severity: High]
Could enabling Restricted Injection cause the VM to crash when an IRQ window
is requested?

When KVM attempts to inject an IRQ into a Restricted Injection guest, but
no_further_signal is set in the HVDB page, svm_interrupt_blocked() returns
true. KVM then calls svm_enable_irq_window(), which unconditionally calls
svm_set_vintr(). This sets the V_IRQ_MASK bit in the VMCB's int_ctl.

Since setting V_IRQ_MASK is strictly forbidden when Restricted Injection is
enabled, could this cause VMRUN to fail with SVM_EXIT_ERR and crash the
guest?

>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608144252.351443-1-joro@8bytes.org?part=6