Re: [PATCH v7 20/21] KVM: s390: vsie: Create minimal scb shadows for not running g3 blocks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kvm: s390: vsie: host DoS via unbacked nested SCA address
- [Medium] kvm: s390: vsie: missing hpid and cpnc in minimal shadow SCB breaks SIGPI
--

commit feee29bf065106ccfaff09da7c439bae1d45d3eb
Author: Christoph Schlameuss <schlameuss@linux.ibm.com>
Subject: KVM: s390: vsie: Create minimal scb shadows for not running g3 blocks

This commit optimizes the shadowing of vSIE control blocks by creating a
minimal shadow for non-running guest-3 blocks instead of a full shadow. The
minimal shadow is designed to only contain information necessary for SIGPI and
SRSI, reducing the overhead of shadowing the entire guest-3 configuration.

> diff --git a/arch/s390/kvm/s390/vsie.c b/arch/s390/kvm/s390/vsie.c
> index 59037964efc9e..c99cc03ecb81d 100644
> --- a/arch/s390/kvm/s390/vsie.c
> +++ b/arch/s390/kvm/s390/vsie.c
[ ... ]
> @@ -722,6 +721,39 @@ static void unshadow_scb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>  		scb_o->ihcpu = scb_s->ihcpu;
>  }
>  
> +static int shadow_scb_minimal(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
> +{
> +	struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
> +	struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
> +	int rc;
> +
> +	/* make sure we don't have any leftovers when reusing the scb */
> +	scb_s->icptcode = 0;
> +	scb_s->eca = 0;
> +	scb_s->ecb = 0;
> +	scb_s->ecb2 = 0;
> +	scb_s->ecb3 = 0;
> +	scb_s->ecd = 0;
> +	scb_s->fac = 0;
> +	scb_s->fpf = 0;
> +
> +	rc = prepare_cpuflags(vcpu, vsie_page);

[Severity: Medium]
Does this zeroing sequence miss carrying over the HPID and CPNC values?

Unlike the full shadow_scb(), shadow_scb_minimal() does not seem to set
scb_s->hpid = HPID_VSIE or copy scb_o->cpnc to scb_s->cpnc. Without the
correct HPID (0x5) initialized in the minimal shadow SCB, will hardware SIGP
Interpretation (SIGPI) fail or incorrectly intercept for non-running guest-3
CPUs?

The hardware SIGPI mechanism requires the sender's HPID to match the target
SCB's HPID.


[Severity: High]
Can an L2 guest setting an unbacked nested SCA address cause a host DoS?

Looking at get_vsie_sca() and kvm_s390_handle_vsie() in
arch/s390/kvm/s390/vsie.c, if a malicious L2 guest sets sca_gpa in its SCB
to an invalid or unbacked guest physical address, pin_sca() fails and
returns -EINVAL:

arch/s390/kvm/s390/vsie.c:get_vsie_sca() {
    ...
	rc = pin_sca(kvm, vsie_sca);
	if (rc) {
		put_vsie_sca(vsie_sca);
		vsie_sca->sca_gpa = ULONG_MAX;
		goto out;
	}
    ...
}

This unhandled -EINVAL is then propagated unmodified through
get_vsie_sca() and returned by kvm_s390_handle_vsie() out of the instruction
handler, instead of injecting a validity intercept:

arch/s390/kvm/s390/vsie.c:kvm_s390_handle_vsie() {
    ...
out_unpin:
	unpin_guest_page(vcpu->kvm, scb_addr, scb_hpa);

	if (rc == -EAGAIN) {
		kvm_s390_rewind_psw(vcpu, 4);
		rc = 0;
	}
	return rc < 0 ? rc : 0;
}

Does this bypass the -EAGAIN check and bubble up to the KVM core, crashing
the host userspace process (e.g., QEMU) and bringing down the entire L1 VM?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918-vsie-sigpi-v7-0-f39806eaae37@linux.ibm.com?part=20