From: sashiko-bot@kernel.org
To: "Sebastian Ene" <sebastianene@google.com>
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH v8 6/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
Date: Wed, 29 Jul 2026 12:26:29 +0000 [thread overview]
Message-ID: <20260729122629.D53D01F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260729121306.1519473-8-sebastianene@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] FFA_NOTIFICATION_INFO_GET is passed through directly to EL3 without proxying the RX buffer, causing the host to read stale data when there are more than 5 endpoints.
--
--- Patch [6]: [PATCH v8 6/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler ---
commit 027209aeedfc445dc1a85dadbbed6fe91255d566
Author: Sebastian Ene <sebastianene@google.com>
KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
This commit allows the host to send FF-A notification queries to Trustzone and
proxies these messages from pKVM by removing FFA_NOTIFICATION_INFO_GET from
the unsupported calls list.
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index c22fe45147414..712811e894352 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -678,8 +678,6 @@ static bool ffa_call_supported(u64 func_id)
> case FFA_RXTX_MAP:
> case FFA_MEM_DONATE:
> case FFA_MEM_RETRIEVE_REQ:
> - /* Optional notification interfaces added in FF-A 1.1 */
> - case FFA_NOTIFICATION_INFO_GET:
[Severity: High]
Does this code successfully proxy the RX buffer when there are more than 5
endpoints with pending notifications?
According to the FF-A specification (v1.1, section 17.5.2), when more than 5
endpoints have pending notifications, EL3 returns the notification array in
the caller's RX buffer.
Because EL2 passes the call through natively without a dedicated proxy
handler in kvm_host_ffa_handler(), EL3 will write the data into EL2's
hyp_buffers.rx.
Without a proxy handler to copy this data to host_buffers.rx (like is done
for FFA_PARTITION_INFO_GET), won't the host read stale or garbage data from
its own buffer?
Furthermore, does this direct pass-through modify EL3's RX buffer state to
Full without EL2 synchronizing via host_buffers.lock?
> /* Optional interfaces added in FF-A 1.2 */
> case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
> case FFA_MSG_SEND_DIRECT_RESP2: /* Optional per 7.5.1 */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729121306.1519473-2-sebastianene@google.com?part=6
next prev parent reply other threads:[~2026-07-29 12:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 12:13 [PATCH v8 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Sebastian Ene
2026-07-29 12:13 ` [PATCH v8 1/7] KVM: arm64: Forward FFA_NOTIFICATION_BITMAP calls to Trustzone Sebastian Ene
2026-07-29 12:29 ` sashiko-bot
2026-07-29 12:13 ` [PATCH v8 2/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler Sebastian Ene
2026-07-29 12:34 ` sashiko-bot
2026-07-29 12:13 ` [PATCH v8 3/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND " Sebastian Ene
2026-07-29 12:13 ` [PATCH v8 4/7] KVM: arm64: Support FFA_NOTIFICATION_SET " Sebastian Ene
2026-07-29 12:23 ` sashiko-bot
2026-07-29 12:13 ` [PATCH v8 5/7] KVM: arm64: Support FFA_NOTIFICATION_GET " Sebastian Ene
2026-07-29 12:27 ` sashiko-bot
2026-07-29 12:13 ` [PATCH v8 6/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET " Sebastian Ene
2026-07-29 12:26 ` sashiko-bot [this message]
2026-07-29 12:13 ` [PATCH v8 7/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy 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=20260729122629.D53D01F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sebastianene@google.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.