From: Marc Zyngier <maz@kernel.org>
To: Sebastian Ene <sebastianene@google.com>
Cc: Vincent Donnefort <vdonnefort@google.com>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, android-kvm@google.com,
catalin.marinas@arm.com, joey.gouly@arm.com,
mark.rutland@arm.com, oupton@kernel.org, suzuki.poulose@arm.com,
tabba@google.com, will@kernel.org, yuzenghui@huawei.com
Subject: Re: [PATCH v2] KVM: arm64: Prevent the host from using an smc with imm16 != 0
Date: Wed, 25 Mar 2026 11:58:52 +0000 [thread overview]
Message-ID: <86jyv03ytf.wl-maz@kernel.org> (raw)
In-Reply-To: <acPJ3Z9hDKc0Sm2t@google.com>
On Wed, 25 Mar 2026 11:41:17 +0000,
Sebastian Ene <sebastianene@google.com> wrote:
>
> On Wed, Mar 25, 2026 at 11:35:18AM +0000, Vincent Donnefort wrote:
> > On Wed, Mar 25, 2026 at 11:31:38AM +0000, Sebastian Ene wrote:
> > > The ARM Service Calling Convention (SMCCC) specifies that the function
> > > identifier and parameters should be passed in registers, leaving the
> > > 16-bit immediate field of the SMC instruction un-handled.
> > > Currently, our pKVM handler ignores the immediate value, which could lead
> > > to non-compliant software relying on implementation-defined behavior.
> > > Enforce the host kernel running under pKVM to use an immediate value
> > > of 0 by decoding the ISS from the ESR_EL2 and return a not supported
> > > error code back to the caller.
> > >
> > > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > > ---
> > > v1 -> v2:
> > >
> > > - Dropped injecting an UNDEF and return an error instead
> > > (SMCCC_RET_NOT_SUPPORTED)
> > > - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> > > - Updated the title of the commit message from:
> > > "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> > > smc with imm16 != 0
> >
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > index e7790097db93..4ffe30fd8707 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > @@ -762,6 +762,12 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
> > > handle_host_hcall(host_ctxt);
> > > break;
> > > case ESR_ELx_EC_SMC64:
> > > + if (ESR_ELx_xVC_IMM_MASK & esr) {
> > > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> > > + kvm_skip_host_instr();
> > > + break;
> > > + }
> > > +
> >
> > I wonder if it isn't better to move that into handle_host_smc() as this is part
> > of how we handle the SMC after all? (and it calls that kvm_skip_host_instr()
> > already)
> >
>
> I was thinking of doing that as well but I prefer this since we don't
> have to look again at the esr in the callee.
I don't see that obtaining ESR_EL2 is that hard or expensive. Given
that everything is in the same compilation unit, the compiler will
probably optimise it.
But if I have to state the obvious: you are *handling* an SMC
instruction. Surely handle_host_smc() is the correct spot for that
job?
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-03-25 11:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 11:31 [PATCH v2] KVM: arm64: Prevent the host from using an smc with imm16 != 0 Sebastian Ene
2026-03-25 11:35 ` Vincent Donnefort
2026-03-25 11:41 ` Sebastian Ene
2026-03-25 11:58 ` Marc Zyngier [this message]
2026-03-25 12:16 ` Fuad Tabba
2026-03-25 13:16 ` Sebastian Ene
2026-03-25 11:46 ` Marc Zyngier
2026-03-25 12:12 ` Will Deacon
2026-03-25 13:33 ` Mark Rutland
2026-03-25 13:15 ` Sebastian Ene
2026-03-25 13:28 ` Mark Rutland
2026-03-25 14:33 ` Marc Zyngier
2026-03-25 16:02 ` Sebastian Ene
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=86jyv03ytf.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=android-kvm@google.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oupton@kernel.org \
--cc=sebastianene@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.