aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware/efi/libstub
AgeCommit message (Collapse)AuthorFilesLines
2020-02-23efi/libstub: Make the LoadFile EFI protocol accessibleArd Biesheuvel1-0/+14
Add the protocol definitions, GUIDs and mixed mode glue so that the EFI loadfile protocol can be used from the stub. This will be used in a future patch to load the initrd. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Expose LocateDevicePath boot serviceArd Biesheuvel1-1/+5
We will be adding support for loading the initrd from a GUIDed device path in a subsequent patch, so update the prototype of the LocateDevicePath() boot service to make it callable from our code. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Clean up command line parsing routineArd Biesheuvel5-55/+96
We currently parse the command non-destructively, to avoid having to allocate memory for a copy before passing it to the standard parsing routines that are used by the core kernel, and which modify the input to delineate the parsed tokens with NUL characters. Instead, we call strstr() and strncmp() to go over the input multiple times, and match prefixes rather than tokens, which implies that we would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while the kernel would disregard the option and run with KASLR enabled. In order to avoid having to reason about whether and how this behavior may be abused, let's clean up the parsing routines, and rebuild them on top of the existing helpers. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Take soft and hard memory limits into account for initrd loadingArd Biesheuvel4-17/+20
On x86, the preferred load address of the initrd is still below 4 GB, even though in some cases, we can cope with an initrd that is loaded above that. To simplify the code, and to make it more straightforward to introduce other ways to load the initrd, pass the soft and hard memory limits at the same time, and let the code handling the initrd= command line option deal with this. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Rewrite file I/O routineArd Biesheuvel4-228/+169
The file I/O routine that is used to load initrd or dtb files from the EFI system partition suffers from a few issues: - it converts the u8[] command line back to a UTF-16 string, which is pointless since we only handle initrd or dtb arguments provided via the loaded image protocol anyway, which is where we got the UTF-16[] command line from in the first place when booting via the PE entry point, - in the far majority of cases, only a single initrd= option is present, but it optimizes for multiple options, by going over the command line twice, allocating heap buffers for dynamically sized arrays, etc. - the coding style is hard to follow, with few comments, and all logic including string parsing etc all combined in a single routine. Let's fix this by rewriting most of it, based on the idea that in the case of multiple initrds, we can just allocate a new, bigger buffer and copy over the data before freeing the old one. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Move file I/O support code into separate fileArd Biesheuvel4-289/+311
Split off the file I/O support code into a separate source file so it ends up in a separate object file in the static library, allowing the linker to omit it if the routines are not used. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Move get_dram_base() into arm-stub.cArd Biesheuvel3-37/+33
get_dram_base() is only called from arm-stub.c so move it into the same source file as its caller. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Move efi_random_alloc() into separate source fileArd Biesheuvel3-115/+125
efi_random_alloc() is only used on arm64, but as it shares a source file with efi_random_get_seed(), the latter will pull in the former on other architectures as well. Let's take advantage of the fact that libstub is a static library, and so the linker will only incorporate objects that are needed to satisfy dependencies in other objects. This means we can move the random alloc code to a separate source file that gets built unconditionally, but only used when needed. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub/x86: Permit cmdline data to be allocated above 4 GBArd Biesheuvel4-11/+8
We now support cmdline data that is located in memory that is not 32-bit addressable, so relax the allocation limit on systems where this feature is enabled. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Move stub specific declarations into efistub.hArd Biesheuvel1-29/+478
Move all the declarations that are only used in stub code from linux/efi.h to efistub.h which is only included locally. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub/x86: Permit bootparams struct to be allocated above 4 GBArd Biesheuvel1-1/+6
We now support bootparams structures that are located in memory that is not 32-bit addressable, so relax the allocation limit on systems where this feature is enabled. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Use consistent type names for file I/O protocolsArd Biesheuvel2-8/+71
Align the naming of efi_file_io_interface_t and efi_file_handle_t with the UEFI spec, and call them efi_simple_file_system_protocol_t and efi_file_protocol_t, respectively, using the same convention we use for all other type definitions that originate in the UEFI spec. While at it, move the definitions to efistub.h, so they are only seen by code that needs them. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub/x86: Incorporate eboot.c into libstubArd Biesheuvel3-0/+791
Most of the EFI stub source files of all architectures reside under drivers/firmware/efi/libstub, where they share a Makefile with special CFLAGS and an include file with declarations that are only relevant for stub code. Currently, we carry a lot of stub specific stuff in linux/efi.h only because eboot.c in arch/x86 needs them as well. So let's move eboot.c into libstub/, and move the contents of eboot.h that we still care about into efistub.h Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Simplify efi_high_alloc() and rename to efi_allocate_pages()Ard Biesheuvel3-89/+21
The implementation of efi_high_alloc() uses a complicated way of traversing the memory map to find an available region that is located as close as possible to the provided upper limit, and calls AllocatePages subsequently to create the allocation at that exact address. This is precisely what the EFI_ALLOCATE_MAX_ADDRESS allocation type argument to AllocatePages() does, and considering that EFI_ALLOC_ALIGN only exceeds EFI_PAGE_SIZE on arm64, let's use AllocatePages() directly and implement the alignment using code that the compiler can remove if it does not exceed EFI_PAGE_SIZE. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Move memory map handling and allocation routines to mem.cArd Biesheuvel3-314/+320
Create a new source file mem.c to keep the routines involved in memory allocation and deallocation and manipulation of the EFI memory map. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub/arm: Relax FDT alignment requirementArd Biesheuvel1-5/+1
The arm64 kernel no longer requires the FDT blob to fit inside a naturally aligned 2 MB memory block, so remove the code that aligns the allocation to 2 MB. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi/libstub: Use hidden visibility for all source filesArd Biesheuvel3-7/+8
Instead of setting the visibility pragma for a small set of symbol declarations that could result in absolute references that we cannot support in the stub, declare hidden visibility for all code in the EFI stub, which is more robust and future proof. To ensure that the #pragma is taken into account before any other includes are processed, put it in a header file of its own and include it via the compiler command line using the -include option. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-22efi/libstub/arm64: Use 1:1 mapping of RT services if property table existsArd Biesheuvel2-63/+22
The UEFI spec defines (and deprecates) a misguided and shortlived memory protection feature that is based on splitting memory regions covering PE/COFF executables into separate code and data regions, without annotating them as belonging to the same executable image. When the OS assigns the virtual addresses of these regions, it may move them around arbitrarily, without taking into account that the PE/COFF code sections may contain relative references into the data sections, which means the relative placement of these segments has to be preserved or the executable image will be corrupted. The original workaround on arm64 was to ensure that adjacent regions of the same type were mapped adjacently in the virtual mapping, but this requires sorting of the memory map, which we would prefer to avoid. Considering that the native physical mapping of the PE/COFF images does not suffer from this issue, let's preserve it at runtime, and install it as the virtual mapping as well. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-22efi/libstub/arm: Make efi_entry() an ordinary PE/COFF entrypointArd Biesheuvel3-22/+28
Expose efi_entry() as the PE/COFF entrypoint directly, instead of jumping into a wrapper that fiddles with stack buffers and other stuff that the compiler is much better at. The only reason this code exists is to obtain a pointer to the base of the image, but we can get the same value from the loaded_image protocol, which we already need for other reasons anyway. Update the return type as well, to make it consistent with what is required for a PE/COFF executable entrypoint. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-01-20Merge tag 'v5.5-rc7' into locking/kcsan, to refresh the treeIngo Molnar1-3/+3
Signed-off-by: Ingo Molnar <[email protected]>
2020-01-10efi: Allow disabling PCI busmastering on bridges during bootMatthew Garrett3-1/+130
Add an option to disable the busmaster bit in the control register on all PCI bridges before calling ExitBootServices() and passing control to the runtime kernel. System firmware may configure the IOMMU to prevent malicious PCI devices from being able to attack the OS via DMA. However, since firmware can't guarantee that the OS is IOMMU-aware, it will tear down IOMMU configuration when ExitBootServices() is called. This leaves a window between where a hostile device could still cause damage before Linux configures the IOMMU again. If CONFIG_EFI_DISABLE_PCI_DMA is enabled or "efi=disable_early_pci_dma" is passed on the command line, the EFI stub will clear the busmaster bit on all PCI bridges before ExitBootServices() is called. This will prevent any malicious PCI devices from being able to perform DMA until the kernel reenables busmastering after configuring the IOMMU. This option may cause failures with some poorly behaved hardware and should not be enabled without testing. The kernel commandline options "efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma" may be used to override the default. Note that PCI devices downstream from PCI bridges are disconnected from their drivers first, using the UEFI driver model API, so that DMA can be disabled safely at the bridge level. [ardb: disconnect PCI I/O handles first, as suggested by Arvind] Co-developed-by: Matthew Garrett <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-01-10efi/x86: Allow translating 64-bit arguments for mixed mode callsArvind Sankar1-4/+1
Introduce the ability to define macros to perform argument translation for the calls that need it, and define them for the boot services that we currently use. When calling 32-bit firmware methods in mixed mode, all output parameters that are 32-bit according to the firmware, but 64-bit in the kernel (ie OUT UINTN * or OUT VOID **) must be initialized in the kernel, or the upper 32 bits may contain garbage. Define macros that zero out the upper 32 bits of the output before invoking the firmware method. When a 32-bit EFI call takes 64-bit arguments, the mixed-mode call must push the two 32-bit halves as separate arguments onto the stack. This can be achieved by splitting the argument into its two halves when calling the assembler thunk. Define a macro to do this for the free_pages boot service. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-30Merge tag 'v5.5-rc4' into locking/kcsan, to resolve conflictsIngo Molnar7-70/+70
Conflicts: init/main.c lib/Kconfig.debug Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Tidy up types and names of global cmdline variablesArd Biesheuvel3-22/+28
Drop leading underscores and use bool not int for true/false variables set on the command line. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Rename efi_call_early/_runtime macros to be more intuitiveArd Biesheuvel9-109/+90
The macros efi_call_early and efi_call_runtime are used to call EFI boot services and runtime services, respectively. However, the naming is confusing, given that the early vs runtime distinction may suggest that these are used for calling the same set of services either early or late (== at runtime), while in reality, the sets of services they can be used with are completely disjoint, and efi_call_runtime is also only usable in 'early' code. So do a global sweep to replace all occurrences with efi_bs_call or efi_rt_call, respectively, where BS and RT match the idiom used by the UEFI spec to refer to boot time or runtime services. While at it, use 'func' as the macro parameter name for the function pointers, which is less likely to collide and cause weird build errors. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop 'table' argument from efi_table_attr() macroArd Biesheuvel2-13/+7
None of the definitions of the efi_table_attr() still refer to their 'table' argument so let's get rid of it entirely. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop protocol argument from efi_call_proto() macroArd Biesheuvel3-14/+11
After refactoring the mixed mode support code, efi_call_proto() no longer uses its protocol argument in any of its implementation, so let's remove it altogether. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub/x86: Work around page freeing issue in mixed modeArd Biesheuvel1-1/+4
Mixed mode translates calls from the 64-bit kernel into the 32-bit firmware by wrapping them in a call to a thunking routine that pushes a 32-bit word onto the stack for each argument passed to the function, regardless of the argument type. This works surprisingly well for most services and protocols, with the exception of ones that take explicit 64-bit arguments. efi_free() invokes the FreePages() EFI boot service, which takes a efi_physical_addr_t as its address argument, and this is one of those 64-bit types. This means that the 32-bit firmware will interpret the (addr, size) pair as a single 64-bit quantity, and since it is guaranteed to have the high word set (as size > 0), it will always fail due to the fact that EFI memory allocations are always < 4 GB on 32-bit firmware. So let's fix this by giving the thunking code a little hand, and pass two values for the address, and a third one for the size. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Remove 'sys_table_arg' from all function prototypesArd Biesheuvel10-139/+111
We have a helper efi_system_table() that gives us the address of the EFI system table in memory, so there is no longer point in passing it around from each function to the next. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop sys_table_arg from printk routinesArd Biesheuvel8-61/+59
As a first step towards getting rid of the need to pass around a function parameter 'sys_table_arg' pointing to the EFI system table, remove the references to it in the printing code, which is represents the majority of the use cases. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Unify the efi_char16_printk implementationsArd Biesheuvel2-9/+9
Use a single implementation for efi_char16_printk() across all architectures. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Get rid of 'sys_table_arg' macro parameterArd Biesheuvel3-1/+14
The efi_call macros on ARM have a dependency on a variable 'sys_table_arg' existing in the scope of the macro instantiation. Since this variable always points to the same data structure, let's create a global getter for it and use that instead. Note that the use of a global variable with external linkage is avoided, given the problems we had in the past with early processing of the GOT tables. While at it, drop the redundant casts in the efi_table_attr and efi_call_proto macros. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Avoid protocol wrapper for file I/O routinesArd Biesheuvel1-10/+7
The EFI file I/O routines built on top of the file I/O firmware services are incompatible with mixed mode, so there is no need to obfuscate them by using protocol wrappers whose only purpose is to hide the mixed mode handling. So let's switch to plain indirect calls instead. This also means we can drop the mixed_mode aliases from the various types involved. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Annotate firmware routines as __efiapiArd Biesheuvel1-4/+6
Annotate all the firmware routines (boot services, runtime services and protocol methods) called in the boot context as __efiapi, and make it expand to __attribute__((ms_abi)) on 64-bit x86. This allows us to use the compiler to generate the calls into firmware that use the MS calling convention instead of the SysV one. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Use stricter typing for firmware function pointersArd Biesheuvel2-4/+5
We will soon remove another level of pointer casting, so let's make sure all type handling involving firmware calls at boot time is correct. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop explicit 32/64-bit protocol definitionsArd Biesheuvel1-10/+0
Now that we have incorporated the mixed mode protocol definitions into the native ones using unions, we no longer need the separate 32/64 bit struct definitions, with the exception of the EFI system table definition and the boot services, runtime services and configuration table definitions. So drop the unused ones. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Distinguish between native/mixed not 32/64 bitArd Biesheuvel1-30/+15
Currently, we support mixed mode by casting all boot time firmware calls to 64-bit explicitly on native 64-bit systems, and to 32-bit on 32-bit systems or 64-bit systems running with 32-bit firmware. Due to this explicit awareness of the bitness in the code, we do a lot of casting even on generic code that is shared with other architectures, where mixed mode does not even exist. This casting leads to loss of coverage of type checking by the compiler, which we should try to avoid. So instead of distinguishing between 32-bit vs 64-bit, distinguish between native vs mixed, and limit all the nasty casting and pointer mangling to the code that actually deals with mixed mode. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Extend native protocol definitions with mixed_mode aliasesArd Biesheuvel2-10/+16
In preparation of moving to a native vs. mixed mode split rather than a 32 vs. 64 bit split when it comes to invoking EFI firmware services, update all the native protocol definitions and redefine them as unions containing an anonymous struct for the native view and a struct called 'mixed_mode' describing the 32-bit view of the protocol when called from 64-bit code. While at it, flesh out some PCI I/O member definitions that we will be needing shortly. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Use a helper to iterate over a EFI handle arrayArd Biesheuvel1-7/+2
Iterating over a EFI handle array is a bit finicky, since we have to take mixed mode into account, where handles are only 32-bit while the native efi_handle_t type is 64-bit. So introduce a helper, and replace the various occurrences of this pattern. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/gop: Unify 32/64-bit functionsArvind Sankar1-116/+18
Use efi_table_attr macro to deal with 32/64-bit firmware using the same source code. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/gop: Convert GOP structures to typedef and clean up some typesArvind Sankar1-13/+13
Use typedef for the GOP structures, in anticipation of unifying 32/64-bit code. Also use more appropriate types in the non-bitness specific structures for the framebuffer address and pointers. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub/random: Initialize pointer variables to zero for mixed modeHans de Goede1-3/+3
Commit: 0d95981438c3 ("x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") causes the drivers/efi/libstub/random.c code to get used on x86 for the first time. But this code was not written with EFI mixed mode in mind (running a 64 bit kernel on 32 bit EFI firmware), this causes the kernel to crash during early boot when running in mixed mode. The problem is that in mixed mode pointers are 64 bit, but when running on a 32 bit firmware, EFI calls which return a pointer value by reference only fill the lower 32 bits of the passed pointer, leaving the upper 32 bits uninitialized which leads to crashes. This commit fixes this by initializing pointers which are passed by reference to EFI calls to NULL before passing them, so that the upper 32 bits are initialized to 0. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Fixes: 0d95981438c3 ("x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-08efi/gop: Fix memory leak in __gop_query32/64()Arvind Sankar1-54/+12
efi_graphics_output_protocol::query_mode() returns info in callee-allocated memory which must be freed by the caller, which we aren't doing. We don't actually need to call query_mode() in order to obtain the info for the current graphics mode, which is already there in gop->mode->info, so just access it directly in the setup_gop32/64() functions. Also nothing uses the size of the info structure, so don't update the passed-in size (which is the size of the gop_handle table in bytes) unnecessarily. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Bhupesh Sharma <[email protected]> Cc: Masayoshi Mizuma <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-08efi/gop: Return EFI_SUCCESS if a usable GOP was foundArvind Sankar1-2/+2
If we've found a usable instance of the Graphics Output Protocol (GOP) with a framebuffer, it is possible that one of the later EFI calls fails while checking if any support console output. In this case status may be an EFI error code even though we found a usable GOP. Fix this by explicitly return EFI_SUCCESS if a usable GOP has been located. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Bhupesh Sharma <[email protected]> Cc: Masayoshi Mizuma <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-08efi/gop: Return EFI_NOT_FOUND if there are no usable GOPsArvind Sankar1-6/+6
If we don't find a usable instance of the Graphics Output Protocol (GOP) because none of them have a framebuffer (i.e. they were all PIXEL_BLT_ONLY), but all the EFI calls succeeded, we will return EFI_SUCCESS even though we didn't find a usable GOP. Fix this by explicitly returning EFI_NOT_FOUND if no usable GOPs are found, allowing the caller to probe for UGA instead. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Bhupesh Sharma <[email protected]> Cc: Masayoshi Mizuma <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-26Merge tag 'acpi-5.5-rc1' of ↵Linus Torvalds3-0/+28
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI updates from Rafael Wysocki: "These update the ACPICA code in the kernel to upstream revision 20191018, add support for EFI specific purpose memory, update the ACPI EC driver to make it work on systems with hardware-reduced ACPI, improve ACPI-based device enumeration for some platforms, rework the lid blacklist handling in the button driver and add more lid quirks to it, unify ACPI _HID/_UID matching, fix assorted issues and clean up the code and documentation. Specifics: - Update the ACPICA code in the kernel to upstream revision 20191018 including: * Fixes for Clang warnings (Bob Moore) * Fix for possible overflow in get_tick_count() (Bob Moore) * Introduction of acpi_unload_table() (Bob Moore) * Debugger and utilities updates (Erik Schmauss) * Fix for unloading tables loaded via configfs (Nikolaus Voss) - Add support for EFI specific purpose memory to optionally allow either application-exclusive or core-kernel-mm managed access to differentiated memory (Dan Williams) - Fix and clean up processing of the HMAT table (Brice Goglin, Qian Cai, Tao Xu) - Update the ACPI EC driver to make it work on systems with hardware-reduced ACPI (Daniel Drake) - Always build in support for the Generic Event Device (GED) to allow one kernel binary to work both on systems with full hardware ACPI and hardware-reduced ACPI (Arjan van de Ven) - Fix the table unload mechanism to unregister platform devices created when the given table was loaded (Andy Shevchenko) - Rework the lid blacklist handling in the button driver and add more lid quirks to it (Hans de Goede) - Improve ACPI-based device enumeration for some platforms based on Intel BayTrail SoCs (Hans de Goede) - Add an OpRegion driver for the Cherry Trail Crystal Cove PMIC and prevent handlers from being registered for unhandled PMIC OpRegions (Hans de Goede) - Unify ACPI _HID/_UID matching (Andy Shevchenko) - Clean up documentation and comments (Cao jin, James Pack, Kacper Piwiński)" * tag 'acpi-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (52 commits) ACPI: OSI: Shoot duplicate word ACPI: HMAT: use %u instead of %d to print u32 values ACPI: NUMA: HMAT: fix a section mismatch ACPI: HMAT: don't mix pxm and nid when setting memory target processor_pxm ACPI: NUMA: HMAT: Register "soft reserved" memory as an "hmem" device ACPI: NUMA: HMAT: Register HMAT at device_initcall level device-dax: Add a driver for "hmem" devices dax: Fix alloc_dax_region() compile warning lib: Uplevel the pmem "region" ida to a global allocator x86/efi: Add efi_fake_mem support for EFI_MEMORY_SP arm/efi: EFI soft reservation to memblock x86/efi: EFI soft reservation to E820 enumeration efi: Common enable/disable infrastructure for EFI soft reservation x86/efi: Push EFI_MEMMAP check into leaf routines efi: Enumerate EFI_MEMORY_SP ACPI: NUMA: Establish a new drivers/acpi/numa/ directory ACPICA: Update version to 20191018 ACPICA: debugger: remove leading whitespaces when converting a string to a buffer ACPICA: acpiexec: initialize all simple types and field units from user input ACPICA: debugger: add field unit support for acpi_db_get_next_token ...
2019-11-16build, kcsan: Add KCSAN build exceptionsMarco Elver1-0/+2
This blacklists several compilation units from KCSAN. See the respective inline comments for the reasoning. Signed-off-by: Marco Elver <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2019-11-07arm/efi: EFI soft reservation to memblockDan Williams2-0/+9
UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the interpretation of the EFI Memory Types as "reserved for a specific purpose". The proposed Linux behavior for specific purpose memory is that it is reserved for direct-access (device-dax) by default and not available for any kernel usage, not even as an OOM fallback. Later, through udev scripts or another init mechanism, these device-dax claimed ranges can be reconfigured and hot-added to the available System-RAM with a unique node identifier. This device-dax management scheme implements "soft" in the "soft reserved" designation by allowing some or all of the reservation to be recovered as typical memory. This policy can be disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with efi=nosoftreserve. For this patch, update the ARM paths that consider EFI_CONVENTIONAL_MEMORY to optionally take the EFI_MEMORY_SP attribute into account as a reservation indicator. Publish the soft reservation as IORES_DESC_SOFT_RESERVED memory, similar to x86. (Based on an original patch by Ard) Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Dan Williams <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-07efi: Common enable/disable infrastructure for EFI soft reservationDan Williams1-0/+19
UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the interpretation of the EFI Memory Types as "reserved for a specific purpose". The proposed Linux behavior for specific purpose memory is that it is reserved for direct-access (device-dax) by default and not available for any kernel usage, not even as an OOM fallback. Later, through udev scripts or another init mechanism, these device-dax claimed ranges can be reconfigured and hot-added to the available System-RAM with a unique node identifier. This device-dax management scheme implements "soft" in the "soft reserved" designation by allowing some or all of the reservation to be recovered as typical memory. This policy can be disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with efi=nosoftreserve. As for this patch, define the common helpers to determine if the EFI_MEMORY_SP attribute should be honored. The determination needs to be made early to prevent the kernel from being loaded into soft-reserved memory, or otherwise allowing early allocations to land there. Follow-on changes are needed per architecture to leverage these helpers in their respective mem-init paths. Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Dan Williams <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-07efi: libstub/tpm: enable tpm eventlog function for ARM platformsXinwei Kong1-0/+2
Wire up the existing code for ARM that loads the TPM event log into OS accessible buffers while running the EFI stub so that the kernel proper can access it at runtime. Tested-by: Zou Cao <[email protected]> Signed-off-by: Xinwei Kong <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>