linux-kernel - Re: [PATCH v2 1/2] KVM: arm64: fix FF-A call failure when ff-a driver is built-in

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aReNnhPnuDQVrO+l@e129823.arm.com>
Date: Fri, 14 Nov 2025 20:14:22 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Will Deacon <will@...nel.org>, sudeep.holla@....com
Cc: maz@...nel.org, oliver.upton@...ux.dev, joey.gouly@....com,
	suzuki.poulose@....com, yuzenghui@...wei.com,
	catalin.marinas@....com, perlarsen@...gle.com, ayrton@...gle.com,
	ben.horgan@....com, sudeep.holla@....com, stuart.yoder@....com,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] KVM: arm64: fix FF-A call failure when ff-a
 driver is built-in

+ Sudeep

Hi Will,

> On Thu, Oct 30, 2025 at 10:22:44AM +0000, Yeoreum Yun wrote:
> > Until has_version_negotiated is set to true,
> > all FF-A function calls fail except FFA_VERSION.
> > The has_version_negotiated flag is set to true when
> > the first FFA_VERSION call is made after init_hyp_mode().
> >
> > This works fine when the FF-A driver is built as a module,
> > since ffa_init() is invoked after kvm_arm_init(), allowing do_ffa_version()
> > to set has_version_negotiated to true.
> >
> > However, when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y),
> > all FF-A calls fail. This happens because ffa_init() runs before
> > kvm_arm_init() — the init level of ffa_init() is rootfs_initcall.
> > As a result, the hypervisor cannot set has_version_negotiated,
> > since the FFA_VERSION call made in ffa_init() does not trap to the hypervisor
> > (HCR_EL2.TSC is cleared before kvm_arm_init()).
> >
> > Consequently, this causes failures when using EFI variable services
> > with secure partitions that rely on FFA_SEND_DIRECT_MSG.
> >
> > To fix this, call hyp_ffa_post_init() and set has_version_negotiated
> > during hyp_ffa_init() when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y).
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@....com>
> > ---
> >  arch/arm64/kvm/hyp/nvhe/ffa.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 4e16f9b96f63..0ae87ff61758 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -984,5 +984,17 @@ int hyp_ffa_init(void *pages)
> >  	};
> >
> >  	version_lock = __HYP_SPIN_LOCK_UNLOCKED;
> > +
> > +	if (IS_BUILTIN(CONFIG_ARM_FFA_TRANSPORT)) {
> > +		hyp_spin_lock(&version_lock);
> > +		if (hyp_ffa_post_init()) {
> > +			hyp_spin_unlock(&version_lock);
> > +			return -EOPNOTSUPP;
> > +		}
> > +
> > +		smp_store_release(&has_version_negotiated, true);
> > +		hyp_spin_unlock(&version_lock);
> > +	}
> > +
>
> I don't think this is the right approach.
>
> If the host starts using FF-A before pKVM has initialised, then we've
> got bigger problems than the version because we have no way of knowing
> which pages have been shared with TZ before we initialised.

Right. for Rx Tx buffer also. This is mentioned by Sebastian in
another thread (https://lore.kernel.org/all/aQRuvu8V3woqnqCV@google.com/)

> Why can't FFA defer initialisation until after the proxy has initialised
> when pKVM is enabled? The fact that the driver is modular indicates that
> this should be do-able.

For example, IMA doesn't support the module build
and if ffa driver and related drivers using ffa driver defered,
IMA couldn't generated "boot aggregate log" which should be produced
at that time with PCR values in the TPM using CRB over FF-A.

That's why commit 0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall")
changes init level of FFA core driver.

But I think this problem already exist before the commit
since the FF-A driver's initcall level was device_initcall() and
arm_kvm_init() is also device_initcall().

IOW, if linker depolyes the FF-A driver's initcall first when
FFA driver and KVM are built as built-in,
pKVM couldn't hook the SMC call in the FFA driver's initcall.

TBH, I'm still thinking the way to solve it but
Currently I couldn't find out some solution except the one which is bad in
https://lore.kernel.org/all/aQSKpZDrLzf%2Fbcx7@e129823.arm.com/
(seperate the arm_kvm_init into two part)...

--
Sincerely,
Yeoreum Yun