[PATCH v2 0/2] use TPM device with CRB over FF-A when kernel boot with pkvm

[PATCH v2 0/2] use TPM device with CRB over FF-A when kernel boot with pkvm

[Yeoreum Yun]

To use TPM device iwth CRB over FF-A, it would be good to be compiled:
  - CONFIG_ARM_FFA_TRANSPORT as bulit-in
  - CONFIG_TCG_ARM_CRB_FFA as built-in

to integrate with IMA subsystem otherwise, it couldn't generate the
boot_aggreate log with the PCR value.

Unfortuately, kernel fails to probe the TPM device
when it boots with kvm-arm.mode=protected since the FF-A calls
(FFA_SEND_DIRECT_MSG/MSG2) are failed when CONFIG_ARM_FFA_TRANSPORT=y.

This patch series resolves failure of the TPM device when
kernel boots with kvm-arm.mode=protected and based on v6.18-rc3.

Patch History
==============

from v1 to v2:
  - remove unnecessary ffa_feature smc-call in ffa_call_supported()
    (Ben Horgan's comment).
  - https://lore.kernel.org/all/20251027191729.1704744-1-yeoreum.yun@arm.com/


Yeoreum Yun (2):
  KVM: arm64: fix FF-A call failure when ff-a driver is built-in
  KVM: arm64: support some optional calls of FF-A v1.2

 arch/arm64/kvm/hyp/nvhe/ffa.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)


base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

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

[Yeoreum Yun]

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@arm.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);
+	}
+
 	return 0;
 }
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[PATCH v2 2/2] KVM: arm64: support some optional calls of FF-A v1.2

[Yeoreum Yun]

To support drivers or components that implement their services using
FFA_DIRECT_REQ2/FFA_DIRECT_RESP2 (e.g., the TPM driver using CRB over FF-A)
and obtain related partition information via FFA_PARTITION_INFO_GET_REG,
enable pKVM to support both FFA_DIRECT_REQ2/FFA_DIRECT_RESP2
and FFA_PARTITION_INFO_GET_REG.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 0ae87ff61758..81e8b33bbdd3 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -679,10 +679,7 @@ 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 */
 		return false;
 	}
 
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

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

[Will Deacon]

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@arm.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.

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.

Will

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

[Yeoreum Yun]

+ 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@arm.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