summaryrefslogtreecommitdiffstats
path: root/src/include/ipxe/efi
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-142-0/+4
| | | | | | | | | Some past security reviews carried out for UEFI Secure Boot signing submissions have covered specific drivers or functional areas of iPXE. Mark all of the files comprising these areas as permitted for UEFI Secure Boot. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-1436-0/+36
| | | | | | | | | | | | Mark all files used in a standard build of bin-x86_64-efi/snponly.efi as permitted for UEFI Secure Boot. These files represent the core functionality of iPXE that is guaranteed to have been included in every binary that was previously subject to a security review and signed by Microsoft. It is therefore legitimate to assume that at least these files have already been reviewed to the required standard multiple times. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark imported EDK2 headers as permitted for Secure BootMichael Brown2026-01-13123-2/+126
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2026-01-131-22/+22
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for creating devices with no EFI parent deviceMichael Brown2025-11-251-2/+2
| | | | | | | | | | | | | | On some systems (observed on an AWS m8g.medium instance in eu-west-2), the UEFI firmware fails to enumerate some of the underlying hardware devices. On these systems, we cannot comply with the UEFI device model by adding our SNP device as a child of the hardware device and appending to the parent hardware device path, since no parent hardware device has been created. Work around these systems by allowing for the creation of SNP devices with no parent device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow probing permission to vary by rangeMichael Brown2025-11-251-1/+2
| | | | | | | Make pci_can_probe() part of the runtime selectable PCI I/O API, and defer this check to the per-range API. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Wrap a selection of runtime services callsMichael Brown2025-11-131-0/+1
| | | | | | | Allow DEBUG=efi_wrap to trace various runtime services calls as well as the existing boot services calls. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add image security database GUID definitionMichael Brown2025-11-121-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add Microsoft vendor GUID definitionMichael Brown2025-11-123-1/+60
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add storage security command protocol header and GUID definitionMichael Brown2025-11-122-0/+213
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2025-11-1217-66/+239
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark Arm/ProcessorBind.h as a non-imported headerMichael Brown2025-11-111-0/+6
| | | | | | | | | | | Support for ARM32 has been removed from the EDK2 codebase. However, we may as well retain the ability to build iPXE for existing EFI platforms. 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] Mark Ip4Config.h as a non-imported headerMichael Brown2025-11-111-0/+5
| | | | | | | | | | | | The Ip4Config.h header has been removed from the EDK2 codebase as obsolete. However, we may still encounter it in the wild and so it is useful to retain the GUID and the corresponding protocol name for debug messages. 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] Mark UgaDraw.h as a non-imported headerMichael Brown2025-11-111-0/+5
| | | | | | | | | | | | The UgaDraw.h header has been removed from the EDK2 codebase as obsolete. However, we may still encounter it in the wild and so it is useful to retain the GUID and the corresponding protocol name for debug messages. 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] Skip including the EDK2 ProcessorBind.h header for 32-bit RISC-VMichael Brown2025-11-111-33/+40
| | | | | | | | | | | | | | | | We currently include the EDK2 RiscV64/ProcessorBind.h header when building for 32-bit RISC-V, as a placeholder since there is no support for 32-bit RISC-V in upstream EDK2. This causes errors when attempting to use the EDK2 VA_START() et al macros, since RiscV64/ProcessorBind.h ends up defining UINTN with a size different from the size of a pointer. Fix by falling back to the generic definitions for UINTN etc (as used for EFI_HOSTONLY) whenever we don't have an architecture-specific ProcessorBind.h header available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add ability to extract device path from an EFI load optionMichael Brown2025-08-291-0/+5
| | | | | | | | | | | | | An EFI boot option (stored in a BootXXXX variable) comprises an EFI_LOAD_OPTION structure, which includes some undefined number of EFI device paths. (The structure is extremely messy and awkward to parse in C, but that's par for the course with EFI.) Add a function to extract the first device path from an EFI load option, along with wrapper functions to read and extract the first device path from an EFI boot variable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow compiler to perform type checks on EFI_EVENTMichael Brown2025-07-151-4/+7
| | | | | | | | | | | | As with EFI_HANDLE, the EFI headers define EFI_EVENT as a void pointer, rendering EFI_EVENT compatible with a pointer to itself and hence guaranteeing that pointer type bugs will be introduced. Redefine EFI_EVENT as a pointer to an anonymous structure (as we already do for EFI_HANDLE) to allow the compiler to perform type checking as expected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Drop to external TPL for calls to ConnectController()Michael Brown2025-07-141-0/+2
| | | | | | | | | | | | | | | There is nothing in the current versions of the UEFI specification that limits the TPL at which we may call ConnectController() or DisconnectController(). However, at least some platforms (observed with a Lenovo ThinkPad T14s Gen 5) will occasionally and unpredictably lock up before returning from ConnectController() if called at a TPL higher than TPL_APPLICATION. Work around whatever defect is present on these systems by dropping to the current external TPL for all calls to ConnectController() or DisconnectController(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide efi_tpl_name() for transcribing TPLs in debug messagesMichael Brown2025-07-141-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Remove userptr_t from ACPI table parsingMichael Brown2025-04-221-2/+2
| | | | | | | Simplify the ACPI table parsing code by assuming that all table content is fully accessible via pointer dereferences. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove userptr_t from ASN.1 parsersMichael Brown2025-04-221-2/+1Star
| | | | | | | | | Simplify the ASN.1 code by assuming that all objects are fully accessible via pointer dereferences. This allows the concept of "additional data beyond the end of the cursor" to be removed, and simplifies parsing of all ASN.1 image formats. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for custom methods for disconnecting existing driversMichael Brown2025-04-171-2/+8
| | | | | | | | Allow for greater control over the process used to disconnect existing drivers from a device handle, by converting the "exclude" field from a simple protocol GUID to a per-driver method. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Populate boot arguments in constructed device treeMichael Brown2025-04-011-1/+1
| | | | | | | | When creating a device tree to pass to a booted operating system, ensure that the "chosen" node exists, and populate the "bootargs" property with the image command line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disconnect existing drivers on a per-protocol basisMichael Brown2025-03-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UEFI does not provide a direct method to disconnect the existing driver of a specific protocol from a handle. We currently use DisconnectController() to remove all drivers from a handle that we want to drive ourselves, and then rely on recursion in the call to ConnectController() to reconnect any drivers that did not need to be disconnected in the first place. Experience shows that OEMs tend not to ever test the disconnection code paths in their UEFI drivers, and it is common to find drivers that refuse to disconnect, fail to close opened handles, fail to function correctly after reconnection, or lock up the entire system. Implement a more selective form of disconnection, in which we use OpenProtocolInformation() to identify the driver associated with a specific protocol, and then disconnect only that driver. Perform disconnections in reverse order of attachment priority, since this is the order likely to minimise the number of cascaded implicit disconnections. This allows our MNP driver to avoid performing any disconnections at all, since it does not require exclusive access to the MNP protocol. It also avoids performing unnecessary disconnections and reconnections of unrelated drivers such as the "UEFI WiFi Connection Manager" that attaches to wireless network interfaces in order to manage wireless network associations. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Define an attachment priority order for EFI driversMichael Brown2025-03-291-2/+4
| | | | | | | | Define an ordering for internal EFI drivers on the basis of how close the driver is to the hardware, and attempt to start drivers in this order. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add various well-known GUIDs encountered in WiFi bootMichael Brown2025-03-285-0/+1285
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Install a device tree for the booted OS, if availableMichael Brown2025-03-281-0/+17
| | | | | | | | | | | | | If we have a device tree available (e.g. because the user has explicitly downloaded a device tree using the "fdt" command), then provide it to the booted operating system as an EFI configuration table. Since x86 does not typically use device trees, we create weak symbols for efi_fdt_install() and efi_fdt_uninstall() to avoid dragging FDT support into all x86 UEFI binaries. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for installing EFI configuration tablesMichael Brown2025-03-271-0/+37
| | | | | | | Add the ability to install and uninstall arbitrary EFI configuration tables. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add flattened device tree header and GUID definitionsMichael Brown2025-03-273-2/+27
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add ACPI and SMBIOS tables as well-known GUIDsMichael Brown2025-03-271-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow use of typed pointers for efi_open() et alMichael Brown2025-03-241-8/+79
| | | | | | | | | Provide wrapper macros to allow efi_open() and related functions to accept a pointer to any pointer type as the "interface" argument, in order to allow a substantial amount of type adjustment boilerplate to be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Create safe wrappers for OpenProtocol() and CloseProtocol()Michael Brown2025-03-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The UEFI model for opening and closing protocols is broken by design and cannot be repaired. Calling OpenProtocol() to obtain a protocol interface pointer does not, in general, provide any guarantees about the lifetime of that pointer. It is theoretically possible that the pointer has already become invalid by the time that OpenProtocol() returns the pointer to its caller. (This can happen when a USB device is physically removed, for example.) Various UEFI design flaws make it occasionally necessary to hold on to a protocol interface pointer despite the total lack of guarantees that the pointer will remain valid. The UEFI driver model overloads the semantics of OpenProtocol() to accommodate the use cases of recording a driver attachment (which is modelled as opening a protocol with EFI_OPEN_PROTOCOL_BY_DRIVER attributes) and recording the existence of a related child controller (which is modelled as opening a protocol with EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER attributes). The parameters defined for CloseProtocol() are not sufficient to allow the implementation to precisely identify the matching call to OpenProtocol(). While the UEFI model appears to allow for matched open and close pairs, this is merely an illusion. Calling CloseProtocol() will delete *all* matching records in the protocol open information tables. Since the parameters defined for CloseProtocol() do not include the attributes passed to OpenProtocol(), this means that a matched open/close pair using EFI_OPEN_PROTOCOL_GET_PROTOCOL can inadvertently end up deleting the record that defines a driver attachment or the existence of a child controller. This in turn can cause some very unexpected side effects, such as allowing other UEFI drivers to start controlling hardware to which iPXE believes it has exclusive access. This rarely ends well. To prevent this kind of inadvertent deletion, we establish a convention for four different types of protocol opening: - ephemeral opens: always opened with ControllerHandle = NULL - unsafe opens: always opened with ControllerHandle = AgentHandle - by-driver opens: always opened with ControllerHandle = Handle - by-child opens: always opened with ControllerHandle != Handle This convention ensures that the four types of open never overlap within the set of parameters defined for CloseProtocol(), and so a close of one type cannot inadvertently delete the record corresponding to a different type. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove the efipci_open() and efipci_close() wrappersMichael Brown2025-03-241-3/+0Star
| | | | | | | In preparation for formalising the way that EFI protocols are opened across the codebase, remove the efipci_open() wrapper. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow wrapping the global boot services table in situMichael Brown2025-03-201-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | When DEBUG=efi_wrap is enabled, we construct a patched copy of the boot services table and patch the global system table to point to this copy. This ensures that any subsequently loaded EFI binaries will call our wrappers. Previously loaded EFI binaries will typically have cached the boot services table pointer (in the gBS variable used by EDK2 code), and therefore will not pick up the updated pointer and so will not call our wrappers. In most cases, this is what we want to happen: we are interested in tracing the calls issued by the newly loaded binary and we do not want to be distracted by the high volume of boot services calls issued by existing UEFI drivers. In some circumstances (such as when a badly behaved OEM driver is causing the system to lock up during the ExitBootServices() call), it can be very useful to be able to patch the global boot services table in situ, so that we can trace calls issued by existing drivers. Restructure the wrapping code to allow wrapping to be enabled or disabled at any time, and to allow for patching the global boot services table in situ. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI_RNG_PROTOCOL_GUID as a well-known GUIDMichael Brown2025-03-181-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add TLS authentication header and GUID definitionsMichael Brown2025-03-133-1/+28
| | | | | | | | | | | | | Add the TlsAuthentication.h header from EDK2's NetworkPkg, along with a GUID definition for EFI_TLS_CA_CERTIFICATE_GUID. It is unclear whether or not the TlsCaCertificate variable is intended to be a UEFI standard. Its presence in NetworkPkg (rather than MdePkg) suggests not, but the choice of EFI_TLS_CA_CERTIFICATE_GUID (rather than e.g. EDKII_TLS_CA_CERTIFICATE_GUID) suggests that it is intended to be included in future versions of the standard. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI_GLOBAL_VARIABLE as a well-known GUIDMichael Brown2025-03-131-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Support extracting certificates from EFI signature list imagesMichael Brown2025-03-111-0/+22
| | | | | | | | | | | Add support for the EFI signature list image format (as produced by tools such as efisecdb). The parsing code does not require any EFI boot services functions and so may be enabled even in non-EFI builds. We default to enabling it only for EFI builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI_SIGNATURE_LIST header and GUID definitionsMichael Brown2025-03-104-0/+753
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2025-03-1012-159/+265
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark UsbHostController.h as a non-imported headerMichael Brown2025-03-101-0/+5
| | | | | | | | | | | | The UsbHostController.h header has been removed from the EDK2 codebase since it was never defined in a released UEFI specification. However, we may still encounter it in the wild and so it is useful to retain the GUID and the corresponding protocol name for debug messages. 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] Add EFI_TCG2_PROTOCOL header and GUID definitionMichael Brown2024-12-172-0/+338
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2024-12-1719-84/+535
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Rename UACCESS_EFI to UACCESS_FLATMichael Brown2024-10-251-103/+0Star
| | | | | | | | | Running with flat physical addressing is a fairly common early boot environment. Rename UACCESS_EFI to UACCESS_FLAT so that this code may be reused in non-UEFI boot environments that also use flat physical addressing. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the RISC-V CPU architectureMichael Brown2024-09-152-0/+179
| | | | | | | | | | | | | | | | | | | | | | | | Add support for building iPXE as a 64-bit or 32-bit RISC-V binary, for either UEFI or Linux userspace platforms. For example: # RISC-V 64-bit UEFI make CROSS=riscv64-linux-gnu- bin-riscv64-efi/ipxe.efi # RISC-V 32-bit UEFI make CROSS=riscv64-linux-gnu- bin-riscv32-efi/ipxe.efi # RISC-V 64-bit Linux make CROSS=riscv64-linux-gnu- bin-riscv64-linux/tests.linux qemu-riscv64 -L /usr/riscv64-linux-gnu/sys-root \ ./bin-riscv64-linux/tests.linux # RISC-V 32-bit Linux make CROSS=riscv64-linux-gnu- SYSROOT=/usr/riscv32-linux-gnu/sys-root \ bin-riscv32-linux/tests.linux qemu-riscv32 -L /usr/riscv32-linux-gnu/sys-root \ ./bin-riscv32-linux/tests.linux Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise definition of efi_cpu_nap()Michael Brown2024-09-131-0/+18
| | | | | | | | | Define a cpu_halt() function which is architecture-specific but platform-independent, and merge the multiple architecture-specific implementations of the EFI cpu_nap() function into a single central efi_cpu_nap() that uses cpu_halt() if applicable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow discovery of PCI bus:dev.fn address rangesMichael Brown2024-08-151-14/+0Star
| | | | | | | | | | | Generalise the logic for identifying the matching PCI root bridge I/O protocol to allow for identifying the closest matching PCI bus:dev.fn address range, and use this to provide PCI address range discovery (while continuing to inhibit automatic PCI bus probing). This allows the "pciscan" command to work as expected under UEFI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Separate permission to probe buses from bus:dev.fn range discoveryMichael Brown2024-08-151-0/+10
| | | | | | | | | | | | | | | | | The UEFI device model requires us to not probe the PCI bus directly, but instead to wait to be offered the opportunity to drive devices via our driver service binding handle. We currently inhibit PCI bus probing by having pci_discover() return an empty range when using the EFI PCI I/O API. This has the unwanted side effect that scanning the bus manually using the "pciscan" command will also fail to discover any devices. Separate out the concept of being allowed to probe PCI buses from the mechanism for discovering PCI bus:dev.fn address ranges, so that this limitation may be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Restructure handling of autoexec.ipxe scriptMichael Brown2024-04-031-4/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently attempt to obtain the autoexec.ipxe script via early use of the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or EFI_PXE_BASE_CODE_PROTOCOL interfaces to obtain an opaque block of memory, which is then registered as an image at an appropriate point during our startup sequence. The early use of these existent interfaces allows us to obtain the script even if our subsequent actions (e.g. disconnecting drivers in order to connect up our own) may cause the script to become inaccessible. This mirrors the approach used under BIOS, where the autoexec.ipxe script is provided by the prefix (e.g. as an initrd image when using the .lkrn build of iPXE) and so must be copied into a normally allocated image from wherever it happens to previously exist in memory. We do not currently have support for downloading an autoexec.ipxe script if we were ourselves downloaded via UEFI HTTP boot. There is an EFI_HTTP_PROTOCOL defined within the UEFI specification, but it is so poorly designed as to be unusable for the simple purpose of downloading an additional file from the same directory. It provides almost nothing more than a very slim wrapper around EFI_TCP4_PROTOCOL (or EFI_TCP6_PROTOCOL). It will not handle redirection, content encoding, retries, or even fundamentals such as the Content-Length header, leaving all of this up to the caller. The UEFI HTTP Boot driver will install an EFI_LOAD_FILE_PROTOCOL instance on the loaded image's device handle. This looks promising at first since it provides the LoadFile() API call which is specified to accept an arbitrary filename parameter. However, experimentation (and inspection of the code in EDK2) reveals a multitude of problems that prevent this from being usable. Calling LoadFile() will idiotically restart the entire DHCP process (and potentially pop up a UI requiring input from the user for e.g. a wireless network password). The filename provided to LoadFile() will be ignored. Any downloaded file will be rejected unless it happens to match one of the limited set of types expected by the UEFI HTTP Boot driver. The list of design failures and conceptual mismatches is fairly impressive. Choose to bypass every possible aspect of UEFI HTTP support, and instead use our own HTTP client and network stack to download the autoexec.ipxe script over a temporary MNP network device. Since this approach works for TFTP as well as HTTP, drop the direct use of EFI_PXE_BASE_CODE_PROTOCOL. For consistency and simplicity, also drop the direct use of EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and rely upon our existing support to access local files via "file:" URIs. This approach results in console output during the "iPXE initialising devices...ok" message that appears while startup is in progress. Remove the trailing "ok" so that this intermediate output appears at a sensible location on the screen. The welcome banner that will be printed immediately afterwards provides an indication that startup has completed successfully even absent the explicit "ok". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add the ability to create a temporary MNP network deviceMichael Brown2024-03-291-0/+20
| | | | | | | | | | An MNP network device may be temporarily and non-destructively installed on top of an existing UEFI network stack without having to disconnect existing drivers. Add the ability to create such a temporary network device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-04 19:24:31 +0100