Re: [PATCH RFC 5/6] firmware/psci: Add EFI runtime conduit

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] State leak and memory corruption during CPU suspend in the EFI PSCI conduit
- [High] Early PSCI call to set OSI mode fails and triggers WARN_ON_ONCE
--

--- Patch [5]: [PATCH RFC 5/6] firmware/psci: Add EFI runtime conduit ---
commit faf63cfc78f9ee926dc0d221e33d99624e0fb74d
Author: Sven Peter <sven@kernel.org>

firmware/psci: Add EFI runtime conduit

This patch adds a new "efi" conduit for PSCI firmware calls, routing them
through an EFI runtime service. This is needed for Apple Silicon where the
kernel shares the highest exception level with the firmware. Early CPU
bring-up queries are answered directly from a firmware-provided table before
EFI runtime services are available.

> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index e73bae6cb23a3..af022bf2cb9f2 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -131,6 +133,63 @@ __invoke_psci_fn_smc(unsigned long function_id,
[ ... ]
> +static unsigned long __invoke_psci_fn_efi(unsigned long function_id,
> +					  unsigned long arg0,
> +					  unsigned long arg1,
> +					  unsigned long arg2)
> +{
> +	u32 fn;
> +
> +	/* These are called before EFI runtime services are available */
> +	switch (function_id) {
> +	case PSCI_0_2_FN_PSCI_VERSION:
> +		return efi_psci.version;
> +	case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
> +		return PSCI_0_2_TOS_MP;
> +	case PSCI_1_0_FN_PSCI_FEATURES:
> +		if (!efi_psci_fn_valid(arg0))
> +			return PSCI_RET_NOT_SUPPORTED;
> +		fn = arg0 & 0xff;
> +		if (fn >= efi_psci.num_features || fn >= EFI_PSCI_MAX_FN)
> +			return PSCI_RET_NOT_SUPPORTED;
> +		return efi_psci.features[fn];
> +	}
> +
> +	if (!efi_psci_fn_valid(function_id))
> +		return PSCI_RET_NOT_SUPPORTED;
> +
> +	if (WARN_ON_ONCE(!efi_psci.psci_handler))
> +		return PSCI_RET_NOT_SUPPORTED;
> +	if (WARN_ON_ONCE(!efi_enabled(EFI_RUNTIME_SERVICES)))
> +		return PSCI_RET_NOT_SUPPORTED;

[Severity: High]
Does this early call switch statement need to handle
PSCI_1_0_FN_SET_SUSPEND_MODE?

During early boot, psci_1_0_init() can invoke psci_set_osi_mode(false), which
calls PSCI_1_0_FN_SET_SUSPEND_MODE:

setup_arch() -> psci_dt_init() -> psci_1_0_init()
    psci_set_osi_mode(false);

Since this happens before efi_enabled(EFI_RUNTIME_SERVICES) is true, will this
fall through and trigger the WARN_ON_ONCE above, failing to set the suspend
mode?

> +
> +	return arm64_efi_psci_call(function_id, arg0, arg1, arg2);
> +}

[Severity: Critical]
Is it safe to call arm64_efi_psci_call() during CPU suspend?

When cpu_suspend() is called to enter a deep sleep state, it eventually invokes
arm64_efi_psci_call(), which modifies thread_info state:

arch/arm64/kernel/efi.c:arm64_efi_psci_call() {
	...
	efi_virtmap_load();
	uaccess_ttbr0_enable();
	post_ttbr_update_workaround();

	ret = efi_psci.psci_handler(function_id, arg0, arg1, arg2);
	...
}

If the CPU powers down, execution doesn't return directly from the EFI handler.
Instead, it resumes at the hardware reset vector, calls cpu_resume(), restores
context, and returns to the caller of cpu_suspend().

Because this bypasses the cleanup in arm64_efi_psci_call() (like
efi_virtmap_unload()), could this leak the preempt_count increment and leave
thread_info->ttbr0 pointing to the EFI runtime page tables when returning to
userspace?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-efi-psci-v1-0-9efb3abf0e4c@kernel.org?part=5