From: sashiko-bot@kernel.org
To: "Amit Machhiwal" <amachhiw@linux.ibm.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v4] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
Date: Tue, 16 Jun 2026 16:51:42 +0000 [thread overview]
Message-ID: <20260616165142.71FBC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260616163405.96962-1-amachhiw@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Setting an invalid arch_compat bypasses capability checks and poisons the shared vcore state, but only marks the calling vCPU as insane, allowing sibling vCPUs to exploit the invalid state.
- [High] The patch breaks the KVM kernel build for BookE and non-Book3S PowerPC configurations by dereferencing an incomplete type `struct kvmppc_vcore`.
--
commit c3e328e2b42077592c9f8abacefc77f063b6a36c
Author: Amit Machhiwal <amachhiw@linux.ibm.com>
KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
This commit introduces a validation mechanism to detect and reject
unsupported arch_compat values during guest initialization on PowerPC
Book3S HV. It uses a sentinel value to mark mismatched compatibility
configurations and updates kvmppc_sanity_check() to prevent the vCPU
from running.
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 61dbeea317f3b..f9380ef657500 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
[ ... ]
> @@ -446,7 +446,19 @@ static int kvmppc_set_arch_compat(struct kvm_vcpu *vcpu, u32 arch_compat)
[ ... ]
> case PVR_ARCH_31_P11:
> + /*
> + * Need to check this for ISA 3.1, as Power10 and
> + * Power11 share the same PCR. For any subsequent ISA
> + * versions, this will be taken care of by the guest vs
> + * host PCR comparison below.
> + */
> + if (!cpu_has_feature(CPU_FTR_P11_PVR)) {
> + arch_compat = PVR_ARCH_INVALID;
> + goto out;
> + }
> guest_pcr_bit = PCR_ARCH_31;
> break;
> default:
> @@ -469,6 +481,7 @@ static int kvmppc_set_arch_compat(struct kvm_vcpu *vcpu, u32 arch_compat)
> return -EINVAL;
> }
>
> +out:
> spin_lock(&vc->lock);
> vc->arch_compat = arch_compat;
> kvmhv_nestedv2_mark_dirty(vcpu, KVMPPC_GSID_LOGICAL_PVR);
> @@ -479,7 +492,7 @@ static int kvmppc_set_arch_compat(struct kvm_vcpu *vcpu, u32 arch_compat)
> vc->pcr = (host_pcr_bit - guest_pcr_bit) | PCR_MASK;
> spin_unlock(&vc->lock);
>
> - return 0;
> + return kvmppc_sanity_check(vcpu);
[Severity: High]
If we set arch_compat to PVR_ARCH_INVALID and take the goto out path, does
this bypass the guest_pcr_bit > host_pcr_bit check and persist the sentinel
value into the shared vc->arch_compat?
Since kvmppc_sanity_check() is only called for the current vcpu, could
sibling vCPUs sharing the same vcore bypass the sanity check and run with
this corrupted vcore state?
> }
>
> static void kvmppc_dump_regs(struct kvm_vcpu *vcpu)
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 00302399fc37b..98de68379b18d 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -258,6 +258,10 @@ int kvmppc_sanity_check(struct kvm_vcpu *vcpu)
> if (!vcpu->arch.pvr)
> goto out;
>
> + if (vcpu->arch.vcore &&
> + vcpu->arch.vcore->arch_compat == PVR_ARCH_INVALID)
> + goto out;
> +
[Severity: High]
Does this break the build for BookE and non-Book3S configurations?
kvmppc_sanity_check() is common code located in arch/powerpc/kvm/powerpc.c,
but struct kvmppc_vcore is only defined in asm/kvm_book3s.h.
If a BookE environment compiles this, won't dereferencing
vcpu->arch.vcore->arch_compat result in an incomplete type error?
> /* PAPR only works with book3s_64 */
> if ((vcpu->arch.cpu_type != KVM_CPU_3S_64) && vcpu->arch.papr_enabled)
> goto out;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616163405.96962-1-amachhiw@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-06-16 16:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 16:34 [PATCH v4] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode Amit Machhiwal
2026-06-16 16:51 ` sashiko-bot [this message]
2026-06-16 18:07 ` Ritesh Harjani
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=20260616165142.71FBC1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=amachhiw@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.