- 17 6月, 2020 1 次提交
-
-
由 Ard Biesheuvel 提交于
On 32-bit ARM, we may boot at HYP mode, or with the MMU and caches off (or both), even though the EFI spec does not actually support this. While booting at HYP mode is something we might tolerate, fiddling with the caches is a more serious issue, as disabling the caches is tricky to do safely from C code, and running without the Dcache makes it impossible to support unaligned memory accesses, which is another explicit requirement imposed by the EFI spec. So take note of the CPU mode and MMU state in the EFI stub diagnostic output so that we can easily diagnose any issues that may arise from this. E.g., EFI stub: Entering in SVC mode with MMU enabled Also, capture the CPSR and SCTLR system register values at EFI stub entry, and after ExitBootServices() returns, and check whether the MMU and Dcache were disabled at any point. If this is the case, a diagnostic message like the following will be emitted: efi: [Firmware Bug]: EFI stub was entered with MMU and Dcache disabled, please fix your firmware! efi: CPSR at EFI stub entry : 0x600001d3 efi: SCTLR at EFI stub entry : 0x00c51838 efi: CPSR after ExitBootServices() : 0x600001d3 efi: SCTLR after ExitBootServices(): 0x00c50838 Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Reviewed-by: NLeif Lindholm <leif@nuviainc.com>
-
- 15 6月, 2020 1 次提交
-
-
由 Gustavo A. R. Silva 提交于
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. Lastly, make use of the sizeof_field() helper instead of an open-coded version. This issue was found with the help of Coccinelle and audited _manually_. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: NKees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20200527171425.GA4053@embeddedorSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
- 21 5月, 2020 2 次提交
-
-
由 Arvind Sankar 提交于
Add video=efifb:list option to list the modes that are available. Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-20-nivedita@alum.mit.eduSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Arvind Sankar 提交于
Add the required typedefs etc for using con_in's simple text input protocol, and for using the boottime event services. Also add the prototype for the "stall" boot service. Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-19-nivedita@alum.mit.eduSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
- 17 5月, 2020 1 次提交
-
-
由 Benjamin Thiel 提交于
Pull up arch-specific prototype efi_systab_show_arch() in order to fix a -Wmissing-prototypes warning: arch/x86/platform/efi/efi.c:957:7: warning: no previous prototype for ‘efi_systab_show_arch’ [-Wmissing-prototypes] char *efi_systab_show_arch(char *str) Signed-off-by: NBenjamin Thiel <b.thiel@posteo.de> Link: https://lore.kernel.org/r/20200516132647.14568-1-b.thiel@posteo.deSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
- 24 4月, 2020 1 次提交
-
-
由 Ard Biesheuvel 提交于
Increase legibility by adding whitespace to the efi_config_table_type_t arrays that describe which EFI config tables we look for when going over the firmware provided list. While at it, replace the 'name' char pointer with a char array, which is more space efficient on relocatable 64-bit kernels, as it avoids a 8 byte pointer and the associated relocation data (24 bytes when using RELA format) Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
- 27 3月, 2020 1 次提交
-
-
由 Benjamin Thiel 提交于
... in order to fix a -Wmissing-ptototypes warning: arch/x86/platform/efi/quirks.c:245:13: warning: no previous prototype for ‘efi_arch_mem_reserve’ [-Wmissing-prototypes] \ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size) Signed-off-by: NBenjamin Thiel <b.thiel@posteo.de> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200326135041.3264-1-b.thiel@posteo.de
-
- 03 3月, 2020 2 次提交
-
-
由 Hans de Goede 提交于
Just like with PCI options ROMs, which we save in the setup_efi_pci* functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself sometimes may contain data which is useful/necessary for peripheral drivers to have access to. Specifically the EFI code may contain an embedded copy of firmware which needs to be (re)loaded into the peripheral. Normally such firmware would be part of linux-firmware, but in some cases this is not feasible, for 2 reasons: 1) The firmware is customized for a specific use-case of the chipset / use with a specific hardware model, so we cannot have a single firmware file for the chipset. E.g. touchscreen controller firmwares are compiled specifically for the hardware model they are used with, as they are calibrated for a specific model digitizer. 2) Despite repeated attempts we have failed to get permission to redistribute the firmware. This is especially a problem with customized firmwares, these get created by the chip vendor for a specific ODM and the copyright may partially belong with the ODM, so the chip vendor cannot give a blanket permission to distribute these. This commit adds support for finding peripheral firmware embedded in the EFI code and makes the found firmware available through the new efi_get_embedded_fw() function. Support for loading these firmwares through the standard firmware loading mechanism is added in a follow-up commit in this patch-series. Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end of start_kernel(), just before calling rest_init(), this is on purpose because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for early_memremap(), so the check must be done after mm_init(). This relies on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services() is called, which means that this will only work on x86 for now. Reported-by: NDave Olsthoorn <dave@bewaar.me> Suggested-by: NPeter Jones <pjones@redhat.com> Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-3-hdegoede@redhat.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Hans de Goede 提交于
Sometimes it is useful to be able to dump the efi boot-services code and data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, but only if efi=debug is passed on the kernel-commandline as this requires not freeing those memory-regions, which costs 20+ MB of RAM. Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-2-hdegoede@redhat.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
- 29 2月, 2020 1 次提交
-
-
由 Tom Lendacky 提交于
When booting with SME active, EFI tables must be mapped unencrypted since they were built by UEFI in unencrypted memory. Update the list of tables to be checked during early_memremap() processing to account for the EFI RNG seed table. Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Signed-off-by: NIngo Molnar <mingo@kernel.org> Cc: linux-efi@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: David Hildenbrand <david@redhat.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Link: https://lore.kernel.org/r/b64385fc13e5d7ad4b459216524f138e7879234f.1582662842.git.thomas.lendacky@amd.com Link: https://lore.kernel.org/r/20200228121408.9075-3-ardb@kernel.org
-
- 24 2月, 2020 21 次提交
-
-
由 Ard Biesheuvel 提交于
Take the newly introduced EFI_RT_PROPERTIES_TABLE configuration table into account, which carries a mask of which EFI runtime services are still functional after ExitBootServices() has been called by the OS. Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
Revision 2.8 of the UEFI spec introduces provisions for firmware to advertise lack of support for certain runtime services at OS runtime. Let's store this mask in struct efi for easy access. Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
Push the FDT params specific types and definition into fdtparams.c, and instead, pass a reference to the memory map data structure and populate it directly, and return the system table address as the return value. Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
The systab member in struct efi has outlived its usefulness, now that we have better ways to access the only piece of information we are interested in after init, which is the EFI runtime services table address. So instead of instantiating a doctored copy at early boot with lots of mangled values, and switching the pointer when switching into virtual mode, let's grab the values we need directly, and get rid of the systab pointer entirely. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
Instead of going through the EFI system table each time, just copy the runtime services table pointer into struct efi directly. This is the last use of the system table pointer in struct efi, allowing us to drop it in a future patch, along with a fair amount of quirky handling of the translated address. Note that usually, the runtime services pointer changes value during the call to SetVirtualAddressMap(), so grab the updated value as soon as that call returns. (Mixed mode uses a 1:1 mapping, and kexec boot enters with the updated address in the system table, so in those cases, we don't need to do anything here) Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
There is some code that exposes physical addresses of certain parts of the EFI firmware implementation via sysfs nodes. These nodes are only used on x86, and are of dubious value to begin with, so let's move their handling into the x86 arch code. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
config_parse_tables() is a jumble of pointer arithmetic, due to the fact that on x86, we may be dealing with firmware whose native word size differs from the kernel's. This is not a concern on other architectures, and doesn't quite justify the state of the code, so let's clean it up by adding a non-x86 code path, constifying statically allocated tables and replacing preprocessor conditionals with IS_ENABLED() checks. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
The efi_config_init() routine is no longer shared with ia64 so let's move it into the x86 arch code before making further x86 specific changes to it. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
We have three different versions of the code that checks the EFI system table revision and copies the firmware vendor string, and they are mostly equivalent, with the exception of the use of early_memremap_ro vs. __va() and the lowest major revision to warn about. Let's move this into common code and factor out the commonalities. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
There is no need for struct efi to carry the address of the memreserve table and share it with the world. So move it out and make it __initdata as well. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
The memory attributes table is only used at init time by the core EFI code, so there is no need to carry its address in struct efi that is shared with the world. So move it out, and make it __ro_after_init as well, considering that the value is set during early boot. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
Move the rng_seed table address from struct efi into a static global variable in efi.c, which is the only place we ever refer to it anyway. This reduces the footprint of struct efi, which is a r/w data structure that is shared with the world. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
The UGA table is x86 specific (its handling was introduced when the EFI support code was modified to accommodate IA32), so there is no need to handle it in generic code. The EFI properties table is not strictly x86 specific, but it was deprecated almost immediately after having been introduced, due to implementation difficulties. Only x86 takes it into account today, and this is not going to change, so make this table x86 only as well. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
The HCDP and MPS tables are Itanium specific EFI config tables, so move their handling to ia64 arch code. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
Some plumbing exists to handle a UEFI configuration table of type BOOT_INFO but since we never match it to a GUID anywhere, we never actually register such a table, or access it, for that matter. So simply drop all mentions of it. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub: - it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86) - otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM) In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether. In the second case, we force the bootloader to duplicate knowledge about the boot protocol which is already encoded in the stub, and which may be subject to change over time, e.g., bootparams struct definitions, memory allocation/alignment requirements for the placement of the initrd etc etc. In the ARM case, it also requires the bootloader to modify the hardware description provided by the firmware, as it is passed in the same file. On systems where the initrd is measured after loading, it creates a time window where the initrd contents might be manipulated in memory before handing over to the kernel. Address these concerns by adding support for loading the initrd into memory by invoking the EFI LoadFile2 protocol installed on a vendor GUIDed device path that specifically designates a Linux initrd. This addresses the above concerns, by putting the EFI stub in charge of placement in memory and of passing the base and size to the kernel proper (via whatever means it desires) while still leaving it up to the firmware or bootloader to obtain the file contents, potentially from other file systems than the one the kernel itself was loaded from. On platforms that implement measured boot, it permits the firmware to take the measurement right before the kernel actually consumes the contents. Acked-by: NLaszlo Ersek <lersek@redhat.com> Tested-by: NIlias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: NIlias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
In preparation of adding support for loading the initrd via a special device path, add the struct definition of a vendor GUIDed device path node to efi.h. Since we will be producing these data structures rather than just consumsing the ones instantiated by the firmware, refactor the various device path node definitions so we can take the size of each node using sizeof() rather than having to resort to opaque arithmetic in the static initializers. While at it, drop the #if IS_ENABLED() check for the declaration of efi_get_device_by_path(), which is unnecessary, and constify its first argument as well. Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ardb@kernel.org>
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ardb@kernel.org>
-
- 20 1月, 2020 3 次提交
-
-
由 Dan Williams 提交于
Dave noticed that when specifying multiple efi_fake_mem= entries only the last entry was successfully being reflected in the efi memory map. This is due to the fact that the efi_memmap_insert() is being called multiple times, but on successive invocations the insertion should be applied to the last new memmap rather than the original map at efi_fake_memmap() entry. Rework efi_fake_memmap() to install the new memory map after each efi_fake_mem= entry is parsed. This also fixes an issue in efi_fake_memmap() that caused it to litter emtpy entries into the end of the efi memory map. An empty entry causes efi_memmap_insert() to attempt more memmap splits / copies than efi_memmap_split_count() accounted for when sizing the new map. When that happens efi_memmap_insert() may overrun its allocation, and if you are lucky will spill over to an unmapped page leading to crash signature like the following rather than silent corruption: BUG: unable to handle page fault for address: ffffffffff281000 [..] RIP: 0010:efi_memmap_insert+0x11d/0x191 [..] Call Trace: ? bgrt_init+0xbe/0xbe ? efi_arch_mem_reserve+0x1cb/0x228 ? acpi_parse_bgrt+0xa/0xd ? acpi_table_parse+0x86/0xb8 ? acpi_boot_init+0x494/0x4e3 ? acpi_parse_x2apic+0x87/0x87 ? setup_acpi_sci+0xa2/0xa2 ? setup_arch+0x8db/0x9e1 ? start_kernel+0x6a/0x547 ? secondary_startup_64+0xb6/0xc0 Commit af164898 "x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage" introduced more occurrences where efi_memmap_insert() is invoked after an efi_fake_mem= configuration has been parsed. Previously the side effects of vestigial empty entries were benign, but with commit af164898 that follow-on efi_memmap_insert() invocation triggers efi_memmap_insert() overruns. Reported-by: NDave Young <dyoung@redhat.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Signed-off-by: NIngo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20191231014630.GA24942@dhcp-128-65.nay.redhat.com Link: https://lore.kernel.org/r/20200113172245.27925-14-ardb@kernel.org
-
由 Dan Williams 提交于
In preparation for fixing efi_memmap_alloc() leaks, add support for recording whether the memmap was dynamically allocated from slab, memblock, or is the original physical memmap provided by the platform. Given this tracking is established in efi_memmap_alloc() and needs to be carried to efi_memmap_install(), use 'struct efi_memory_map_data' to convey the flags. Some small cleanups result from this reorganization, specifically the removal of local variables for 'phys' and 'size' that are already tracked in @data. Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Signed-off-by: NIngo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-12-ardb@kernel.org
-
由 Dan Williams 提交于
In preparation for garbage collecting dynamically allocated EFI memory maps, where the allocation method of memblock vs slab needs to be recalled, convert the existing 'late' flag into a 'flags' bitmask. Arrange for the flag to be passed via 'struct efi_memory_map_data'. This structure grows additional flags in follow-on changes. Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Signed-off-by: NIngo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-11-ardb@kernel.org
-
- 11 1月, 2020 3 次提交
-
-
由 Matthew Garrett 提交于
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: NMatthew Garrett <mjg59@google.com> Signed-off-by: NMatthew Garrett <mjg59@google.com> Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Matthew Garrett <matthewgarrett@google.com> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20200103113953.9571-18-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Ard Biesheuvel 提交于
The routines efi_runtime_init32() and efi_runtime_init64() are almost indistinguishable, and the only relevant difference is the offset in the runtime struct from where to obtain the physical address of the SetVirtualAddressMap() routine. However, this address is only used once, when installing the virtual address map that the OS will use to invoke EFI runtime services, and at the time of the call, we will necessarily be running with a 1:1 mapping, and so there is no need to do the map/unmap dance here to retrieve the address. In fact, in the preceding changes to these users, we stopped using the address recorded here entirely. So let's just get rid of all this code since it no longer serves a purpose. While at it, tweak the logic so that we handle unsupported and disable EFI runtime services in the same way, and unmap the EFI memory map in both cases. Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Matthew Garrett <mjg59@google.com> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20200103113953.9571-12-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Ard Biesheuvel 提交于
All EFI firmware call prototypes have been annotated as __efiapi, permitting us to attach attributes regarding the calling convention by overriding __efiapi to an architecture specific value. On 32-bit x86, EFI firmware calls use the plain calling convention where all arguments are passed via the stack, and cleaned up by the caller. Let's add this to the __efiapi definition so we no longer need to cast the function pointers before invoking them. Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Matthew Garrett <mjg59@google.com> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20200103113953.9571-6-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 25 12月, 2019 3 次提交
-
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-20-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-19-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-15-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-