Re: [PATCH v3 4/4] KVM: s390: vsie: Implement ASTFLEIE facility 2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Hardware alignment violation for Cryptographic Control Block (CRYCB) Format 2.
- [High] Uninitialized `reserved0` field in the shadow format-2 facility list control block leads to hardware state corruption.
--

commit 74d49835ae9f08ad6c33a2e48ab3b975fa0b0159
Author: Nina Schoetterl-Glausch <nsg@linux.ibm.com>

KVM: s390: vsie: Implement ASTFLEIE facility 2

This commit implements shadowing of the format-2 facility list when
running in VSIE, to support the ASTFLEIE2 facility available since
IBM z16.

> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> index 2ea3bbaf568e5..592d6b6f57292 100644
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
> @@ -65,9 +65,9 @@ struct vsie_page {
>  	gpa_t scb_gpa;				/* 0x0258 */
>  	/* the shadow gmap in use by the vsie_page */
>  	struct gmap_cache gmap_cache;		/* 0x0260 */
> -	__u8 reserved[0x0700 - 0x0278];		/* 0x0278 */
> -	struct kvm_s390_crypto_cb crycb;	/* 0x0700 */
> -	__u8 fac[S390_ARCH_FAC_LIST_SIZE_BYTE];	/* 0x0800 */
> +	__u8 reserved[0x06f8 - 0x0278];		/* 0x0278 */
> +	struct kvm_s390_crypto_cb crycb;	/* 0x06f8 */

[Severity: Critical]
Does moving crycb to offset 0x06f8 violate the hardware's 256-byte
alignment requirement for the Cryptographic Control Block (CRYCB) Origin
address?

When KVM applies CRYCB_FORMAT2 to this unaligned physical address in
shadow_crycb():

    scb_s->crycbd = (u32)virt_to_phys(&vsie_page->crycb) | CRYCB_FORMAT2;

will the hardware see a misaligned crycbd value and either inject a
validity intercept or mask out the lower bits, reading keys from
uninitialized padding instead of the actual control block?

[ ... ]

> @@ -999,6 +999,28 @@ static int handle_stfle_0(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page,
>  	return 0;
>  }
>  
> +static int handle_stfle_2(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page, u32 fac_list_origin)
> +{
> +	struct kvm_s390_flcb2 *flcb_s = (struct kvm_s390_flcb2 *)vsie_page->fac;
> +	struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
> +	u64 len;
> +
> +	if (read_guest_real(vcpu, fac_list_origin, &len, sizeof(len)))
> +		return set_validity_icpt(scb_s, 0x1090U);
> +
> +	/* discard reserved bits */
> +	len = (len & U8_MAX);
> +	flcb_s->length = len;
> +	len += 1;

[Severity: High]
Could this leave the 7-byte reserved0 array in the shadow format-2
facility list uninitialized?

Since vsie_page structures are pooled and reused across nested executions
without zeroing the fac array, will reserved0 contain stale data from
previous executions, like facility bits from a prior format-0 STFLE
execution?

If the architecture requires these reserved bits to be zero, will passing
non-zero reserved bits to the hardware cause a validity intercept and
crash the nested guest?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-vsie-alter-stfle-fac-v3-0-b1a35efedaba@linux.ibm.com?part=4