aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-11-23[efi] Treat writable sections as data sectionsMichael Brown1-11/+11
Hybrid bzImage and UEFI binaries (such as wimboot) may include 16-bit executable code that is opaque data from the perspective of a UEFI PE binary, as described in wimboot commit fe456ca ("[efi] Use separate .text and .data PE sections"). The ELF section will be marked as containing both executable code and writable data. Choose to treat such a section as a data section rather than a code section, since that matches the expected semantics for ELF files that we expect to process. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-22[efi] Update to current EDK2 headersMichael Brown6-26/+65
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-07[cloud] Add utility script to read iPXE output from INT13CON partitionMichael Brown1-0/+68
Some AWS instance types still do not support serial console output or screenshots. For these instance types, the only viable way to extract debugging information is to use the INT13 console (which is already enabled via CONFIG=cloud for all AWS images). Obtaining the INT13 console output can be very cumbersome, since there is no direct way to read from an AWS volume. The simplest current approach is to stop the instance under test, detach its root volume, and reattach the volume to a Linux instance in the same region. Add a utility script aws-int13con to retrieve the INT13 console output by creating a temporary snapshot, reading the first block from the snapshot, and extracting the INT13 console partition content. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-07[cloud] Add ability to overwrite existing AMI imagesMichael Brown1-2/+13
AMI names must be unique within a region. Add a --overwrite option that allows an existing AMI of the same name to be deregistered (and its underlying snapshot deleted). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-07[eapol] Limit number of EAPoL-Start packets transmitted per attemptMichael Brown2-0/+13
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-07[eapol] Delay EAPoL-Start while waiting for EAP to completeMichael Brown3-44/+84
EAP exchanges may take a long time to reach a final status, especially when relying upon MAC Authentication Bypass (MAB). Our current behaviour of sending EAPoL-Start every few seconds until a final status is obtained can prevent these exchanges from ever completing. Fix by redefining the EAP supplicant state to allow EAPoL-Start to be suppressed: either temporarily (while waiting for a full EAP exchange to complete, in which case we need to eventually resend EAPoL-Start if the final Success or Failure packet is lost), or permanently (while waiting for the potentially very long MAC Authentication Bypass timeout period). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-02[pci] Require discovery of a PCI device when determining usable PCI APIsMichael Brown1-11/+14
The PCI cloud API (PCIAPI_CLOUD) currently selects the first PCI API that successfully discovers a PCI device address range. The ECAM API may discover an address range but subsequently be unable to map the configuration space region, which would result in the selected PCI API being unusable. Fix by instead selecting the first PCI API that can be successfully used to discover a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-02[pci] Check that ECAM configuration space is within reachable memoryMichael Brown1-0/+9
Some machines (observed with an AWS EC2 m7a.large instance) will place the ECAM configuration space window above 4GB, thereby making it unreachable from non-paged 32-bit code. This problem is currently ignored by iPXE, since the address is silently truncated in the call to ioremap(). (Note that other uses of ioremap() are not affected since the PCI core will already have checked for unreachable 64-bit BARs when retrieving the physical address to be mapped.) Fix by adding an explicit check that the region to be mapped starts within the reachable memory address space. (Assume that no machines will be sufficiently peverse to provide a region that straddles the 4GB boundary.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-02[pci] Cache ECAM mapping errorsMichael Brown2-2/+6
When an error occurs during ECAM configuration space mapping, preserve the error within the existing cached mapping (instead of invalidating the cached mapping) in order to avoid flooding the debug log with repeated identical mapping errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-02[pci] Handle non-zero starting bus in ECAM allocationsMichael Brown1-0/+1
The base address provided in the PCI ECAM allocation within the ACPI MCFG table is the base address for the segment as a whole, not for the starting bus within that allocation. On machines that provide ECAM allocations with a non-zero starting bus number (observed with an AWS EC2 m7a.large instance), this will result in iPXE accessing the wrong memory addresses within the ECAM region. Fix by adding the appropriate starting bus offset to the base address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-11-01[pci] Force completion of ECAM configuration space writesMichael Brown1-1/+10
The PCIe specification requires that "processor and host bridge implementations must ensure that a method exists for the software to determine when the write using the ECAM is completed by the completer" but does not specify any particular method to be used. Some platforms might treat writes to the ECAM region as non-posted, others might require reading back from a dedicated (and implementation-specific) completion register to determine when the configuration space write has completed. Since PCI configuration space writes will never be used for any performance-critical datapath operations (on any sane hardware), a simple and platform-independent solution is to always read back from the written register in order to guarantee that the write must have completed. This is safe to do, since the PCIe specification defines a limited set of configuration register types, none of which have read side effects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-10-24[iphone] Add missing va_start()/va_end() around reused argument listMichael Brown1-0/+2
The ipair_tx() function uses a va_list twice (first to calculate the formatted string length before allocation, then to construct the string in the allocated buffer) but is missing the va_start() and va_end() around the second usage. This is undefined behaviour that happens to work on some build platforms. Fix by adding the missing va_start() and va_end() around the second usage of the variadic argument list. Reported-by: Andreas Hammarskjöld <andreas@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-10-06[libc] Use wall clock time as seed for the (non-cryptographic) RNGsrandtimeMichael Brown1-3/+5
We currently use the number of timer ticks since power-on as a seed for the non-cryptographic RNG implemented by random(). Since iPXE is often executed directly after power-on, and since the timer tick resolution is generally low, this can often result in identical seed values being used on each cold boot attempt. As of commit 41f786c ("[settings] Add "unixtime" builtin setting to expose the current time"), the current wall-clock time is always available within the default build of iPXE. Use this time instead, to introduce variability between cold boot attempts on the same host. (Note that variability between different hosts is obtained by using the MAC address as an additional seed value.) This has no effect on the separate DRBG used by cryptographic code. Suggested-by: Heiko <heik0@xs4all.nl> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-19[eapol] Send EAPoL-Start packets to trigger EAP authenticationMichael Brown2-0/+81
We have no way to force a link-layer restart in iPXE, and therefore no way to explicitly trigger a restart of EAP authentication. If an iPXE script has performed some action that requires such a restart (e.g. registering a device such that the port VLAN assignment will be changed), then the only means currently available to effect the restart is to reboot the whole system. If iPXE is taking over a physical link already used by a preceding bootloader, then even a reboot may not work. In the EAP model, the supplicant is a pure responder and never initiates transmissions. EAPoL extends this to include an EAPoL-Start packet type that may be sent by the supplicant to (re)trigger EAP. Add support for sending EAPoL-Start packets at two-second intervals on links that are open and have reached physical link-up, but for which EAP has not yet completed. This allows "ifclose ; ifopen" to be used to restart the EAP process. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-18[eap] Define a supplicant model for EAP and EAPoLMichael Brown5-27/+184
Extend the EAP model to include a record of whether or not EAP authentication has completed (successfully or otherwise), and to provide a method for transmitting EAP responses. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-14[fcoe] Use driver-private data to hold FCoE port structureMichael Brown1-64/+21
Simplify the FCoE code by using driver-private data to hold the FCoE port for each network device, instead of using a separate allocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-14[vmware] Use driver-private data to hold GuestInfo settings blockMichael Brown1-41/+7
Simplify the per-netdevice GuestInfo settings code by using driver-private data to hold the settings block, instead of using a separate allocation. The settings block (if existent) will be automatically unregistered when the parent network device settings block is unregistered, and no longer needs to be separately freed. The guestinfo_net_remove() function may therefore be omitted completely. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-13[ipv6] Use driver-private data to hold link-local IPv6 settings blockMichael Brown1-29/+10
Simplify the IPv6 link-local settings code by using driver-private data to hold the settings block, instead of using a separate allocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-13[lldp] Use driver-private data to hold LLDP settings blockMichael Brown1-63/+31
Simplify the LLDP code by using driver-private data to hold the LLDP settings block, instead of using a separate allocation. This avoids the need to maintain a list of LLDP settings blocks (since the LLDP settings block pointer can always be obtained using netdev_priv()) and obviates several failure paths. Any recorded LLDP data is now freed when the network device is unregistered, since there is no longer a dedicated reference counter for the LLDP settings block. To minimise surprise, we also now explicitly unregister the settings block. This is not strictly necessary (since the block will be automatically unregistered when the parent network device settings block is unregistered), but it maintains symmetry between lldp_probe() and lldp_remove(). The overall reduction in the size of the LLDP code is around 15%. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-09-13[netdevice] Allocate private data for each network upper-layer driverMichael Brown13-34/+110
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>
generated by cgit v1.1 at 2024-08-15 21:02:28 +0000