aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [lldp] Add support for the Link Layer Discovery ProtocollldpMichael Brown2023-02-056-0/+443
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for recording LLDP packets and exposing TLV values via the settings mechanism. LLDP settings are encoded as ${netX.lldp/<prefix>.<type>.<index>.<offset>.<length>} where <type> is the TLV type <offset> is the starting offset within the TLV value <length> is the length (or zero to read the from <offset> to the end) <prefix>, if it has a non-zero value, is the subtype byte string of length <offset> to match at the start of the TLV value, up to a maximum matched length of 4 bytes <index> is the index of the entry matching <type> and <prefix> to be accessed, with zero indicating the first matching entry The <prefix> is designed to accommodate both matching of the OUI within an organization-specific TLV (e.g. 0x0080c2 for IEEE 802.1 TLVs) and of a subtype byte as found within many TLVs. This encoding allows most LLDP values to be extracted easily. For example System name: ${netX.lldp/5.0.0.0:string} System description: ${netX.lldp/6.0.0.0:string} Port description: ${netX.lldp/4.0.0.0:string} Port interface name: ${netX.lldp/5.2.0.1.0:string} Chassis MAC address: ${netX.lldp/4.1.0.1.0:hex} Management IPv4 address: ${netX.lldp/5.1.8.0.2.4:ipv4} Port VLAN ID: ${netX.lldp/0x0080c2.1.127.0.4.2:int16} Port VLAN name: ${netX.lldp/0x0080c2.3.127.0.7.0:string} Maximum frame size: ${netX.lldp/0x00120f.4.127.0.4.2:uint16} Originally-implemented-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ci] Update to ubuntu-22.04 GitHub actions runnerMichael Brown2023-02-032-4/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Ignore DHCPNAK unless originating from the selected DHCP serverMichael Brown2023-02-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | RFC 2131 leaves undefined the behaviour of the client in response to a DHCPNAK that comes from a server other than the selected DHCP server. A substantial amount of online documentation suggests using multiple independent DHCP servers with non-overlapping ranges in the same subnet in order to provide some minimal redundancy. Experimentation shows that in this setup, at least ISC dhcpd will send a DHCPNAK in response to the client's DHCPREQUEST for an address that is not within the range defined on that server. (Since the requested address does lie within the subnet defined on that server, this will happen regardless of the "authoritative" parameter.) The client will therefore receive a DHCPACK from the selected DHCP server along with one or more DHCPNAKs from each of the non-selected DHCP servers. Filter out responses from non-selected DHCP servers before checking for a DHCPNAK, so that these arguably spurious DHCPNAKs will not cause iPXE to return to the discovery state. Continue to check for DHCPNAK before filtering out responses for non-selected lease addresses, since experimentation shows that the DHCPNAK will usually have an empty yiaddr field. Reported-by: Anders Blomdell <anders.blomdell@control.lth.se> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not attempt to drive PCI bridge devicesefibridgeMichael Brown2023-02-033-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* [util] Add support for LoongArch64 binariesloongarch64Xiaotian Wu2023-02-033-0/+38
| | | | | | Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ci] Update to actions/checkout@v3 to silence GitHub warningsMichael Brown2023-02-032-4/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Update to current Xen headersxenMichael Brown2023-02-0219-874/+2901
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow autoexec script to be located alongside iPXE binaryMichael Brown2023-02-013-22/+75
| | | | | | | | | 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>
* [realtek] Explicitly disable VLAN offloadMichael Brown2023-02-012-2/+7
| | | | | | | | | | | | Some cards seem to have the receive VLAN tag stripping feature enabled by default, which causes received VLAN packets to be misinterpreted as being received by the trunk device. Fix by disabling VLAN tag stripping in the C+ Command Register. Debugged-by: Xinming Lai <yiyihu@gmail.com> Tested-by: Xinming Lai <yiyihu@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-02-012-12/+12
| | | | | | | Update to pick up the upstream commit bda715b ("MdePkg: Fix UINT64 and INT64 word length for LoongArch64"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tests] Verify ability to sleep the CPUnaptestMichael Brown2023-01-312-0/+54
| | | | | | | | | | | | | The self-test suite does not currently ever attempt to sleep the CPU. This is an operation that may fail (e.g. by attempting to execute a privileged instruction while running as a Linux userspace binary, or by halting the CPU with all interrupts disabled). Add a trivial self-test to exercise the ability to sleep the CPU without crashing or halting forever. Inspired-by: Xiaotian Wu <wuxiaotian@loongson.cn> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Add IANA-defined values for all current EFI client architecturesMichael Brown2023-01-311-2/+21
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Accept a command line passed to an iPXE image via LoadOptionsMichael Brown2023-01-294-0/+175
| | | | | | | | | Treat a command line passed to iPXE via UEFI LoadOptions as an image to be registered at startup, as is already done for the .lkrn, .pxe, and .exe BIOS images. Originally-implemented-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [la64] Import LoongArch64 ProcessorBind.h from EDK2 headersMichael Brown2023-01-283-2/+128
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-01-2895-15321/+14255
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark ConsoleControl.h as a non-imported headerMichael Brown2023-01-281-0/+5
| | | | | | | | | | | The obsolete ConsoleControl.h header is no longer present in the current EDK2 codebase, but is still required for interoperability with old iMacs. Add an iPXE include guard to this file so that the EDK2 header import script will no longer attempt to import it from the EDK2 tree. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove deleted directories from EDK2 header import scriptMichael Brown2023-01-281-2/+1
| | | | | | | | The IntelFrameworkPkg and EdkCompatibilityPkg directories have been removed from the EDK2 codebase. Remove these directories from the EDK2 header import script. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for whitespace before #include in imported EDK2 header filesMichael Brown2023-01-281-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Detect SPDX licence identifiers in imported EDK2 headersMichael Brown2023-01-281-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Add missing FILE_LICENCE declaration to efi_path.cMichael Brown2023-01-281-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Add support for the BSD-2-Clause-Patent licenceMichael Brown2023-01-282-0/+61
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Build util/efirom as a host-only binaryMichael Brown2023-01-282-0/+5
| | | | | | | | | As with util/elf2efi32 and util/elf2efi64 in commit a99e435 ("[efi] Do not rely on ProcessorBind.h when building host binaries"), build util/efirom without using any architecture-specific EDK2 headers since the build host's CPU architecture may not be supported by EDK2. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tcp] Update maximum window size to 2MBMichael Brown2023-01-251-6/+12
| | | | | | | | | | | The current maximum window size of 256kB was calculated based on rough link bandwidth and RTT measurements taken in 2012, and is too small to avoid filling the TCP window on some modern links. Update the list of typical link bandwidth and RTT figures to reflect the modern world, and increase the maximum window size accordingly. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Discard queued PXE UDP packets when under memory pressureMichael Brown2023-01-251-0/+26
| | | | | | | | | | | The PXE UDP receive queue may grow without limit if the PXE NBP does not call PXENV_UDP_READ sufficiently frequently. Fix by implementing a cache discarder for received PXE UDP packets (similar to the TCP cache discarder). Reported-by: Tal Shorer <shorer@amazon.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [golan] Add new PCI ID for NVIDIA BlueField-3 network deviceMohammed Taha2023-01-231-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Avoid drawing menu items on bottom row of screenpxemenuscrollMichael Brown2023-01-231-1/+1
| | | | | | | | | | | | | | | Many consoles will scroll immediately upon drawing a character in the rightmost column of the bottom row of the display, in order to be able to advance the cursor to the next character (even if the cursor is disabled). This causes PXE menus to display incorrectly. Specifically, pressing the down arrow key while already on the last menu item may cause the whole screen to scroll and the line to be duplicated. Fix by moving the PXE menu one row up from the bottom of the screen. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Bind to only the topmost instance of the SNP or NII protocolssnploopMichael Brown2023-01-231-30/+36
| | | | | | | | | | | | | | UEFI has the mildly annoying habit of installing copies of the EFI_SIMPLE_NETWORK_PROTOCOL instance on the IPv4 and IPv6 child device handles. This can cause iPXE's SNP driver to attempt to bind to a copy of the EFI_SIMPLE_NETWORK_PROTOCOL that iPXE itself provided on a different handle. Fix by refusing to bind to an SNP (or NII) handle if there exists another instance of the same protocol further up the device path (on the basis that we always want to bind to the highest possible device). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Extend efi_locate_device() to allow searching up the device pathMichael Brown2023-01-234-17/+45
| | | | | | | | 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-232-7/+23
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_terminate() utility functionMichael Brown2023-01-235-33/+24
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Inhibit linker warnings about an implied executable stackMichael Brown2023-01-234-4/+4
| | | | | | | | | | | Some versions of the 32-bit ARM linker seem to treat the absence of a .note.GNU-stack section as implying an executable stack, and will print a warning that this is deprecated behaviour. Silence the warning by adding a .note.GNU-stack section to each assembly file and retaining the sections in the Linux linker script. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use -mfloat-abi=soft only for EFI buildsMichael Brown2023-01-232-1/+5
| | | | | | | | | The EFI ABI requires the use of -mfloat-abi=soft, but other platforms may require -mfloat-abi=hard. Allow for this by using -mfloat-abi=soft only for EFI builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use -fno-short-enums for all 32-bit ARM buildsMichael Brown2023-01-232-4/+5
| | | | | | | | | | | The EFI ABI requires the use of -fno-short-enums, and the EDK2 headers will perform a compile-time check that enums are 32 bits. The EDK2 headers may be included even in builds for non-EFI platforms, and so the -fno-short-enums flag must be used in all 32-bit ARM builds. Fortunately, nothing else currently cares about enum sizes. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Support building as a Linux userspace binary for AArch64Michael Brown2023-01-222-0/+16
| | | | | | | | | | | | | | | | | | | | Add support for building as a Linux userspace binary for AArch64. This allows the self-test suite to be more easily run for the 64-bit ARM code. For example: # On a native AArch64 system: # make bin-arm64-efi/tests.linux && ./bin-arm64-efi/tests.linux # On a non-AArch64 system (e.g. x86_64) via cross-compilation, # assuming that kernel and glibc headers are present within # /usr/aarch64-linux-gnu/sys-root/: # make bin-arm64-linux/tests.linux CROSS=aarch64-linux-gnu- && \ qemu-aarch64 -L /usr/aarch64-linux-gnu/sys-root/ \ ./bin-arm64-linux/tests.linux Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Simplify platform-specific client architecture definitionsMichael Brown2023-01-2218-288/+138
| | | | | | | | | | | | | | | | Move the platform-specific DHCP client architecture definitions to header files of the form <ipxe/$(PLATFORM)/dhcparch.h>. This simplifies the directory structure and allows the otherwise unused arch/$(ARCH)/include/$(PLATFORM) to be removed from the include directory search path, which avoids the confusing situation in which a header file may potentially be accessed through more than one path. For Linux userspace binaries on any architecture, use the EFI values for that architecture by delegating to the EFI header file. This avoids the need to explicitly select values for Linux userspace binaries for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Move -Ulinux to common MakefileMichael Brown2023-01-222-3/+4
| | | | | | | The requirement to undo the implicit "-Dlinux" is not specific to the x86 architecture. Move this out of the x86-specific Makefile. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Centralise the linker script for Linux binariesMichael Brown2023-01-225-116/+9
| | | | | | | Reduce duplication between i386 and x86_64 by providing a single shared linker script that both architectures can include. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not rely on ProcessorBind.h when building host binariesprocessorbindMichael Brown2023-01-202-4/+40
| | | | | | | | | | | | | We cannot rely on the EDK2 ProcessorBind.h headers when compiling a binary for execution on the build host itself (e.g. elf2efi), since the host's CPU architecture may not even be supported by EDK2. Fix by skipping ProcessorBind.h when building a host binary, and defining the bare minimum required to allow other EDK2 headers to compile cleanly. Reported-by: Michal Suchánek <msuchanek@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Allocate an unused Asynchronous Event Notification Queue (AENQ)aenqAlexander Graf2023-01-182-0/+139
| | | | | | | | | | | | | | We currently don't allocate an Asynchronous Event Notification Queue (AENQ) because we don't actually care about any of the events that may come in. The ENA firmware found on Graviton instances requires the AENQ to exist, otherwise all admin queue commands will fail. Fix by allocating an AENQ and disabling all events (so that we do not need to include code to acknowledge any events that may arrive). Signed-off-by: Alexander Graf <graf@amazon.com>
* [netdevice] Ensure consistent interpretation of "netX" device nameMichael Brown2023-01-171-2/+2
| | | | | | | | Ensure that the "${netX/...}" settings mechanism always uses the same interpretation of the network device corresponding to "netX" as any other mechanism that performs a name-based lookup of a network device. 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>
* [vlan] Support automatic VLAN device creationMichael Brown2023-01-152-0/+49
| | | | | | | Add the ability to automatically create a VLAN device for a specified trunk device link-layer address and VLAN tag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [autoboot] Include VLAN tag in filter for identifying autoboot deviceMichael Brown2023-01-155-8/+30
| | | | | | | | | | | | | 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] Allow duplicate MAC addressesMichael Brown2023-01-155-38/+56
| | | | | | | | | | | | | | | | | | | | | | | | Many laptops now include the ability to specify a "system-specific MAC address" (also known as "pass-through MAC"), which is supposed to be used for both the onboard NIC and for any attached docking station or other USB NIC. This is intended to simplify interoperability with software or hardware that relies on a MAC address to recognise an individual machine: for example, a deployment server may associate the MAC address with a particular operating system image to be deployed. This therefore creates legitimate situations in which duplicate MAC addresses may exist within the same system. As described in commit 98d09a1 ("[netdevice] Avoid registering duplicate network devices"), the Xen netfront driver relies on the rejection of duplicate MAC addresses in order to inhibit registration of the emulated PCI devices that a Xen PV-HVM guest will create to shadow each of the paravirtual network devices. Move the code that rejects duplicate MAC addresses from the network device core to the Xen netfront driver, to allow for the existence of duplicate MAC addresses in non-Xen setups. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Separate concept of scope ID from network device name indexMichael Brown2023-01-1410-33/+36
| | | | | | | | | | | | | | | | | | | | | 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>
* [efi] Disable receive filters to work around buggy UNDI driversMichael Brown2023-01-111-10/+47
| | | | | | | | | | | | | Some UNDI drivers (such as the AMI UsbNetworkPkg currently in the process of being upstreamed into EDK2) have a bug that will prevent any packets from being received unless at least one attempt has been made to disable some receive filters. Work around these buggy drivers by attempting to disable receive filters before enabling them. Ignore any errors, since we genuinely do not care whether or not the disabling succeeds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Retain cached DHCPACK after startup if not already consumedefivlanMichael Brown2022-12-221-4/+22
| | | | | | | | | | | | | | We currently free an unclaimed cached DHCPACK immediately after startup, in order to free up memory. This prevents the cached DHCPACK from being applied to a device that is created after startup, such as a VLAN device created via the "vcreate" command. Retain any unclaimed DHCPACK after startup to allow it to be matched against (and applied to) any device that gets created at runtime. Free the DHCPACK during shutdown if it still remains unclaimed, in order to exit with memory cleanly freed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Include VLAN tag in filter for applying cached DHCPACKMichael Brown2022-12-226-15/+41
| | | | | | | | | | | | | | | 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-222-0/+24
| | | | | | | | | | | | | | | | | | 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-223-15/+41
| | | | | | | 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>
generated by cgit (git 2.34.1) at 2025-02-22 22:43:15 +0000