From: Marc Zyngier <maz@kernel.org>
To: Sebastian Ene <sebastianene@google.com>
Cc: oupton@kernel.org, will@kernel.org, ayrton@google.com,
catalin.marinas@arm.com, joey.gouly@arm.com, korneld@google.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, android-kvm@google.com,
mrigendra.chaubey@gmail.com, perlarsen@google.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
stable@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
Date: Thu, 23 Apr 2026 09:08:46 +0100 [thread overview]
Message-ID: <867bpy14kx.wl-maz@kernel.org> (raw)
In-Reply-To: <aejOu98q1lEZoFfW@google.com>
On Wed, 22 Apr 2026 14:35:55 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> On Wed, Apr 22, 2026 at 01:24:02PM +0100, Marc Zyngier wrote:
> > On Wed, 22 Apr 2026 11:25:40 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > Prevent the pKVM hypervisor from making assumptions that the
> > > endpoint memory access descriptor (EMAD) comes right after the
> > > FF-A memory region header and enforce a strict placement for it
> > > when validating an FF-A memory lend/share transaction.
>
> Hello Marc,
>
> >
> > As I read this, you want to remove a bad assumption...
> >
> > >
> > > Prior to FF-A version 1.1 the header of the memory region
> > > didn't contain an offset to the endpoint memory access descriptor.
> > > The layout of a memory transaction looks like this:
> > >
> > > Field name | Offset
> > > -- 0
> > > [ Header (ffa_mem_region) |__ ep_mem_offset
> > > EMAD 1 (ffa_mem_region_attributes) |
> > > ]
> > >
> > > Reject the host from specifying a memory access descriptor offset
> > > that is different than the size of the memory region header.
> >
> > And yet you decide that you want to enforce this assumption. I don't
> > understand how you arrive to this conclusion.
> >
> > Looking at the spec, it appears that the offset is *designed* to allow
> > a gap between the header and the EMAD. Refusing to handle a it seems to be a
> > violation of the spec.
> >
> > What am I missing?
>
> While the spec allows the gap to be variable (since version 1.1), the
> arm ff-a driver places it at a fixed position in:
> ffa_mem_region_additional_setup()
> https://elixir.bootlin.com/linux/v7.0/source/drivers/firmware/arm_ffa/driver.c#L671
That's an implementation detail, and you shouldn't rely on this.
> and makes use of the same assumption in: ffa_mem_desc_offset().
> https://elixir.bootlin.com/linux/v7.0/source/include/linux/arm_ffa.h#L448
> The later one seems wrong IMO. because we should compute the offset
> based on the value stored in ep_mem_offset and not adding it up with
> sizeof(struct ffa_mem_region).
>
> Maybe this should be the fix instead and not the one in pKVM ? What do
> you think ?
I think you should parse the buffers as the spec intends them, without
assumptions or limitations.
>
> The current implementation in pKVM makes use of the
> ffa_mem_desc_offset() to validate the first EMAD. If a compromised host
> places an EMAD at a different offset than sizeof(struct ffa_mem_region),
> then pKVM will not validate that EMAD.
Why compromised? Isn't that a perfectly valid thing to do? What I
understand is that the FFA 1.1 implementation in pKVM doesn't match
the expectations of the spec. If that's indeed the case, pKVM should
be fixed to accept these messages correctly, or stop using FFA 1.1.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-04-23 8:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 10:25 [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement Sebastian Ene
2026-04-22 12:24 ` Marc Zyngier
2026-04-22 13:35 ` Sebastian Ene
2026-04-22 19:29 ` Sudeep Holla
2026-04-23 9:17 ` Sebastian Ene
2026-04-23 9:55 ` Sudeep Holla
2026-04-23 8:08 ` Marc Zyngier [this message]
2026-04-23 9:29 ` Sebastian Ene
2026-04-22 19:17 ` Sudeep Holla
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=867bpy14kx.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=android-kvm@google.com \
--cc=ayrton@google.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=korneld@google.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mrigendra.chaubey@gmail.com \
--cc=oupton@kernel.org \
--cc=perlarsen@google.com \
--cc=sebastianene@google.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox