aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-09-13[netdevice] Allocate private data for each network upper-layer drivernetstateMichael Brown13-34/+109
Allow network upper-layer drivers (such as LLDP, which attaches to each network device in order to provide a corresponding LLDP settings block) to specify a size for private data, which will be allocated as part of the network device structure (as with the existing private data allocated for the underlying device driver). This will allow network upper-layer drivers to be simplified by omitting memory allocation and freeing code. If the upper-layer driver requires a reference counter (e.g. for interface initialisation), then it may use the network device's existing reference counter, since this is now the reference counter for the containing block of memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-13[netdevice] Remove netdev_priv() helper functionMichael Brown23-193/+182
Some network device drivers use the trivial netdev_priv() helper function while others use the netdev->priv pointer directly. Standardise on direct use of netdev->priv, in order to free up the function name netdev_priv() for reuse. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-05[librm] Use explicit operand size when pushing a label addressopsizeMichael Brown1-2/+4
We currently use "push $1f" within inline assembly to push the address of the real-mode code fragment, relying on the assembler to treat this as "pushl" for 32-bit code or "pushq" for 64-bit code. As of binutils commit 5cc0077 ("x86: further adjust extend-to-32bit- address conditions"), first included in binutils-2.41, this implicit operand size is no longer calculated as expected and 64-bit builds will fail with Error: operand size mismatch for `push' Fix by adding an explicit operand size to the "push" instruction. Originally-fixed-by: Justin Cano <jstncno@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-08-22[virtio] Fix implementation of vpm_ioread32()Alexander Eichner1-2/+2
The current implementation of vpm_ioread32() erroneously reads only 16 bits of data, which fails when used with the (stricter) virtio device emulation in VirtualBox. Fix by using the correct readl()/inl() I/O wrappers. Reworded-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-19[dhcp] Request NTP server optionntpsettingCornelius Hoffmann1-3/+4
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-19[ntp] Define NTP server settingMichael Brown2-0/+13
Define the IPv4 NTP server setting to simplify the use of a DHCP-provided NTP server in scripts, using e.g. #!ipxe dhcp ntp ${ntp} Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-07[console] Restore compatibility with "--key" values in existing scriptskeyvalsMichael Brown3-3/+31
Commit 3ef4f7e ("[console] Avoid overlap between special keys and Unicode characters") renumbered the special key encoding to avoid collisions with Unicode key values outside the ASCII range. This change broke backwards compatibility with existing scripts that specify key values using e.g. "prompt --key" or "menu --key". Restore compatibility with existing scripts by tweaking the special key encoding so that the relative key value (i.e. the delta from KEY_MIN) is numerically equal to the old pre-Unicode key value, and by modifying parse_key() to accept a relative key value. Reported-by: Sven Dreyer <sven@dreyer-net.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-05[linux] Set a default MAC address for tap devicesMichael Brown1-0/+5
Avoid the need to always specify a local MAC address on the command line by setting a default hardware MAC address (using the same default address as for slirp devices). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-05[linux] Fix error control flow in af_packet_nic_probe()Michael Brown1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-05[linux] Fix error control flow in tap_probe()Michael Brown1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-05[netdevice] Stop link block timer when device is closedMichael Brown1-1/+4
A running link block timer holds a reference to the network device and will prevent it from being freed until the timer expires. It is impossible for free_netdev() to be called while the timer is still running: the call to stop_timer() therein is therefore a no-op. Stop the link block timer when the device is closed, to allow a link-blocked device to be freed immediately upon unregistration of the device. (Since link block state is updated in response to received packets, the state is effectively undefined for a closed device: there is therefore no reason to leave the timer running.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-04[interface] Fix debug message values for temporary interfacestmpintfMichael Brown3-17/+59
The interface debug message values constructed by INTF_DBG() et al rely on the interface being embedded within a containing object. This assumption is not valid for the temporary outbound-only interfaces constructed on the stack by intf_shutdown() and xfer_vredirect(). Formalise the notion of a temporary outbound-only interface as having a NULL interface descriptor, and overload the "original interface descriptor" field to contain a pointer to the original interface that the temporary interface is shadowing. Originally-fixed-by: Vincent Fazio <vfazio@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-04[build] Inhibit more linker warnings about an implied executable stackMichael Brown1-0/+1
Add .note.GNU-stack section declarations to the autogenerated PCI device ID list objects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-04[build] Silence the "creating blib.a" messageMichael Brown1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-04[console] Avoid overlap between special keys and Unicode charactersMichael Brown3-31/+77
The special key range (from KEY_MIN upwards) currently overlaps with the valid range for Unicode characters, and therefore prohibits the use of Unicode key values outside the ASCII range. Create space for Unicode key values by moving the special keys to the range immediately above the maximum valid Unicode character. This allows the existing encoding of special keys as an efficiently packed representation of the equivalent ANSI escape sequence to be maintained almost as-is. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-04[console] Avoid overlap between remapping flags and character valuesMichael Brown1-4/+4
The keyboard remapping flags currently occupy bits 8 and upwards of the to-be-mapped character value. This overlaps the range used for special keys (KEY_MIN and upwards) and also overlaps the valid Unicode character range. No conflict is created by this overlap, since by design only ASCII character values (as generated by an ASCII-only keyboard driver) are subject to remapping, and so the to-be-remapped character values exist in a conceptually separate namespace from either special keys or non-ASCII Unicode characters. However, the overlap is potentially confusing for readers of the code. Minimise cognitive load by using bits 24 and upwards for the keyboard remapping flags. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-07-03[build] Use separate code segment if supported by linkerMichael Brown2-0/+14
Some versions of ld will complain that the automatically created (and unused by our build process) ELF program headers include a "LOAD segment with RWX permissions". Silence this warning by adding "-z separate-code" to the linker options, where supported. For BIOS builds, where the prefix will generally require writable access to its own (tiny) code segment, simply inhibit the warning completely via "--no-warn-rwx-segments". Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-30[build] Inhibit linker warnings about an implied executable stackGeert Stappers32-0/+33
Signed-off-by: Geert Stappers <stappers@stappers.it> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-30[build] Avoid using multiple target patterns in pattern rulesMichael Brown2-3/+13
Multiple target patterns in pattern rules are treated as grouped targets regardless of the separator character. Newer verions of make will generate "warning: pattern recipe did not update peer target" to warn that the rule was expected to update all of the (implicitly) grouped targets. Fix by splitting all multiple target pattern rules into single target pattern rules. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-29[loong64] Add support for building EFI binariesXiaotian Wu2-0/+19
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-29[loong64] Add CPU sleeping API for EFI LoongArch64Xiaotian Wu4-1/+75
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-29[loong64] Add I/O API for LoongArch64Xiaotian Wu3-0/+130
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-29[ioapi] Centralise definitions for dummy PIOMichael Brown3-50/+70
There is no common standard for I/O-space access for non-x86 CPU families, and non-MMIO peripherals are vanishingly rare. Generalise the existing ARM definitions for dummy PIO to allow for reuse by other CPU architectures. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-29[arm] Add missing arch/arm/core source directoryMichael Brown2-2/+4
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-29[arm] Remove redundant inclusion of io.hMichael Brown1-2/+0
The PCI I/O API (supporting accesses to PCI configuration space) is not related to the general I/O API (supporting accesses to memory-mapped I/O peripherals). Remove the spurious inclusion of ipxe/io.h from the PCI I/O header. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-23[efi] Process veto objects in reverse order of enumerationMichael Brown1-7/+11
While not guaranteed by the UEFI specification, the enumeration of handles, protocols, and openers will generally return results in order of creation. Processing these objects in reverse order (as is already done when calling DisconnectController() on the list of all handles) will generally therefore perform the forcible uninstallation operations in reverse order of object creation, which minimises the number of implicit operations performed (e.g. when disconnecting a controller that itself still has existent child controllers). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-23[efi] Check for protocols opened by vetoed driver and image handlesMichael Brown1-1/+4
The UEFI specification states that the AgentHandle may be either the driving binding protocol handle or the image handle. Check for both handles when searching for stale handles to be forcibly closed on behalf of a vetoed driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-23[efi] Unload vetoed drivers by image handle rather than driver handleMichael Brown1-3/+6
In most cases, the driver handle will be the image handle itself. However, this is not required by the UEFI specification, and some images will install multiple driver binding handles. Use the image handle (extracted from the driver binding protocol instance) when attempting to unload the driver's image. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-23[efi] Pass more detailed driver information to veto methodsMichael Brown1-36/+58
Pass the driver binding handle, the driver binding protocol instance, the image handle, and the loaded image protocol instance to all veto methods. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-22[efi] Show manufacturer in veto debug outputMichael Brown1-0/+1
Simplify the process of adding new entries to the veto list by including the manufacturer name within the standard debug output. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-21[efi] Always poll for TX completionsdell3440bMichael Brown1-5/+5
Polling for TX completions is arguably redundant when there are no transmissions currently in progress. Commit c6c7e78 ("[efi] Poll for TX completions only when there is an outstanding TX buffer") switched to setting the PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS flag only when there is an in-progress transmission awaiting completion, in order to reduce reported TX errors and debug message noise from buggy NII implementations that report spurious TX completions whenever the transmit queue is empty. Some other NII implementations (observed with the Realtek driver in a Dell Latitude 3440) seem to have a bug in the transmit datapath handling which results in the transmit ring freezing after sending a few hundred packets under heavy load. The symptoms are that the TPPoll register's NPQ bit remains set and the 256-entry transmit ring contains a large number of uncompleted descriptors (with the OWN bit set), the first two of which have identical data buffer addresses. Though iPXE will submit at most one in-progress transmission via NII, the Dell/Realtek driver seems to make a page-aligned copy of each transmit data buffer and to report TX completions immediately without waiting for the packet to actually be transmitted. These synthetic TX completions continue even after the hardware transmit ring freezes. Setting PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS on every poll reduces the probability of this Dell/Realtek driver bug being triggered by a factor of around 500, which brings the failure rate down to the point that it can sensibly be managed by external logic such as the "--timeout" option for image downloads. Closing and reopening the interface (via "ifclose"/"ifopen") will clear the error condition and allow transmissions to resume. Revert to setting PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS on every poll, and silently ignore situations in which the hardware reports a completion when no transmission is in progress. This approximately matches the behaviour of the SnpDxe driver, which will also generally set PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS on every poll. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-09[efi] Provide read-only access to EFI variables via settings mechanismMichael Brown5-0/+244
EFI variables do not map neatly to the iPXE settings mechanism, since the EFI variable identifier includes a namespace GUID that cannot cleanly be supplied as part of a setting name. Creating a new EFI variable requires the variable's attributes to be specified, which does not fit within iPXE's settings concept. However, EFI variable names are generally unique even without the namespace GUID, and EFI does provide a mechanism to iterate over all existent variables. We can therefore provide read-only access to EFI variables by comparing only the names and ignoring the namespace GUIDs. Provide an "efi" settings block that implements this mechanism using a syntax such as: echo Platform language is ${efi/PlatformLang:string} show efi/SecureBoot:int8 Settings are returned as raw binary values by default since an EFI variable may contain boolean flags, integer values, ASCII strings, UCS-2 strings, EFI device paths, X.509 certificates, or any other arbitrary blob of data. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-08[efi] Veto the VMware UefiPxeBcDxe driverMichael Brown1-0/+35
The EDK2 UefiPxeBcDxe driver includes some remarkably convoluted and unsafe logic in its driver binding protocol Start() and Stop() methods in order to support a pair of nominally independent driver binding protocols (one for IPv4, one for IPv6) sharing a single dynamically allocated data structure. This PXEBC_PRIVATE_DATA structure is installed as a dummy protocol on the NIC handle in order to allow both IPv4 and IPv6 driver binding protocols to locate it as needed. The error handling code path in the UefiPxeBcDxe driver's Start() method may attempt to uninstall the dummy protocol but fail to do so. This failure is ignored and the containing memory is subsequently freed anyway. On the next invocation of the driver binding protocol, it will find and use this already freed block of memory. At some point another memory allocation will occur, the PXEBC_PRIVATE_DATA structure will be corrupted, and some undefined behaviour will occur. The UEFI firmware used in VMware ESX 8 includes some proprietary changes which attempt to install copies of the EFI_LOAD_FILE_PROTOCOL and EFI_PXE_BASE_CODE_PROTOCOL instances from the IPv4 child handle onto the NIC handle (along with a VMware-specific protocol with GUID 5190120d-453b-4d48-958d-f0bab3bc2161 and a NULL instance pointer). This will inevitably fail with iPXE, since the NIC handle already includes an EFI_LOAD_FILE_PROTOCOL instance. These VMware proprietary changes end up triggering the unsafe error handling code path described above. The typical symptom is that an attempt to exit from iPXE back to the UEFI firmware will crash the VM with a General Protection fault from within the UefiPxeBcDxe driver: this happens when the UefiPxeBcDxe driver's Stop() method attempts to call through a function pointer in the (freed) PXEBC_PRIVATE_DATA structure, but the function pointer has by then been overwritten by UCS-2 character data from an unrelated memory allocation. Work around this failure by adding the VMware UefiPxeBcDxe driver to the driver veto list. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-08[efi] Include protocol interface address in debug outputMichael Brown2-5/+42
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Add UefiPxeBcDxe module GUIDMichael Brown1-0/+8
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Add HttpBootDxe module GUIDMichael Brown1-0/+8
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Add new IScsiDxe module GUIDMichael Brown1-1/+9
The old IPv4-only IScsiDxe driver in MdeModulePkg/Universal/Network was replaced by a dual-stack IScsiDxe driver in NetworkPkg. Add the module GUID for this driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Add HTTP header and GUID definitionsMichael Brown4-0/+531
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Add DNS headers and GUID definitionsMichael Brown5-0/+1103
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Add Ip4Config2 header and GUID definitionMichael Brown4-0/+326
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Add IPv6 versions of existing IPv4 headers and GUID definitionsMichael Brown9-0/+4436
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Update to current EDK2 headersMichael Brown8-40/+266
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-07[efi] Disable static assertions in EFI headers on non-EFI platformsMichael Brown1-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>
2023-06-02[crypto] Add support for PKCS#8 private key formatpkcs8Michael Brown4-2/+105
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-05-24[efi] Implement "shim" as a dummy command on non-EFI platformsMichael Brown3-2/+15
The "shim" command will skip downloading the shim binary (and is therefore a conditional no-op) if there is already a selected EFI image that can be executed directly via LoadImage()/StartImage(). This allows the same iPXE script to be used with Secure Boot either enabled or disabled. Generalise this further to provide a dummy "shim" command that is an unconditional no-op on non-EFI platforms. This then allows the same iPXE script to be used for BIOS, EFI with Secure Boot disabled, or EFI with Secure Boot enabled. The same effect could be achieved by using "iseq ${platform} efi" within the script, but this would complicate end-user documentation. To minimise the code size impact, the dummy "shim" command is a pure no-op that does not call parse_options() and so will ignore even standardised arguments such as "--help". Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-05-23[efi] Support versions of shim that perform SBAT verificationMichael Brown5-6/+160
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>
2023-05-23[efi] Separate GetMemoryMap() wrapper from shim unlockerMichael Brown1-27/+34
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-05-22[efi] Add "shim" commandMichael Brown4-0/+117
Allow a shim to be used to facilitate booting a kernel using a script such as: kernel /images/vmlinuz console=ttyS0,115200n8 initrd /images/initrd.img shim /images/shimx64.efi boot Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-05-22[efi] Add support for executing images via a shimMichael Brown8-3/+413
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>
2023-05-22[efi] Add definitions for the UEFI shim lock protocolMichael Brown4-0/+39
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>
generated by cgit v1.1 at 2024-07-10 08:19:00 +0000