| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aQNrh1BG8KSkLOHg@e129823.arm.com>
Date: Thu, 30 Oct 2025 13:43:35 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Per Larsen <perl@...unant.com>
Cc: Ben Horgan <ben.horgan@....com>, maz@...nel.org, oliver.upton@...ux.dev,
joey.gouly@....com, suzuki.poulose@....com, yuzenghui@...wei.com,
catalin.marinas@....com, will@...nel.org, perlarsen@...gle.com,
ayrton@...gle.com, linux-arm-kernel@...ts.infradead.org,
kvmarm@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2
Hi Per,
>
> On 10/29/25 2:36 PM, Yeoreum Yun wrote:
> > Hi Ben,
> >
> > >
> > > On 10/28/25 21:06, Yeoreum Yun wrote:
> > > > Hi Ben,
> > > >
> > > > > > To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
> > > > > > support the FF-A v1.2's optinal calls by querying whether
> > > > > > SPMC supports those.
> > > > > >
> > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@....com>
> > > > > > ---
> > > > > > arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
> > > > > > 1 file changed, 18 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > > > > index 0ae87ff61758..9ded1c6369b9 100644
> > > > > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > > > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > > > > @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > > > > ffa_to_smccc_res(res, ret);
> > > > > > }
> > > > > >
> > > > > > +static bool ffa_1_2_optional_calls_supported(u64 func_id)
> > > > > > +{
> > > > > > + struct arm_smccc_1_2_regs res;
> > > > > > +
> > > > > > + if (!smp_load_acquire(&has_version_negotiated) ||
> > > > > > + (FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
> > > > > > + return false;
> > > > > > +
> > > > > > + arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
> > > > > > + .a0 = FFA_FEATURES,
> > > > > > + .a1 = func_id,
> > > > > > + }, &res);
> > > > > > +
> > > > > > + return res.a0 == FFA_SUCCESS;
> > > > > > +}
> > > > > > +
> > > > > > /*
> > > > > > * Is a given FFA function supported, either by forwarding on directly
> > > > > > * or by handling at EL2?
> > > > > > @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
> > > > > > case FFA_NOTIFICATION_SET:
> > > > > > case FFA_NOTIFICATION_GET:
> > > > > > case FFA_NOTIFICATION_INFO_GET:
> > > > > > + return false;
> > > > > > /* 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 */
> > > > > > case FFA_CONSOLE_LOG: /* Optional per 13.1: not in Table 13.1 */
> > > > >
> > > > > Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
> > > > > instances and not from the normal world.
> > > >
> > > > Thanks. in that case, we can return false for FFA_CONSOLE_LOG
> > > > unconditionally.
> > > >
> > > > >
> > > > > > case FFA_PARTITION_INFO_GET_REGS: /* Optional for virtual instances per 13.1 */
> > > > > > - return false;
> > > > > > + return ffa_1_2_optional_calls_supported(func_id);
> > > > > > }
> > > > >
> > > > > I don't think that an smc call here is the right thing to do. This changes this from a light
> > > > > weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.
> > > > >
> > > > > Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
> > > > > and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.
> > > > >
> > > > > So, just this change:
> > > > >
> > > > > @@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
> > > > > case FFA_NOTIFICATION_GET:
> > > > > case FFA_NOTIFICATION_INFO_GET:
> > > > > /* 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 */
> > > > > case FFA_CONSOLE_LOG: /* Optional per 13.1: not in Table 13.1 */
> > > > > case FFA_PARTITION_INFO_GET_REGS: /* Optional for virtual instances per 13.1 */
> > > > >
> > > > > Am I missing something?
> > > >
> > > > Nope. I think you don't think you miss anything and
> > > > I also think about it.
> > > >
> > > > But, I'm not sure about "support" means in the pkvm about FF-A.
> > > > Anyway unless the SPMC doesn't support the specific FF-A ABI,
> > > > I don't know that's meaningful to return "TRUE" in here.
> > > > IOW, suppose pkvm returns supports of FFA_MSG_SEND_DIRECT_REQ2
> > > > but user receive when it calls FFA_MSG_SEND_DIRECT_REQ2 with NOT SUPPORTED.
> > >
> > > As I understand it, the ffa_call_supported() is used in two places:
> > > 1. To return NOT SUPPORTED to an FFA_FEATURE call for ffa calls that are
> > > on the deny list.
> > > 2. To block ffa calls if they are on the deny list.
> > >
> > > For both your patch and just removing FFA_MSG_SEND_DIRECT_REQ2 from the
> > > denylist I think the behaviour is the same.
> > >
> > > If FFA_MSG_SEND_DIRECT_REQ2 is not supported at the spmc then:
> > > a) an FFA_FEATURE call will return not supported
> > > b) an FFA_MSG_SEND_DIRECT_REQ2 will return not supported
> > >
> >
> > Right! I've missed the FFA_FEATURE handles via default_host_smc_handler().
> > As you said, it just a deny list.
> >
> > Thanks. I'll change it.
> Sorry to jump into the discussion very late. I uploaded a patch set which
> adds support for the FFA_MSG_SEND_DIRECT_REQ2 interface which was originally
> developed for the Android common kernels:
>
> https://lore.kernel.org/all/20251030-host-direct-messages-v1-0-463e57871c8f@google.com/T/#t
>
>
> Since there appears to be an upstream use case for this functionality, it
> might be a good building block for the present patch set.
No worries and thanks for sharing.
I'll take a look and let me rebase this patch upon your one.
Thanks.
--
Sincerely,
Yeoreum Yun
Powered by blists - more mailing lists