aboutsummaryrefslogtreecommitdiffstats
path: root/src/include/ipxe/efi
Commit message (Collapse)AuthorAgeFilesLines
* [efi] Fix dependency list construction in EDK2 header import scriptMichael Brown2023-11-241-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-11-226-26/+65
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include protocol interface address in debug outputMichael Brown2023-06-081-0/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add HTTP header and GUID definitionsMichael Brown2023-06-072-0/+518
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add DNS headers and GUID definitionsMichael Brown2023-06-073-0/+1077
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add Ip4Config2 header and GUID definitionMichael Brown2023-06-072-0/+319
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add IPv6 versions of existing IPv4 headers and GUID definitionsMichael Brown2023-06-077-0/+4364
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-06-078-40/+266
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disable static assertions in EFI headers on non-EFI platformsMichael Brown2023-06-071-0/+9
| | | | | | | | | | | | | The EDK2 headers may be included even in builds for non-EFI platforms. Commits such as 9de6c45 ("[arm] Use -fno-short-enums for all 32-bit ARM builds") have so far ensured that the compile-time checks within the EDK2 headers will pass even when building for a non-EFI platform. As a more general solution, temporarily disable static assertions while including UefiBaseType.h if building on a non-EFI platform. This avoids the need to modify the ABI on other platforms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Support versions of shim that perform SBAT verificationMichael Brown2023-05-231-0/+1
| | | | | | | | | | | | | | | The UEFI shim implements a fairly nicely designed revocation mechanism designed around the concept of security generations. Unfortunately nobody in the shim community has thus far added the relevant metadata to the Linux kernel, with the result that current versions of shim are incapable of booting current versions of the Linux kernel. Experience shows that there is unfortunately no point in trying to get a fix for this upstreamed into shim. We therefore default to working around this undesirable behaviour by patching data read from the "SbatLevel" variable used to hold SBAT configuration. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for executing images via a shimMichael Brown2023-05-222-0/+50
| | | | | | | | | | | | | | | | | | | | | | | Add support for using a shim as a helper to execute an EFI image. When a shim has been specified via shim(), the shim image will be passed to LoadImage() instead of the selected EFI image and the command line will be prepended with the name of the selected EFI image. The selected EFI image will be accessible to the shim via the virtual filesystem as a hidden file. Reduce the Secure Boot attack surface by removing, where possible, the spurious requirement for a third party second stage loader binary such as GRUB to be used solely in order to call the "shim lock protocol" entry point. Do not install the EFI PXE APIs when using a shim, since if shim finds EFI_PXE_BASE_CODE_PROTOCOL on the loaded image's device handle then it will attempt to download files afresh instead of using the files already downloaded by iPXE and exposed via the EFI_SIMPLE_FILE_SYSTEM protocol. (Experience shows that there is no point in trying to get a fix for this upstreamed into shim.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add definitions for the UEFI shim lock protocolMichael Brown2023-05-222-0/+32
| | | | | | | | | The UEFI shim includes a "shim lock protocol" that can be used by a third party second stage loader such as GRUB to verify a kernel image. Add definitions for the relevant portions of this protocol interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_asprintf() and efi_vasprintf()Michael Brown2023-05-221-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Allow entropy source to be selected at runtimeMichael Brown2023-02-171-35/+0
| | | | | | | | | | | | | | | | | | | | | | | | As noted in commit 3c83843 ("[rng] Check for several functioning RTC interrupts"), experimentation shows that Hyper-V cannot be trusted to reliably generate RTC interrupts. (As noted in commit f3ba0fb ("[hyperv] Provide timer based on the 10MHz time reference count MSR"), Hyper-V appears to suffer from a general problem in reliably generating any legacy interrupts.) An alternative entropy source is therefore required for an image that may be used in a Hyper-V Gen1 virtual machine. The x86 RDRAND instruction provides a suitable alternative entropy source, but may not be supported by all CPUs. We must therefore allow for multiple entropy sources to be compiled in, with the single active entropy source selected only at runtime. Restructure the internal entropy API to allow a working entropy source to be detected and chosen at runtime. Enable the RDRAND entropy source for all x86 builds, since it is likely to be substantially faster than any other source. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow autoexec script to be located alongside iPXE binaryMichael Brown2023-02-011-1/+2
| | | | | | | | | Try loading the autoexec.ipxe script first from the directory containing the iPXE binary (based on the relative file path provided to us via EFI_LOADED_IMAGE_PROTOCOL), then fall back to trying the root directory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-02-012-12/+12
| | | | | | | Update to pick up the upstream commit bda715b ("MdePkg: Fix UINT64 and INT64 word length for LoongArch64"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Accept a command line passed to an iPXE image via LoadOptionsMichael Brown2023-01-291-0/+18
| | | | | | | | | Treat a command line passed to iPXE via UEFI LoadOptions as an image to be registered at startup, as is already done for the .lkrn, .pxe, and .exe BIOS images. Originally-implemented-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [la64] Import LoongArch64 ProcessorBind.h from EDK2 headersMichael Brown2023-01-283-2/+128
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-01-2895-15321/+14255
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark ConsoleControl.h as a non-imported headerMichael Brown2023-01-281-0/+5
| | | | | | | | | | | The obsolete ConsoleControl.h header is no longer present in the current EDK2 codebase, but is still required for interoperability with old iMacs. Add an iPXE include guard to this file so that the EDK2 header import script will no longer attempt to import it from the EDK2 tree. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove deleted directories from EDK2 header import scriptMichael Brown2023-01-281-2/+1
| | | | | | | | The IntelFrameworkPkg and EdkCompatibilityPkg directories have been removed from the EDK2 codebase. Remove these directories from the EDK2 header import script. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for whitespace before #include in imported EDK2 header filesMichael Brown2023-01-281-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Detect SPDX licence identifiers in imported EDK2 headersMichael Brown2023-01-281-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Build util/efirom as a host-only binaryMichael Brown2023-01-281-0/+3
| | | | | | | | | As with util/elf2efi32 and util/elf2efi64 in commit a99e435 ("[efi] Do not rely on ProcessorBind.h when building host binaries"), build util/efirom without using any architecture-specific EDK2 headers since the build host's CPU architecture may not be supported by EDK2. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Extend efi_locate_device() to allow searching up the device pathMichael Brown2023-01-231-1/+1
| | | | | | | | Extend the functionality of efi_locate_device() to allow callers to find instances of the protocol that may exist further up the device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_prev() utility functionMichael Brown2023-01-231-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_terminate() utility functionMichael Brown2023-01-231-0/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not rely on ProcessorBind.h when building host binariesprocessorbindMichael Brown2023-01-201-4/+38
| | | | | | | | | | | | | We cannot rely on the EDK2 ProcessorBind.h headers when compiling a binary for execution on the build host itself (e.g. elf2efi), since the host's CPU architecture may not even be supported by EDK2. Fix by skipping ProcessorBind.h when building a host binary, and defining the bare minimum required to allow other EDK2 headers to compile cleanly. Reported-by: Michal Suchánek <msuchanek@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [autoboot] Include VLAN tag in filter for identifying autoboot deviceMichael Brown2023-01-151-1/+2
| | | | | | | | | | | | | When chainloading iPXE from a VLAN device, the MAC address of the loaded image's device handle will match the MAC address of the trunk device created by iPXE, and the autoboot process will then erroneously consider the trunk device to be an autoboot device. Fix by recording the VLAN tag along with the MAC address, and treating the VLAN tag as part of the filter used to match the MAC address against candidate network devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Include VLAN tag in filter for applying cached DHCPACKMichael Brown2022-12-221-1/+2
| | | | | | | | | | | | | | | When chainloading iPXE from a VLAN device, the MAC address within the cached DHCPACK will match the MAC address of the trunk device created by iPXE, and the cached DHCPACK will then end up being erroneously applied to the trunk device. This tends to break outbound IPv4 routing, since both the trunk and VLAN devices will have the same assigned IPv4 address. Fix by recording the VLAN tag along with the cached DHCPACK, and treating the VLAN tag as part of the filter used to match the cached DHCPACK against candidate network devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_vlan() utility functionMichael Brown2022-12-221-0/+1
| | | | | | | | | | | | | | | | | | EFI provides no API for determining the VLAN tag (if any) for a specified device handle. There is the EFI_VLAN_CONFIG_PROTOCOL, but that exists only on the trunk device handle (not on the VLAN device handle), and provides no way to match VLAN tags against the trunk device's child device handles. The EDK2 codebase seems to rely solely on the device path to determine the VLAN tag for a specified device handle: both NetLibGetVlanId() and BmGetNetworkDescription() will parse the device path to search for a VLAN_DEVICE_PATH component. Add efi_path_vlan() which uses the same device path parsing logic to determine the VLAN tag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose efi_path_next() utility functionMichael Brown2022-12-221-0/+2
| | | | | | | Provide a single central implementation of the logic for stepping through elements of an EFI device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide VLAN configuration protocolMichael Brown2022-12-142-0/+5
| | | | | | | | | | | | | | | | | | | | | | | UEFI implements VLAN support within the Managed Network Protocol (MNP) driver, which may create child VLAN devices automatically based on stored UEFI variables. These child devices do not themselves provide a raw-packet interface via EFI_SIMPLE_NETWORK_PROTOCOL, and may be consumed only via the EFI_MANAGED_NETWORK_PROTOCOL interface. The device paths constructed for these child devices may conflict with those for the EFI_SIMPLE_NETWORK_PROTOCOL instances that iPXE attempts to install for its own VLAN devices. The upshot is that creating an iPXE VLAN device (e.g. via the "vcreate" command) will fail if the UEFI Managed Network Protocol has already created a device for the same VLAN tag. Fix by providing our own EFI_VLAN_CONFIG_PROTOCOL instance on the same device handle as EFI_SIMPLE_NETWORK_PROTOCOL. This causes the MNP driver to treat iPXE's device as supporting hardware VLAN offload, and it will therefore not attempt to install its own instance of the protocol. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise pci_num_bus() to pci_discover()Michael Brown2022-09-151-5/+8
| | | | | | | | | | Allow pci_find_next() to discover devices beyond the first PCI segment, by generalising pci_num_bus() (which implicitly assumes that there is only a single PCI segment) with pci_discover() (which has the ability to return an arbitrary contiguous chunk of PCI bus:dev.fn address space). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Run ExitBootServices shutdown hook at TPL_NOTIFYshutdown_tpl_notifyMichael Brown2021-11-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some systems (observed with the Thunderbolt ports on a ThinkPad X1 Extreme Gen3 and a ThinkPad P53), if the IOMMU is enabled then the system firmware will install an ExitBootServices notification event that disables bus mastering on the Thunderbolt xHCI controller and all PCI bridges, and destroys any extant IOMMU mappings. This leaves the xHCI controller unable to perform any DMA operations. As described in commit 236299b ("[xhci] Avoid DMA during shutdown if firmware has disabled bus mastering"), any subsequent DMA operation attempted by the xHCI controller will end up completing after the operating system kernel has reenabled bus mastering, resulting in a DMA operation to an area of memory that the hardware is no longer permitted to access and, on Windows with the Driver Verifier enabled, a STOP 0xE6 (DRIVER_VERIFIER_DMA_VIOLATION). That commit avoids triggering any DMA attempts during the shutdown of the xHCI controller itself. However, this is not a complete solution since any attached and opened USB device (e.g. a USB NIC) may asynchronously trigger DMA attempts that happen to occur after bus mastering has been disabled but before we reset the xHCI controller. Avoid this problem by installing our own ExitBootServices notification event at TPL_NOTIFY, thereby causing it to be invoked before the firmware's own ExitBootServices notification event that disables bus mastering. This unsurprisingly causes the shutdown hook itself to be invoked at TPL_NOTIFY, which causes a fatal error when later code attempts to raise the TPL to TPL_CALLBACK (which is a lower TPL). Work around this problem by redefining the "internal" iPXE TPL to be variable, and set this internal TPL to TPL_NOTIFY when the shutdown hook is invoked. Avoid calling into an underlying SNP protocol instance from within our shutdown hook at TPL_NOTIFY, since the underlying SNP driver may attempt to raise the TPL to TPL_CALLBACK (which would cause a fatal error). Failing to shut down the underlying SNP device is safe to do since the underlying device must, in any case, have installed its own ExitBootServices hook if any shutdown actions are required. Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Modify global system table when wrapping a loaded imageMichael Brown2021-11-211-1/+1
| | | | | | | | | | | | | | | | | | | The EFI loaded image protocol allows an image to be provided with a custom system table, and we currently use this mechanism to wrap any boot services calls made by the loaded image in order to provide strace-like debugging via DEBUG=efi_wrap. The ExitBootServices() call will modify the global system table, leaving the loaded image using a system table that is no longer current. When DEBUG=efi_wrap is used, this generally results in the machine locking up at the point that the loaded operating system calls ExitBootServices(). Fix by modifying the global EFI system table to point to our wrapper functions, instead of providing a custom system table via the loaded image protocol. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for platforms that provide ACPI tables individuallyMichael Brown2021-03-011-0/+13
| | | | | | | | | | | | | | | | The ACPI API currently expects platforms to provide access to a single contiguous ACPI table. Some platforms (e.g. Linux userspace) do not provide a convenient way to obtain the entire ACPI table, but do provide access to individual tables. All iPXE consumers of the ACPI API require access only to individual tables. Redefine the internal API to make acpi_find() an API method, with all existing implementations delegating to the current RSDT-based implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Record cached DHCPACK from loaded image's device handle, if presentMichael Brown2021-02-171-0/+16
| | | | | | | | | | | Record the cached DHCPACK obtained from the EFI_PXE_BASE_CODE_PROTOCOL instance installed on the loaded image's device handle, if present. This allows a chainloaded UEFI iPXE to reuse the IPv4 address and DHCP options previously obtained by the built-in PXE stack, as is already done for a chainloaded BIOS iPXE. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split out autoexec script portions of efi_autoboot.cMichael Brown2021-02-172-1/+19
| | | | | | | | | | | The "autoboot device" and "autoexec script" functionalities in efi_autoboot.c are unrelated except in that they both need to be invoked by efiprefix.c before device drivers are loaded. Split out the autoexec script portions to a separate file to avoid potential confusion. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove support for building with the Intel C compilerMichael Brown2021-02-121-5/+0
| | | | | | | | | | | | | | | | | | | Support for building with the Intel C compiler (icc) was added in 2009 in the expectation that UEFI support would eventually involve compiling iPXE to EFI Byte Code. EFI Byte Code has never found any widespread use: no widely available compilers can emit it, Microsoft refuses to sign EFI Byte Code binaries for UEFI Secure Boot, and I have personally never encountered any examples of EFI Byte Code in the wild. The support for using the Intel C compiler has not been tested in over a decade, and would almost certainly require modification to work with current releases of the compiler. Simplify the build process by removing this old legacy code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow EFI_USB_IO_PROTOCOL interfaces to be nullified and leakedMichael Brown2020-12-171-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow vetoing of drivers that cannot be unloadedMichael Brown2020-11-301-1/+1
| | | | | | | | | | | | | | | | Some UEFI drivers (observed with the "Usb Xhci Driver" on an HP EliteBook) are particularly badly behaved: they cannot be unloaded and will leave handles opened with BY_DRIVER attributes even after disconnecting the driver, thereby preventing a replacement iPXE driver from opening the handle. Allow such drivers to be vetoed by falling back to a brute-force mechanism that will disconnect the driver from all handles, uninstall the driver binding protocol (to prevent it from attaching to any new handles), and finally close any stray handles that the vetoed driver has left open. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split out dbg_efi_opener() as a standalone functionMichael Brown2020-11-301-0/+22
| | | | | | | Allow external code to dump the information for an opened protocol information entry via DBG_EFI_OPENER() et al. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid dropping below TPL as at entry to iPXEMichael Brown2020-11-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iPXE will currently drop to TPL_APPLICATION whenever the current system time is obtained via currticks(), since the system time mechanism relies on a timer that can fire only when the TPL is below TPL_CALLBACK. This can cause unexpected behaviour if the system time is obtained in the middle of an API call into iPXE by external code. For example, MnpDxe sets up a 10ms periodic timer running at TPL_CALLBACK to poll the underling EFI_SIMPLE_NETWORK_PROTOCOL device for received packets. If the resulting poll within iPXE happens to hit a code path that requires obtaining the current system time (e.g. due to reception of an STP packet, which affects iPXE's blocked link timer), then iPXE will end up temporarily dropping to TPL_APPLICATION. This can potentially result in retriggering the MnpDxe periodic timer, causing code to be unexpectedly re-entered. Fix by recording the external TPL at any entry point into iPXE and dropping only as far as this external TPL, rather than dropping unconditionally to TPL_APPLICATION. The side effect of this change is that iPXE's view of the current system time will be frozen for the duration of any API calls made into iPXE by external code at TPL_CALLBACK or above. Since any such external code is already responsible for allowing execution at TPL_APPLICATION to occur, then this should not cause a problem in practice. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Rename efi_blacklist to efi_vetoMichael Brown2020-11-072-13/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Retain a long-lived reference to the EFI_PCI_IO_PROTOCOL instanceMichael Brown2020-11-041-2/+10
| | | | | | | | | | | | | | | Provide opened EFI PCI devices with access to the underlying EFI_PCI_IO_PROTOCOL instance, in order to facilitate the future use of the DMA mapping methods within the fast data path. Do not require the use of this stored EFI_PCI_IO_PROTOCOL instance for memory-mapped I/O (since the entire point of memory-mapped I/O as a concept is to avoid this kind of unnecessary complexity) or for slow-path PCI configuration space accesses (since these may be required for access to PCI bus:dev.fn addresses that do not correspond to a device bound via our driver binding protocol instance). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Nullify interfaces and leak memory on uninstallation failureMichael Brown2020-10-262-1/+32
| | | | | | | | | | | | | | | The UEFI specification allows uninstallation of a protocol interface to fail. There is no sensible way for code to react to this, since uninstallation is likely to be taking place on a code path that cannot itself fail (e.g. a code path that is itself a failure path). Where the protocol structure exists within a dynamically allocated block of memory, this leads to possible use-after-free bugs. Work around this unfortunate design choice by nullifying the protocol (i.e. overwriting the method pointers with no-ops) and leaking the memory containing the protocol structure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Allow SRP device to be described using an EFI device pathMichael Brown2020-10-231-0/+3
| | | | | | | | | The UEFI specification provides a partial definition of an Infiniband device path structure. Use this structure to construct what may be a plausible path containing at least some of the information required to identify an SRP target device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fcp] Allow Fibre Channel device to be described using an EFI device pathMichael Brown2020-10-221-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Allow iSCSI device to be described using an EFI device pathMichael Brown2020-10-201-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-24 00:49:14 +0000