linux.git/drivers/acpi/prmt.c, branch for-next

ACPI: PRM: Clean up guid type in struct prm_handler_info

2024-10-24T15:31:41+00:00

Clang 19 prints a warning when we pass &th->guid to efi_pa_va_lookup():

drivers/acpi/prmt.c:156:29: error: passing 1-byte aligned argument to
4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an
unaligned pointer access [-Werror,-Walign-mismatch]
  156 |                         (void *)efi_pa_va_lookup(&th->guid, handler_info->handler_address);
      |                                                  ^

The problem is that efi_pa_va_lookup() takes a efi_guid_t and &th->guid
is a regular guid_t.  The difference between the two types is the
alignment.  efi_guid_t is a typedef.

	typedef guid_t efi_guid_t __aligned(__alignof__(u32));

It's possible that this a bug in Clang 19.  Even though the alignment of
&th->guid is not explicitly specified, it will still end up being aligned
at 4 or 8 bytes.

Anyway, as Ard points out, it's cleaner to change guid to efi_guid_t type
and that also makes the warning go away.

Fixes: 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context")
Reported-by: Linux Kernel Functional Testing 
Suggested-by: Ard Biesheuvel 
Signed-off-by: Dan Carpenter 
Tested-by: Paul E. McKenney 
Acked-by: Ard Biesheuvel 
Link: https://patch.msgid.link/3777d71b-9e19-45f4-be4e-17bf4fa7a834@stanley.mountain
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki

ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context

2024-10-21T11:46:50+00:00

PRMT needs to find the correct type of block to translate the PA-VA
mapping for EFI runtime services.

The issue arises because the PRMT is finding a block of type
EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services
as described in Section 2.2.2 (Runtime Services) of the UEFI
Specification [1]. Since the PRM handler is a type of runtime service,
this causes an exception when the PRM handler is called.

    [Firmware Bug]: Unable to handle paging request in EFI runtime service
    WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341
        __efi_queue_work+0x11c/0x170
    Call trace:

Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM
context.

If no suitable block is found, a warning message will be printed, but
the procedure continues to manage the next PRM handler.

However, if the PRM handler is actually called without proper allocation,
it would result in a failure during error handling.

By using the correct memory types for runtime services, ensure that the
PRM handler and the context are properly mapped in the virtual address
space during runtime, preventing the paging request error.

The issue is really that only memory that has been remapped for runtime
by the firmware can be used by the PRM handler, and so the region needs
to have the EFI_MEMORY_RUNTIME attribute.

Link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf # [1]
Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Cc: All applicable 
Signed-off-by: Koba Ko 
Reviewed-by: Matthew R. Ochs 
Reviewed-by: Zhang Rui 
Reviewed-by: Ard Biesheuvel 
Link: https://patch.msgid.link/20241012205010.4165798-1-kobak@nvidia.com
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki

ACPI: PRM: Add PRM handler direct call support

2024-08-01T12:23:39+00:00

Platform Runtime Mechanism (PRM) handlers can be invoked from either the AML
interpreter or directly by an OS driver. Implement the latter.

  [ bp: Massage commit message. ]

Signed-off-by: John Allen 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Yazen Ghannam 
Reviewed-by: Ard Biesheuvel 
Acked-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/20240730151731.15363-2-john.allen@amd.com

ACPI: PRM: Annotate struct prm_module_info with __counted_by

2023-10-03T19:24:10+00:00

Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).

As found with Coccinelle[1], add __counted_by for struct prm_module_info.

Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci # [1]
Signed-off-by: Kees Cook 
Reviewed-by: Gustavo A. R. Silva 
Signed-off-by: Rafael J. Wysocki

acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers

2023-08-22T08:39:26+00:00

Instead of bypassing the kernel's adaptation layer for performing EFI
runtime calls, wire up ACPI PRM handling into it. This means these calls
can no longer occur concurrently with EFI runtime calls, and will be
made from the EFI runtime workqueue. It also means any page faults
occurring during PRM handling will be identified correctly as
originating in firmware code.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Ard Biesheuvel

efi/runtime-wrappers: Remove duplicated macro for service returning void

2023-08-22T08:39:26+00:00

__efi_call_virt() exists as an alternative for efi_call_virt() for the
sole reason that ResetSystem() returns void, and so we cannot use a call
to it in the RHS of an assignment.

Given that there is only a single user, let's drop the macro, and expand
it into the caller. That way, the remaining macro can be tightened
somewhat in terms of type safety too.

Note that the use of typeof() on the runtime service invocation does not
result in an actual call being made, but it does require a few pointer
types to be fixed up and converted into the proper function pointer
prototypes.

Signed-off-by: Ard Biesheuvel

ACPI: PRM: Check whether EFI runtime is available

2023-01-18T18:58:15+00:00

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.

Given that the EFI runtime services may become unavailable after a crash
occurring in the firmware, we need to check this each time the PRM
address space handler is invoked. If the EFI runtime services were not
available at registration time to being with, don't install the address
space handler at all.

Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Signed-off-by: Ard Biesheuvel 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki

ACPI: PRM: Change handler_addr type to void pointer

2022-06-30T15:35:45+00:00

handler_addr is a virtual address passed to efi_call_virt_pointer.
While x86 currently type cast it into the pointer in it's arch specific
arch_efi_call_virt() implementation, ARM64 is restrictive for right
reasons.

Convert the handler_addr type from u64 to void pointer.

Signed-off-by: Sudeep Holla 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Ard Biesheuvel

ACPI: PRM: Handle memory allocation and memory remap failure

2021-10-26T13:29:07+00:00

Handle memory allocation and memory remap failure in acpi_parse_prmt()
when system runs out of memory to avoid the potential NULL pointer
dereference errors.

Signed-off-by: Aubrey Li 
Signed-off-by: Rafael J. Wysocki

ACPI: PRM: Remove unnecessary blank lines

2021-10-26T13:29:07+00:00

Just remove unnecessary blank lines, no other code changes

Signed-off-by: Aubrey Li 
Signed-off-by: Rafael J. Wysocki