[PATCH v2 15/15] efi/arm64: Implement ARM64 DRTM in the stub

[Jason Gunthorpe]

On Wed, Oct 21, 2026 at 11:11:15AM -0700, Jonathan Cameron wrote:
> On Fri,  2 Oct 2026 20:31:52 -0300
> Jason Gunthorpe <jgg at nvidia.com> wrote:
> 
> > Provide an implementation of the CONFIG_EFI_STUB_DRTM protocol for ARM64
> > DEN0113 >= v1.1.
> > 
> > First, it queries the FW for support and collects all the
> > information. This is needed to compute the extra_size, which comes
> > from FW reporting how much memory it needs during the launch for the
> > DLME Data and DCE-owned data. The generic stub ensures there is
> > trailing memory after Image for this.
> > 
> > Then the DRTM_PARAMETERS launch structure is computed using the
> > offsets in the efi_info.
> > 
> > Finally, the stub does ExitBootServices and calls the actual launch.
> > 
> > The feature discovery process is deliberately fairly verbose to help
> > debug any FW weirdness in the field. Enable it with efi=debug
> > 
> > It looks something like:
> > 
> >  EFI stub: DRTM: interface version 1.4
> >  EFI stub: DEBUG: DRTM: TPM algorithm 0xc, TPM hashing unavailable, PCR schemas 0x1
> >  EFI stub: DEBUG: DRTM: minimum DLME data 73728 bytes, Normal-world DCE 0 bytes
> >  EFI stub: Decompressing Linux Kernel...
> >  EFI stub: Generating empty DTB
> >  EFI stub: Exiting boot services...
> >  EFI stub: DEBUG: DRTM: will launch, selected launch features 0x0
> >  [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
> > 
> > Eventually the launch'd kernel is going to require built in crypto
> > libraries that match what the FW is using so it can validate some of the
> > information left behind during early boot. Refuse to launch if these are
> > not built in and build in the most common ones from the ARM64_DRTM
> > kconfig.
> > 
> > One nit, if the platform does not support SMC then using drtm=auto may
> > crash on the SMC op. As far as I can tell there is no way to discover SMC
> > support through EFI. Learning it from the ACPI FADT is doable and costs
> > about 250 lines of code.
> 
> Ouch. Sounds like a must have if there is no easier way.

Yeah, maybe so. I will include the patch in the next version. Though
I'm not keen on it and I don't know very much about ACPI.

> > +/* True if SMCCC 1.0 or later is available. */
> > +static bool efi_arm64_psci_smccc_compatible(void)
> > +{
> > +	struct arm_smccc_res res;
> > +	s32 status;
> > +
> > +	arm_smccc_1_1_smc(PSCI_0_2_FN_PSCI_VERSION, &res);
> 
> A function that is meant to check for smccc 1.0 is using the
> smccc_1_1 namespaced calls?  Maybe add a comment on why that
> is ok to do.  Is anyone actually using SMCCC 1.0 on systems like this?

This is a good point, I didn't quite get all these details at the
time, but yeah, technically we have to use the 1.0 calling convention
due the register clobber differnces. The other reason is we can't use
the kernels 1.0 helper since it is an asm function not an assembly..

Fixing everything I came with this:

/*
 * Discovery must tolerate SMCCC 1.0 clobbering x0-x17. The EFI stub cannot
 * call the kernel's out-of-line SMCCC helper, so issue these calls inline.
 */
static u32 efi_arm64_smc_1_0(u32 function, u32 arg)
{
	register unsigned long x0 asm("x0") = function;
	register unsigned long x1 asm("x1") = arg;

	asm volatile("smc #0"
		     : "+r" (x0), "+r" (x1)
		     :
		     : "x2", "x3", "x4", "x5", "x6", "x7", "x8", "x9",
		       "x10", "x11", "x12", "x13", "x14", "x15", "x16",
		       "x17", "cc", "memory");

	return x0;
}

/* True if SMCCC 1.1 or later in the 1.x series is available. */
static bool efi_arm64_psci_smccc_compatible(void)
{
	u32 version;
	s32 status;

	version = efi_arm64_smc_1_0(PSCI_0_2_FN_PSCI_VERSION, 0);
	if ((s32)version < 0)
		return false;

	if (PSCI_VERSION_MAJOR(version) < 1)
		return false;

	status = efi_arm64_smc_1_0(PSCI_1_0_FN_PSCI_FEATURES,
				   ARM_SMCCC_VERSION_FUNC_ID);
	if (status < 0)
		return false;

	version = efi_arm64_smc_1_0(ARM_SMCCC_VERSION_FUNC_ID, 0);
	return (version >> 16) == 1 && version >= ARM_SMCCC_VERSION_1_1;
}

efistub can get away with this inline asm since it isn't 32 bit and it
doesn't deal with quirks.

> I a bit surprised we don't have a common helper for this -
> I guess the version checks are often explicit in a particular
> driver being bound.

The PSCI stuff in the kernel is all very early when establishing what
the channel is and is done only once. Here is a bit different
since we only accept the smc instruction used by drtm..

And even if there was a helper we can't really call it from zboot..

Thanks,
Jason