linux-kernel - Re: [PATCH 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: <aQSZYJQfcWCTtIZm@e129823.arm.com>
Date: Fri, 31 Oct 2025 11:11:28 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: Sebastian Ene <sebastianene@...gle.com>, 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,
	sudeep.holla@....com
Subject: Re: [PATCH 1/2] KVM: arm64: fix FF-A call failure when ff-a driver
 is built-in

+Sudeep holla

Hi Marc,

> Yeoreum Yun <yeoreum.yun@....com> wrote:
> >
> > Hi Sebastian,
> >
> > > > 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()).
> > > >
> > >
> > > I understand the reason behind the patch but this is problematic to have
> > > the builtin driver load before pKVM because the hypervisor would be
> > > un-aware of the host mapped buffers. (eg. the call from ffa_rxtx_map is
> > > not trapped because it is too early). Essentially, you will end up
> > > bypassing the hyp FF-A proxy which I think you will want to avoid.
> >
> > Ah. I've overlooed the ffa_rxtx_map proxy.
> > But unfortunately, some of depndency with the driver using arm_ffa
> > driver, ffa_init() should be called first then other drivers' initcall
> > (usually, these kind of driver defines its one initcall with
> > device_initcall()) (i.e) https://lore.kernel.org/all/20250618102302.2379029-1-yeoreum.yun@arm.com/.
> >
> > Though I arm_ffa driver provide an API getting mapped rx/tx buffer,
> > But this seems to reverse dependency -- kvm depends on arm_ffa driver.
>
> No it doesn't. KVM doesn't give a damn about the kernel FFA driver. It
> just makes sure that the driver doesn't do anything stupid.
>
> > I’ve been thinking about some possible solutions,
> > but in my narrow idea, valid solution is kvm_arm_init() as
> > subsys_initcall_sync() and call kvm_init() in module_init() like
> > attached modification.
> >
> > Do you have any idea?
>
> There is no way we can accept such a change. It makes something
> fragile even more brittle. If anything, make the FFA driver check for
> KVM being initialised, and make the probing defer if not.

The problematic situation is that we couldn't use "defer probe".
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.

Whatever monitoring KVM being intitialised, unless "defer probe" makes
a problematic situation, I think it seems meaningless.

@Sudeep. What do you think about it?


--
Sincerely,
Yeoreum Yun