On Fri, 2 Oct 2026 20:31:52 -0300 Jason Gunthorpe <[email protected]> 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. > > Signed-off-by: Jason Gunthorpe <[email protected]> One thing inline that confused me. Otherwise seems fine to me > diff --git a/drivers/firmware/efi/libstub/arm64-drtm.c > b/drivers/firmware/efi/libstub/arm64-drtm.c > new file mode 100644 > index 00000000000000..2fc58babc3e7cb > --- /dev/null > +++ b/drivers/firmware/efi/libstub/arm64-drtm.c > @@ -0,0 +1,426 @@ > + > +/* 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? 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. > + if ((s32)res.a0 < 0) > + return false; > + > + if (PSCI_VERSION_MAJOR(res.a0) < 1) > + return false; > + > + arm_smccc_1_1_smc(PSCI_1_0_FN_PSCI_FEATURES, ARM_SMCCC_VERSION_FUNC_ID, > + &res); > + status = (s32)res.a0; > + if (status == PSCI_RET_NOT_SUPPORTED) { > + /* > + * SMCCC_VERSION was introduced by SMCCC 1.1, so firmware that > + * does not advertise that function through PSCI_FEATURES is > + * using the valid SMCCC 1.0 baseline. > + */ > + return true; > + } else if (status < 0) { > + return false; > + } else { > + u32 version; > + > + arm_smccc_1_1_smc(ARM_SMCCC_VERSION_FUNC_ID, &res); > + version = res.a0; > + if ((version >> 16) != 1 || version < ARM_SMCCC_VERSION_1_1) > + return false; > + } > + return true; > +}
