On Wed, Jan 11, 2023 at 2:27 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> The ACPI PRM address space handler calls efi_call_virt_pointer() to
> execute PRM firmware code, but doing so is only permitted when the EFI
> runtime environment is available. Otherwise, such calls are guaranteed
> to result in a crash, and must therefore be avoided.
>
> Cc: <stable@xxxxxxxxxxxxxxx>
> Cc: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
> Cc: Len Brown <lenb@xxxxxxxxxx>
> Cc: linux-acpi@xxxxxxxxxxxxxxx
> Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
> ---
> drivers/acpi/prmt.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
> index 998101cf16e47145..74f924077866ae69 100644
> --- a/drivers/acpi/prmt.c
> +++ b/drivers/acpi/prmt.c
> @@ -236,6 +236,11 @@ static acpi_status acpi_platformrt_space_handler(u32 function,
> efi_status_t status;
> struct prm_context_buffer context;
>
> + if (!efi_enabled(EFI_RUNTIME_SERVICES)) {
> + pr_err("PRM: EFI runtime services unavailable\n");
> + return AE_NOT_IMPLEMENTED;
> + }
> +
Does the check need to be made in the address space handler and if so, then why?
It looks like it would be better to prevent it from being installed if
EFI runtime services are not enabled in the first place, in
init_prmt().
> /*
> * The returned acpi_status will always be AE_OK. Error values will be
> * saved in the first byte of the PRM message buffer to be used by ASL.
> --
