From: sashiko-bot@kernel.org
To: "Christoph Schlameuss" <schlameuss@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v5 12/21] KVM: s390: vsie: Add helper unshadow_intercept()
Date: Wed, 26 Aug 2026 15:14:57 +0000 [thread overview]
Message-ID: <20260826151458.52F0D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826-vsie-sigpi-v5-12-cf471edb46b2@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] unshadow_intercept() writes uninitialized or stale shadow SCB fields (gbea and icptstatus) back to the guest's original SCB on early validity intercepts, causing guest state corruption.
--
commit 065588b108c97fdd6441ebcc560b6bd343203830
Author: Christoph Schlameuss <schlameuss@linux.ibm.com>
KVM: s390: vsie: Add helper unshadow_intercept()
This commit extracts the unshadow_intercept() helper from unshadow_scb().
The new helper only copies intercept information and avoids clobbering the
timer and guest-state fields, to be used when the rest of the scb is not yet
shadowed.
> diff --git a/arch/s390/kvm/s390/vsie.c b/arch/s390/kvm/s390/vsie.c
> index 5c4f13777178b..988370f491bf5 100644
> --- a/arch/s390/kvm/s390/vsie.c
> +++ b/arch/s390/kvm/s390/vsie.c
> @@ -565,18 +565,27 @@ static void prepare_ibc(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
> }
> }
>
> -/* unshadow the scb, copying parameters back to the real scb */
> -static void unshadow_scb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
> +/*
> + * Only write the interception fields back; avoid clobbering the timer and
> + * guest-state fields in scb_o.
> + */
> +static inline void unshadow_intercept(struct kvm_s390_sie_block *scb_o,
> + struct kvm_s390_sie_block *scb_s)
> {
> - struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
> - struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
> -
> - /* interception */
> scb_o->icptcode = scb_s->icptcode;
> scb_o->icptstatus = scb_s->icptstatus;
> scb_o->ipa = scb_s->ipa;
> scb_o->ipb = scb_s->ipb;
> scb_o->gbea = scb_s->gbea;
> +}
[ ... ]
> @@ -755,10 +764,13 @@ static int shadow_scb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>
> prepare_ibc(vcpu, vsie_page);
> rc = shadow_crycb(vcpu, vsie_page);
> -out:
> if (rc)
> unshadow_scb(vcpu, vsie_page);
> return rc;
> +
> +out_validity:
> + unshadow_intercept(vsie_page->scb_o, &vsie_page->scb_s);
[Severity: High]
This is a pre-existing issue, but does calling unshadow_intercept() here
corrupt the L1 guest state by writing uninitialized or stale shadow SCB fields
back to the guest's original SCB?
When shadow_scb() fails early in prepare_cpuflags() (e.g., due to an L1 guest
setting an invalid CPU flag), it jumps to out_validity and calls
unshadow_intercept().
However, because gbea and icptstatus are not copied from scb_o to scb_s until
much later in shadow_scb(), unshadow_intercept() will write the stale values
from scb_s back into the guest's scb_o, explicitly clobbering the L1 guest's
changes.
An L1 guest could potentially trigger this trivially by forcing an early validity
intercept.
> + return rc;
> }
>
> /* unpin the scb provided by guest 2, marking it as dirty */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260826-vsie-sigpi-v5-0-cf471edb46b2@linux.ibm.com?part=12
next prev parent reply other threads:[~2026-08-26 15:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 15:05 [PATCH v5 00/21] KVM: s390: vsie: Add VSIE SIGP ECALL and SRSI Interpretation Christoph Schlameuss
2026-08-26 15:05 ` [PATCH v5 01/21] KVM: s390: vsie: Add SCAO read and write helpers Christoph Schlameuss
2026-08-26 15:12 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 02/21] KVM: s390: vsie: Move SCAO validation into a function Christoph Schlameuss
2026-08-26 15:15 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 03/21] KVM: s390: vsie: Add vsie_interp_extf detection Christoph Schlameuss
2026-08-26 15:12 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 04/21] KVM: s390: vsie: Add ssca_block and ssca_entry structs Christoph Schlameuss
2026-08-26 15:09 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 05/21] KVM: s390: vsie: Move pin/unpin guest page Christoph Schlameuss
2026-08-26 15:17 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 06/21] KVM: s390: vsie: Move pin/unpin_scb methods Christoph Schlameuss
2026-08-26 15:10 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 07/21] KVM: s390: vsie: Move release/acquire gmap shadow Christoph Schlameuss
2026-08-26 15:14 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 08/21] KVM: s390: vsie: Create helpers to alloc and free vsie_pages Christoph Schlameuss
2026-08-26 15:10 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 09/21] KVM: s390: vsie: Replace radix_tree with xarray addr_to_page Christoph Schlameuss
2026-08-26 15:14 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 10/21] KVM: s390: vsie: Refactor kvm_s390_vsie_destroy and extract reusable methods Christoph Schlameuss
2026-08-26 15:19 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 11/21] KVM: s390: vsie: Add helper reset_vsie_page() and unshadow_intercept() Christoph Schlameuss
2026-08-26 15:18 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 12/21] KVM: s390: vsie: Add helper unshadow_intercept() Christoph Schlameuss
2026-08-26 15:14 ` sashiko-bot [this message]
2026-08-26 15:05 ` [PATCH v5 13/21] KVM: s390: vsie: Lazily keep original scb pinned after vsie exit Christoph Schlameuss
2026-08-26 15:25 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 14/21] KVM: s390: vsie: Add helper to pin and unpin multiple guest pages Christoph Schlameuss
2026-08-26 15:15 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 15/21] KVM: s390: vsie: Add struct vsie_sca with pin and unpin methods Christoph Schlameuss
2026-08-26 15:26 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 16/21] KVM: s390: vsie: Shadow VSIE SCA in guest-1 Christoph Schlameuss
2026-08-26 15:25 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 17/21] KVM: s390: vsie: Allow guest-3 cpu add and remove with ssca Christoph Schlameuss
2026-08-26 15:23 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 18/21] KVM: s390: vsie: Add VSIE max shadow configuration Christoph Schlameuss
2026-08-26 15:24 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 19/21] KVM: s390: vsie: Add VSIE shadow stat counters Christoph Schlameuss
2026-08-26 15:19 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 20/21] KVM: s390: vsie: Create minimal scb shadows for not running g3 blocks Christoph Schlameuss
2026-08-26 15:35 ` sashiko-bot
2026-08-26 15:05 ` [PATCH v5 21/21] KVM: s390: vsie: Enable use of VSIE SSCA Christoph Schlameuss
2026-08-26 15:33 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260826151458.52F0D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=schlameuss@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.