aboutsummaryrefslogtreecommitdiffstats
path: root/src/interface
Commit message (Collapse)AuthorAgeFilesLines
* [image] Always unregister currently executing imageinterpreterMichael Brown2023-03-071-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We unregister script images during their execution, to prevent a "boot" command from re-executing the containing script. This also has the side effect of preventing executing scripts from showing up within the Linux magic initrd image (or the Multiboot module list). Additional logic in bzimage.c and efi_file.c prevents a currently executing kernel from showing up within the magic initrd image. Similar logic in multiboot.c prevents the Multiboot kernel from showing up as a Multiboot module. This still leaves some corner cases that are not covered correctly. For example: when using a gzip-compressed kernel image, nothing will currently hide the original compressed image from the magic initrd. Fix by moving the logic that temporarily unregisters the current image from script_exec() to image_exec(), so that it applies to all image types, and simplify the magic initrd and Multiboot module list construction logic on the basis that no further filtering of the registered image list is necessary. This change has the side effect of hiding currently executing EFI images from the virtual filesystem exposed by iPXE. For example, when using iPXE to boot wimboot, the wimboot binary itself will no longer be visible within the virtual filesystem. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Consistently use for_each_image() to iterate over imagesMichael Brown2023-03-061-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Omit EFI_LOAD_FILE2_PROTOCOL for a zero-length initrdnoinitrdMichael Brown2023-02-281-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the Linux kernel is being used with no initrd, iPXE will still provide a zero-length initrd.magic file within the virtual filesystem. As of commit 6a004be ("[efi] Support the initrd autodetection mechanism in newer Linux kernels"), this zero-length file will also be exposed via an EFI_LOAD_FILE2_PROTOCOL instance on a handle with a fixed device path. The correct handling of zero-length files via EFI_LOAD_FILE2_PROTOCOL is unfortunately not well defined. Linux expects the first call to LoadFile() to always fail with EFI_BUFFER_TOO_SMALL. When the initrd is genuinely zero-length, iPXE will return success since the buffer is not too small to hold the (zero-length) file. This causes Linux to immediately report a spurious EFI_LOAD_ERROR boot failure. We could change the logic in iPXE's efi_file_load() to always return EFI_BUFFER_TOO_SMALL if Buffer is NULL on entry. Since the correct behaviour of LoadFile() in the corner case of a zero-length file is left undefined by the UEFI specification, this would be permissible. Unfortunately this approach would not fix the problem. If we return EFI_BUFFER_TOO_SMALL and set the file length to zero, then Linux will call the boot services AllocatePages() method with a zero length. In at least the EDK2 implementation, this combination of parameters will cause AllocatePages() to return EFI_OUT_OF_RESOURCES, and Linux will again report a boot failure. Another approach would be to install the initrd device path handle only if we have a non-empty initrd to offer. Unfortunately this would lead to a failure in yet another corner case: if a previous bootloader has installed an initrd device path handle (e.g. to pass a boot script to iPXE) then we must not leave that initrd in place, since then our loaded kernel would end up seeing the wrong initrd content. The cleanest fix seems to be to ensure that the initrd device path handle is installed with the EFI_DEVICE_PATH_PROTOCOL instance present but with the EFI_LOAD_FILE2_PROTOCOL instance absent (and forcibly uninstalled if necessary), matching the state in which we leave the handle after uninstalling our virtual filesystem. Linux will then not find any handle that supports EFI_LOAD_FILE2_PROTOCOL within the fixed device path, and so will fall through to trying other mechanisms to locate the initrd. Reported-by: Chris Bradshaw <cwbshaw@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split out EFI_RNG_PROTOCOL as a separate entropy sourceentropyMichael Brown2023-02-202-90/+123
| | | | | | | | | | | | | | | | | | Commit 7ca801d ("[efi] Use the EFI_RNG_PROTOCOL as an entropy source if available") added EFI_RNG_PROTOCOL as an alternative entropy source via an ad-hoc mechanism specific to efi_entropy.c. Split out EFI_RNG_PROTOCOL to a separate entropy source, and allow the entropy core to handle the selection of RDRAND, EFI_RNG_PROTOCOL, or timer ticks as the active source. The fault detection logic added in commit a87537d ("[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementations") may be removed completely, since the failure will already be detected by the generic ANS X9.82-mandated repetition count test and will now be handled gracefully by the entropy core. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Allow entropy source to be selected at runtimeMichael Brown2023-02-172-8/+31
| | | | | | | | | | | | | | | | | | | | | | | | 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] Support the initrd autodetection mechanism in newer Linux kernelsMichael Brown2023-02-151-0/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 5.7 added the ability to autodetect an initrd by searching for a handle via a fixed vendor-specific "Linux initrd device path" and then locating and using the EFI_LOAD_FILE2_PROTOCOL instance on that handle. This maps quite naturally onto our existing concept of a "magic initrd" as introduced for EFI in commit e5f0255 ("[efi] Provide an "initrd.magic" file for use by UEFI kernels"). Add an EFI_LOAD_FILE2_PROTOCOL instance to our EFI virtual files (backed by simply calling the existing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL method to read from the file), and install the protocol instance for the "initrd.magic" virtual file onto a new device handle that also provides the Linux initrd device path. The design choice in Linux of using a single fixed device path makes this unfortunately messy to support, since device paths must be unique within a system. When multiple bootloaders are used (e.g. GRUB loading iPXE loading Linux) then only one bootloader can ever install the device path onto a handle. Subsequent bootloaders must locate the existing handle and replace the load file protocol instance with their own. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix debug message when reading from EFI virtual filesMichael Brown2023-02-151-1/+1
| | | | | | | Show the requested range when a caller reads from a virtual file via the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not attempt to drive PCI bridge devicesefibridgeMichael Brown2023-02-031-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | The "bridge" driver introduced in 3aa6b79 ("[pci] Add minimal PCI bridge driver") is required only for BIOS builds using the ENA driver, where experimentation shows that we cannot rely on the BIOS to fully assign MMIO addresses. Since the driver is a valid PCI driver, it will end up binding to all PCI bridge devices even on a UEFI platform, where the firmware is likely to have completed MMIO address assignment correctly. This has no impact on most systems since there is generally no UEFI driver for PCI bridges: the enumeration of the whole PCI bus is handled by the PciBusDxe driver bound to the root bridge. Experimentation shows that at least one laptop will freeze at the point that iPXE attempts to bind to the bridge device. No deeper investigation has been carried out to find the root cause. Fix by causing efipci_supported() to return an error unless the configuration space header type indicates a non-bridge device. Reported-by: Marcel Petersen <mp@sbe.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow autoexec script to be located alongside iPXE binaryMichael Brown2023-02-012-21/+73
| | | | | | | | | 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] Accept a command line passed to an iPXE image via LoadOptionsMichael Brown2023-01-292-0/+156
| | | | | | | | | 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>
* [legal] Add missing FILE_LICENCE declaration to efi_path.cMichael Brown2023-01-281-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Extend efi_locate_device() to allow searching up the device pathMichael Brown2023-01-231-14/+42
| | | | | | | | 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-7/+20
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_terminate() utility functionMichael Brown2023-01-233-30/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Create VLAN autoboot device automaticallyautovlanMichael Brown2023-01-151-0/+9
| | | | | | | When chainloading iPXE from an EFI VLAN device, configure the corresponding iPXE VLAN device to be created automatically. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [autoboot] Include VLAN tag in filter for identifying autoboot deviceMichael Brown2023-01-152-3/+13
| | | | | | | | | | | | | 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>
* [netdevice] Separate concept of scope ID from network device name indexMichael Brown2023-01-142-3/+3
| | | | | | | | | | | | | | | | | | | | | The network device index currently serves two purposes: acting as a sequential index for network device names ("net0", "net1", etc), and acting as an opaque unique integer identifier used in socket address scope IDs. There is no particular need for these usages to be linked, and it can lead to situations in which devices are named unexpectedly. For example: if a system has two network devices "net0" and "net1", a VLAN is created as "net1-42", and then a USB NIC is connected, then the USB NIC will be named "net3" rather than the expected "net2" since the VLAN device "net1-42" will have consumed an index. Separate the usages: rename the "index" field to "scope_id" (matching its one and only use case), and assign the name without reference to the scope ID by finding the first unused name. For consistency, assign the scope ID by similarly finding the first unused scope ID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Include VLAN tag in filter for applying cached DHCPACKMichael Brown2022-12-222-6/+14
| | | | | | | | | | | | | | | 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/+23
| | | | | | | | | | | | | | | | | | 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-222-15/+39
| | | | | | | 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] Allow passing a NULL device path to path utility functionsMichael Brown2022-12-222-5/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide VLAN configuration protocolMichael Brown2022-12-142-2/+219
| | | | | | | | | | | | | | | | | | | | | | | 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>
* [efi] Clear DMA-coherent buffers before mappingioactiveMichael Brown2022-11-041-0/+3
| | | | | | | | | | | | | | | | | | | The DMA mapping is performed implicitly as part of the call to dma_alloc(). The current implementation creates the IOMMU mapping for the allocated and potentially uninitialised data before returning to the caller (which will immediately zero out or otherwise initialise the buffer). This leaves a small window within which a malicious PCI device could potentially attempt to retrieve firmware-owned secrets present in the uninitialised buffer. (Note that the hypothetically malicious PCI device has no viable way to know the address of the buffer from which to attempt a DMA read, rendering the attack extremely implausible.) Guard against any such hypothetical attacks by zeroing out the allocated buffer prior to creating the coherent DMA mapping. Suggested-by: Mateusz Siwiec <Mateusz.Siwiec@ioactive.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise pci_num_bus() to pci_discover()Michael Brown2022-09-152-2/+2
| | | | | | | | | | 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>
* [linux] Add missing PROVIDE_PCIAPI_INLINE() macrosMichael Brown2022-09-151-0/+9
| | | | | | | Ensure type consistency of the PCI I/O API methods by adding the missing PROVIDE_PCIAPI_INLINE() macros. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Support Unicode character output via framebuffer consoleMichael Brown2022-03-151-3/+48
| | | | | | | Extend the glyph cache to include a number of dynamic entries that are populated on demand whenever a non-ASCII character needs to be drawn. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fbcon] Support Unicode character outputMichael Brown2022-03-151-70/+128
| | | | | | | Accumulate UTF-8 characters in fbcon_putchar(), and require the frame buffer console's .glyph() method to accept Unicode character values. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Support Unicode character output via text consoleMichael Brown2022-03-151-1/+17
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support AltGr to access ASCII characters via remappingMichael Brown2022-02-151-0/+3
| | | | | | | | | | | | | Several keyboard layouts define ASCII characters as accessible only via the AltGr modifier. Add support for this modifier to ensure that all ASCII characters are accessible. Experiments suggest that the BIOS console is likely to fail to generate ASCII characters when the AltGr key is pressed. Work around this limitation by accepting LShift+RShift (which will definitely produce an ASCII character) as a synonym for AltGr. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Centralise handling of key modifiersMichael Brown2022-02-151-16/+28
| | | | | | | Handle Ctrl and CapsLock key modifiers within key_remap(), to provide consistent behaviour across different console types. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Support keyboard remapping via the EFI consoleMichael Brown2022-02-101-0/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Attempt to fetch autoexec script via TFTPMichael Brown2022-01-181-0/+176
| | | | | | | | | | | | | | | | | Attempt to fetch the autoexec.ipxe script via TFTP using the PXE base code protocol installed on the loaded image's device handle, if present. This provides a generic alternative to the use of an embedded script for chainloaded binaries, which is particularly useful in a UEFI Secure Boot environment since it allows the script to be modified without the need to sign a new binary. As a side effect, this also provides a third method for breaking the PXE chainloading loop (as an alternative to requiring an embedded script or custom DHCP server configuration). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for autoexec scripts that are not located in a filesystemMichael Brown2022-01-181-21/+41
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Support formatting UUIDs as little-endian GUIDsMichael Brown2022-01-041-1/+2
| | | | | | | | | | | | | | | | | | The RFC4122 specification defines UUIDs as being in network byte order, but an unfortunately significant amount of (mostly Microsoft) software treats them as having the first three fields in little-endian byte order. In an ideal world, any server-side software that compares UUIDs for equality would perform an endian-insensitive comparison (analogous to comparing strings for equality using a case-insensitive comparison), and would therefore not care about byte order differences. Define a setting type name ":guid" to allow a UUID setting to be formatted in little-endian order, to simplify interoperability with server-side software that expects such a formatting. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disable EFI watchdog timer when shutting down to boot an OSMichael Brown2021-11-251-0/+34
| | | | | | | | | | | | | | | The UEFI specification mandates that the EFI watchdog timer should be disabled by the platform firmware as part of the ExitBootServices() call, but some platforms (e.g. Hyper-V) are observed to occasionally forget to do so, resulting in a reboot approximately five minutes after starting the operating system. Work around these firmware bugs by disabling the watchdog timer ourselves. Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Run ExitBootServices shutdown hook at TPL_NOTIFYshutdown_tpl_notifyMichael Brown2021-11-233-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Raise TPL during driver unload entry pointMichael Brown2021-11-221-0/+7
| | | | | | | | | | | | The efi_unload() function is currently missing the calls to raise and restore the TPL. This has the side effect of causing iPXE to return from the driver unload entry point at TPL_CALLBACK, which will cause unexpected behaviour (typically a system lockup) shortly afterwards. Fix by adding the missing calls to raise and restore the TPL. Debugged-by: Petr Borsodi <petr.borsodi@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Modify global system table when wrapping a loaded imageMichael Brown2021-11-211-43/+56
| | | | | | | | | | | | | | | | | | | 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>
* [efi] Do not attempt to use console output after ExitBootServices()Michael Brown2021-11-211-3/+6
| | | | | | | | | A successful call to ExitBootServices() will result in the EFI console becoming unusable. Ensure that the EFI wrapper produces a complete line of debug output before calling the wrapped ExitBootServices() method, and attempt subsequent debug output only if the call fails. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Record cached ProxyDHCPOFFER and PXEBSACK, if presentMichael Brown2021-07-271-3/+26
| | | | | | | | | | | | | | | | | | | Commit cd3de55 ("[efi] Record cached DHCPACK from loaded image's device handle, if present") added the ability for a chainloaded UEFI iPXE to reuse an IPv4 address and DHCP options previously obtained by a built-in PXE stack, without needing to perform a second DHCP request. Extend this to also record the cached ProxyDHCPOFFER and PXEBSACK 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 a boot filename or other options that were provided via a ProxyDHCP or PXE boot server mechanism, rather than by standard DHCP. Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Veto the Itautec Ip4ConfigDxe driveritautecMichael Brown2021-06-111-8/+10
| | | | | | | | | | | | | | | The Ip4ConfigDxe driver bug that was observed on Dell systems in commit 64b4452 ("[efi] Blacklist the Dell Ip4ConfigDxe driver") has also been observed on systems with a manufacturer name of "Itautec S.A.". The symptoms of the bug are identical: an attempt to call DisconnectController() on the LOM device handle will lock up the system. Fix by extending the veto to cover the Ip4ConfigDxe driver for this manufacturer. Debugged-by: Celso Viana <celso.vianna@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide an "initrd.magic" file for use by UEFI kernelsMichael Brown2021-05-211-0/+88
| | | | | | | | | | | | | | | | | | | | | | | Provide a file "initrd.magic" via the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL that contains the initrd file as constructed for BIOS bzImage kernels (including injected files with CPIO headers constructed by iPXE). This allows BIOS and UEFI kernels to obtain the exact same initramfs image, by adding "initrd=initrd.magic" to the kernel command line. For example: #!ipxe kernel boot/vmlinuz initrd=initrd.magic initrd boot/initrd.img initrd boot/modules/e1000.ko /lib/modules/e1000.ko initrd boot/modules/af_packet.ko /lib/modules/af_packet.ko boot Do not include the "initrd.magic" file within the root directory listing, since doing so would break software such as wimboot that processes all files within the root directory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for non-image-backed virtual filesMichael Brown2021-05-211-69/+221
| | | | | | | | Restructure the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL implementation to allow for the existence of virtual files that are not simply backed by a single underlying image. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Show ACPI address space descriptor ranges in debug messagesMichael Brown2021-04-211-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Always map full length of coherent DMA buffer allocationMichael Brown2021-04-201-1/+2
| | | | | | | | | | | | | | | The EFI PCI API takes a page count as the input to AllocateBuffer() but a byte count as the input to Map(). There is nothing in the UEFI specification that requires us to map exactly the allocated length, and no systems have yet been observed that will fail if the map length does not exactly match the allocated length. However, it is plausible that some implementations may fail if asked to map a length that does not match the length of the corresponding allocation. Avoid potential future problems by always mapping the full allocated length. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Avoid infinite loop on allocation failure in xenstore_response()Michael Brown2021-04-201-6/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Fail at link time if building slirp.linux without libslirpMichael Brown2021-03-111-29/+3
| | | | | | | | | | | | | | | | | | | | The iPXE build system is constructed for a standalone codebase with no external dependencies, and does not have any equivalent of the standard userspace ./configure script. We currently check for the ability to include slirp/libslirp.h and conditionalise portions of linux_api.c on its presence. The actual slirp driver code is built unconditionally, as with all iPXE drivers. This currently leads to a silent runtime failure if attempting to use slirp.linux built on a system that was missing slirp/libslirp.h. Convert this to a link-time failure by deliberately omitting the relevant symbols from linux_api.c when slirp/libslirp.h is not present. This allows other builds (e.g. tap.linux or tests.linux) to succeed: the link-time failure will occur only if the slirp driver is included within the build target. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Do not assume that stat() works on sysfs filesMichael Brown2021-03-031-29/+20
| | | | | | | | Linux kernel 3.12 and earlier report a zero size via stat() for all ACPI table files in sysfs. There is no way to determine the file size other than by reading the file until EOF. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Validate length of ACPI table read from sysfsMichael Brown2021-03-031-0/+10
| | | | | | | | | | | | | Consumers of acpi_find() will assume that returned structures include a valid table header and that the length in the table header is correct. These assumptions are necessary when dealing with raw ACPI tables, since there exists no independent source of length information. Ensure that these assumptions are also valid for ACPI tables read from sysfs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Use fstat() rather than statx()Michael Brown2021-03-032-8/+7
| | | | | | | | | | | | The statx() system call has a clean header file and a consistent layout, but was unfortunately added only in kernel 4.11. Using stat() or fstat() directly is extremely messy since glibc does not necessarily use the kernel native data structures. However, as the only current use case is to obtain the length of an open file, we can merely provide a wrapper that does precisely this. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-24 02:33:06 +0000