2 days ago[dma] Modify DMA API to simplify calculation of medial addresses coverity_scan master
Michael Brown [Wed, 25 Nov 2020 15:52:00 +0000 (15:52 +0000)] 
[dma] Modify DMA API to simplify calculation of medial addresses

Redefine the value stored within a DMA mapping to be the offset
between physical addresses and DMA addresses within the mapped region.

Provide a dma() wrapper function to calculate the DMA address for any
pointer within a mapped region, thereby simplifying the use cases when
a device needs to be given addresses other than the region start

On a platform using the "flat" DMA implementation the DMA offset for
any mapped region is always zero, with the result that dma_map() can
be optimised away completely and dma() reduces to a straightforward
call to virt_to_phys().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 days ago[intelxl] Configure DMA mask as 64-bit
Michael Brown [Tue, 24 Nov 2020 17:47:42 +0000 (17:47 +0000)] 
[intelxl] Configure DMA mask as 64-bit

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 days ago[intel] Configure DMA mask as 64-bit
Michael Brown [Tue, 24 Nov 2020 17:46:39 +0000 (17:46 +0000)] 
[intel] Configure DMA mask as 64-bit

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 days ago[efi] Report correct error when failing to unload a vetoed driver
Michael Brown [Tue, 24 Nov 2020 15:42:43 +0000 (15:42 +0000)] 
[efi] Report correct error when failing to unload a vetoed driver

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 days ago[efi] Allow initialisation via SNP interface even while claimed
Michael Brown [Mon, 23 Nov 2020 15:34:13 +0000 (15:34 +0000)] 
[efi] Allow initialisation via SNP interface even while claimed

iPXE will currently fail all SNP interface methods with EFI_NOT_READY
while the network devices are claimed for use by iPXE's own network

As of commit c70b3e0 ("[efi] Always enable recursion when calling
ConnectController()"), this exposes latent UEFI firmware bugs on some
systems at the point of calling ExitBootServices().

With recursion enabled, the MnpDxe driver will immediately attempt to
consume the SNP protocol instance provided by iPXE.  Since the network
devices are claimed by iPXE at this point, the calls by MnpDxe to
Start() and Initialize() will both fail with EFI_NOT_READY.

This unfortunately triggers a broken error-handling code path in the
Ip6Dxe driver.  Specifically: Ip6DriverBindingStart() will call
Ip6CreateService(), which will call Ip6ServiceConfigMnp(), which will
return an error.  The subsequent error handling code path in
Ip6CreateService() simply calls Ip6CleanService().  The code in
Ip6CleanService() will attempt to leave the all-nodes multicast group,
which will fail since the group was never joined.  This will result in
Ip6CleanService() returning an error and omitting most of the required
clean-up operations.  In particular, the MNP protocol instance will
remain opened with BY_DRIVER attributes even though the Ip6Dxe driver
start method has failed.

When ExitBootServices() is eventually called, iPXE will attempt to
uninstall the SNP protocol instance.  This results in the UEFI core
calling Ip6DriverBindingStop(), which will fail since there is no
EFI_IP6_SERVICE_BINDING_PROTOCOL instance installed on the handle.

A failure during a call to UninstallMultipleProtocolInterfaces() will
result in the UEFI core attempting to reinstall any successfully
uninstalled protocols.  This is an intrinsically unsafe operation, and
represents a fundamental design flaw in UEFI.  Failure code paths
cannot be required to themselves handle failures, since there is no
well-defined correct outcome of such a situation.

With a current build of OVMF, this results in some unexpected debug
messages occurring at the time that the loaded operating system calls
ExitBootServices().  With the UEFI firmware in Hyper-V, the result is
an immediate reboot.

Work around these UEFI design and implementation flaws by allowing the
calls to our EFI_SIMPLE_NETWORK_PROTOCOL instance's Start() and
Initialize() methods to return success even when the network devices
are claimed for exclusive use by iPXE.  This is sufficient to allow
MnpDxe to believe that it has successfully initialised the device, and
thereby avoids the problematic failure code paths in Ip6Dxe.

Debugged-by: Aaron Heusser <aaron_heusser@hotmail.com>
Debugged-by: Pico Mitchell <pico@randomapplications.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 days ago[intelxl] Update driver to use DMA API
Michael Brown [Tue, 17 Nov 2020 01:26:21 +0000 (01:26 +0000)] 
[intelxl] Update driver to use DMA API

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 days ago[intelxl] Read PCI bus:dev.fn number from PFFUNC_RID register
Michael Brown [Sat, 21 Nov 2020 13:19:27 +0000 (13:19 +0000)] 
[intelxl] Read PCI bus:dev.fn number from PFFUNC_RID register

For the physical function driver, the transmit queue needs to be
configured to be associated with the relevant physical function
number.  This is currently obtained from the bus:dev.fn address of the
underlying PCI device.

In the case of a virtual machine using the physical function via PCI
passthrough, the PCI bus:dev.fn address within the virtual machine is
unrelated to the real physical function number.  Such a function will
typically be presented to the virtual machine as a single-function
device.  The function number extracted from the PCI bus:dev.fn address
will therefore always be zero.

Fix by reading from the Function Requester ID Information Register,
which always returns the real PCI bus:dev.fn address as used by the
physical host.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 days ago[intelxl] Read MAC address from PRTPM_SA[HL] instead of PRTGL_SA[HL]
Michael Brown [Fri, 20 Nov 2020 19:12:24 +0000 (19:12 +0000)] 
[intelxl] Read MAC address from PRTPM_SA[HL] instead of PRTGL_SA[HL]

The datasheet is fairly incomprehensible in terms of identifying the
appropriate MAC address for use by the physical function driver.
Choose to read the MAC address from PRTPM_SAH and PRTPM_SAL, which at
least matches the MAC address as selected by the Linux i40e driver.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 days ago[efi] Avoid dropping below TPL as at entry to iPXE
Michael Brown [Fri, 20 Nov 2020 15:15:15 +0000 (15:15 +0000)] 
[efi] Avoid dropping below TPL as at entry to iPXE

iPXE will currently drop to TPL_APPLICATION whenever the current
system time is obtained via currticks(), since the system time
mechanism relies on a timer that can fire only when the TPL is below

This can cause unexpected behaviour if the system time is obtained in
the middle of an API call into iPXE by external code.  For example,
MnpDxe sets up a 10ms periodic timer running at TPL_CALLBACK to poll
the underling EFI_SIMPLE_NETWORK_PROTOCOL device for received packets.
If the resulting poll within iPXE happens to hit a code path that
requires obtaining the current system time (e.g. due to reception of
an STP packet, which affects iPXE's blocked link timer), then iPXE
will end up temporarily dropping to TPL_APPLICATION.  This can
potentially result in retriggering the MnpDxe periodic timer, causing
code to be unexpectedly re-entered.

Fix by recording the external TPL at any entry point into iPXE and
dropping only as far as this external TPL, rather than dropping
unconditionally to TPL_APPLICATION.

The side effect of this change is that iPXE's view of the current
system time will be frozen for the duration of any API calls made into
iPXE by external code at TPL_CALLBACK or above.  Since any such
external code is already responsible for allowing execution at
TPL_APPLICATION to occur, then this should not cause a problem in

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 days ago[intel] Use physical addresses in debug messages
Michael Brown [Mon, 16 Nov 2020 15:00:05 +0000 (15:00 +0000)] 
[intel] Use physical addresses in debug messages

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 days ago[realtek] Use physical addresses in debug messages
Michael Brown [Mon, 16 Nov 2020 13:07:31 +0000 (13:07 +0000)] 
[realtek] Use physical addresses in debug messages

Physical addresses in debug messages are more meaningful from an
end-user perspective than potentially IOMMU-mapped I/O virtual
addresses, and have the advantage of being calculable without access
to the original DMA mapping entry (e.g. when displaying an address for
a single failed completion within a descriptor ring).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
12 days ago[efi] Use casts rather than virt_to_bus() for UNDI buffer addresses
Michael Brown [Sun, 15 Nov 2020 23:33:52 +0000 (23:33 +0000)] 
[efi] Use casts rather than virt_to_bus() for UNDI buffer addresses

For a software UNDI, the addresses in PXE_CPB_TRANSMIT.FrameAddr and
PXE_CPB_RECEIVE.BufferAddr are host addresses, not bus addresses.

Remove the spurious (and no-op) use of virt_to_bus() and replace with
a cast via intptr_t.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
12 days ago[efi] Do not populate media header length in PXE transmit CPB
Michael Brown [Sun, 15 Nov 2020 23:17:17 +0000 (23:17 +0000)] 
[efi] Do not populate media header length in PXE transmit CPB

The UEFI specification defines PXE_CPB_TRANSMIT.DataLen as excluding
the length of the media header.  iPXE currently fills in DataLen as
the whole frame length (including the media header), along with
placing the media header length separately in MediaheaderLen.  On some
UNDI implementations (observed using a VMware ESXi 7.0b virtual
machine), this causes transmitted packets to include 14 bytes of
trailing garbage.

Match the behaviour of the EDK2 SnpDxe driver, which fills in DataLen
as the whole frame length (including the media header) and leaves
MediaheaderLen as zero.  This behaviour also violates the UEFI
specification, but is likely to work in practice since EDK2 is the
reference implementation.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 weeks ago[intel] Update driver to use DMA API
Michael Brown [Fri, 13 Nov 2020 19:55:22 +0000 (19:55 +0000)] 
[intel] Update driver to use DMA API

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 weeks ago[efi] Rename efi_blacklist to efi_veto
Michael Brown [Sat, 7 Nov 2020 16:25:00 +0000 (11:25 -0500)] 
[efi] Rename efi_blacklist to efi_veto

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[realtek] Update driver to use DMA API
Michael Brown [Wed, 4 Nov 2020 15:25:30 +0000 (15:25 +0000)] 
[realtek] Update driver to use DMA API

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[efi] Provide DMA operations for EFI PCI devices
Michael Brown [Wed, 4 Nov 2020 15:23:14 +0000 (15:23 +0000)] 
[efi] Provide DMA operations for EFI PCI devices

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[dma] Define a DMA API to allow for non-flat device address spaces
Michael Brown [Wed, 4 Nov 2020 15:18:49 +0000 (15:18 +0000)] 
[dma] Define a DMA API to allow for non-flat device address spaces

iPXE currently assumes that DMA-capable devices can directly address
physical memory using host addresses.  This assumption fails when
using an IOMMU.

Define an internal DMA API with two implementations: a "flat"
implementation for use in legacy BIOS or other environments in which
flat physical addressing is guaranteed to be used and all allocated
physical addresses are guaranteed to be within a 32-bit address space,
and an "operations-based" implementation for use in UEFI or other
environments in which DMA mapping may require bus-specific handling.

The purpose of the fully inlined "flat" implementation is to allow the
trivial identity DMA mappings to be optimised out at build time,
thereby avoiding an increase in code size for legacy BIOS builds.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[malloc] Rename malloc_dma() to malloc_phys()
Michael Brown [Thu, 5 Nov 2020 19:08:48 +0000 (19:08 +0000)] 
[malloc] Rename malloc_dma() to malloc_phys()

The malloc_dma() function allocates memory with specified physical
alignment, and is typically (though not exclusively) used to allocate
memory for DMA.

Rename to malloc_phys() to more closely match the functionality, and
to create name space for functions that specifically allocate and map
DMA-capable buffers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[efi] Retain a long-lived reference to the EFI_PCI_IO_PROTOCOL instance
Michael Brown [Wed, 4 Nov 2020 15:08:48 +0000 (15:08 +0000)] 
[efi] Retain a long-lived reference to the EFI_PCI_IO_PROTOCOL instance

Provide opened EFI PCI devices with access to the underlying
EFI_PCI_IO_PROTOCOL instance, in order to facilitate the future use of
the DMA mapping methods within the fast data path.

Do not require the use of this stored EFI_PCI_IO_PROTOCOL instance for
memory-mapped I/O (since the entire point of memory-mapped I/O as a
concept is to avoid this kind of unnecessary complexity) or for
slow-path PCI configuration space accesses (since these may be
required for access to PCI bus:dev.fn addresses that do not correspond
to a device bound via our driver binding protocol instance).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[realtek] Reset NIC when closing interface if using legacy mode
Michael Brown [Wed, 4 Nov 2020 14:24:52 +0000 (14:24 +0000)] 
[realtek] Reset NIC when closing interface if using legacy mode

The legacy transmit descriptor index is not reset by anything short of
a full device reset.  This can cause the legacy transmit ring to stall
after closing and reopening the device, since the hardware and
software indices will be out of sync.

Fix by performing a reset after closing the interface.  Do this only
if operating in legacy mode, since in C+ mode the reset is not
required and would undesirably clear additional state (such as the C+
command register itself).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 weeks ago[efi] Fall back to assuming identity mapping of MMIO address space
Michael Brown [Fri, 30 Oct 2020 14:22:55 +0000 (14:22 +0000)] 
[efi] Fall back to assuming identity mapping of MMIO address space

Some UEFI systems (observed with a Supermicro X11SPG-TF motherboard)
seem to fail to provide a valid ACPI address space descriptor for the
MMIO address space associated with a PCI root bridge.

If no valid descriptor can be found, fall back to assuming that the
MMIO address space is identity mapped, thereby matching the behaviour
prior to commit 27e886c ("[efi] Use address offset as reported by

Debugged-by: Tore Anderson <tore@fud.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 weeks ago[efi] Avoid dragging in USB subsystem via efi_usb_path()
Michael Brown [Fri, 30 Oct 2020 13:51:30 +0000 (13:51 +0000)] 
[efi] Avoid dragging in USB subsystem via efi_usb_path()

Commit 87e39a9c9 ("[efi] Split efi_usb_path() out to a separate
function") unintentionally introduced an undefined symbol reference
from efi_path.o to usb_depth(), causing the USB subsystem to become a
dependency of all EFI builds.

Fix by converting usb_depth() to a static inline function.

Reported-by: Pico Mitchell <pico@randomapplications.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 weeks ago[efi] Fix memory copy length used in efi_nullify_name2()
Michael Brown [Tue, 27 Oct 2020 11:43:08 +0000 (11:43 +0000)] 
[efi] Fix memory copy length used in efi_nullify_name2()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 weeks ago[efi] Nullify interfaces and leak memory on uninstallation failure
Michael Brown [Mon, 26 Oct 2020 15:10:18 +0000 (15:10 +0000)] 
[efi] Nullify interfaces and leak memory on uninstallation failure

The UEFI specification allows uninstallation of a protocol interface
to fail.  There is no sensible way for code to react to this, since
uninstallation is likely to be taking place on a code path that cannot
itself fail (e.g. a code path that is itself a failure path).

Where the protocol structure exists within a dynamically allocated
block of memory, this leads to possible use-after-free bugs.  Work
around this unfortunate design choice by nullifying the protocol
(i.e. overwriting the method pointers with no-ops) and leaking the
memory containing the protocol structure.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[efi] Allow block devices to provide their own EFI device paths
Michael Brown [Fri, 16 Oct 2020 14:11:49 +0000 (15:11 +0100)] 
[efi] Allow block devices to provide their own EFI device paths

Use the device path constructed via efi_describe() for the installed
EFI_BLOCK_IO_PROTOCOL device handle.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[infiniband] Allow SRP device to be described using an EFI device path
Michael Brown [Fri, 23 Oct 2020 14:26:30 +0000 (15:26 +0100)] 
[infiniband] Allow SRP device to be described using an EFI device path

The UEFI specification provides a partial definition of an Infiniband
device path structure.  Use this structure to construct what may be a
plausible path containing at least some of the information required to
identify an SRP target device.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[fcp] Allow Fibre Channel device to be described using an EFI device path
Michael Brown [Thu, 22 Oct 2020 13:01:27 +0000 (14:01 +0100)] 
[fcp] Allow Fibre Channel device to be described using an EFI device path

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[iscsi] Allow iSCSI device to be described using an EFI device path github/coverity_scan github/master
Michael Brown [Tue, 20 Oct 2020 13:48:29 +0000 (14:48 +0100)] 
[iscsi] Allow iSCSI device to be described using an EFI device path

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[efi] Show block device ACPI table contents only at DBGLVL_EXTRA
Michael Brown [Tue, 20 Oct 2020 14:03:37 +0000 (15:03 +0100)] 
[efi] Show block device ACPI table contents only at DBGLVL_EXTRA

The ACPI table contents are typically large and are likely to cause
any preceding error messages to scroll off-screen.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[aoe] Allow AoE device to be described using an EFI device path
Michael Brown [Mon, 19 Oct 2020 13:42:11 +0000 (14:42 +0100)] 
[aoe] Allow AoE device to be described using an EFI device path

There is no standard defined for AoE device paths in the UEFI
specification, and it seems unlikely that any standard will be adopted
in future.

Choose to construct an AoE device path using a concatenation of the
network device path and a SATA device path, treating the AoE major and
minor numbers as the HBA port number and port multiplier port number

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[efi] Provide utility function to concatenate device paths
Michael Brown [Mon, 19 Oct 2020 13:12:48 +0000 (14:12 +0100)] 
[efi] Provide utility function to concatenate device paths

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[efi] Split efi_netdev_path() out to a separate function
Michael Brown [Mon, 19 Oct 2020 12:44:43 +0000 (13:44 +0100)] 
[efi] Split efi_netdev_path() out to a separate function

Provide efi_netdev_path() as a standalone function, to allow for reuse
when constructing child device paths.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[http] Allow HTTP connection to be described using an EFI device path
Michael Brown [Fri, 16 Oct 2020 14:08:19 +0000 (15:08 +0100)] 
[http] Allow HTTP connection to be described using an EFI device path

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[efi] Provide efi_uri_path() to construct a URI device path
Michael Brown [Fri, 16 Oct 2020 14:09:15 +0000 (15:09 +0100)] 
[efi] Provide efi_uri_path() to construct a URI device path

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[usbblk] Allow USB block device to be described using an EFI device path
Michael Brown [Fri, 16 Oct 2020 14:11:16 +0000 (15:11 +0100)] 
[usbblk] Allow USB block device to be described using an EFI device path

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[efi] Split efi_usb_path() out to a separate function
Michael Brown [Fri, 16 Oct 2020 14:07:14 +0000 (15:07 +0100)] 
[efi] Split efi_usb_path() out to a separate function

Provide efi_usb_path() as a standalone function, to allow for reuse by
the USB mass storage driver.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[efi] Define an interface operation to describe using an EFI device path
Michael Brown [Fri, 16 Oct 2020 14:09:52 +0000 (15:09 +0100)] 
[efi] Define an interface operation to describe using an EFI device path

Allow arbitrary objects to support describing themselves using an EFI
device path.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[efi] Split device path functions out to efi_path.c
Michael Brown [Fri, 16 Oct 2020 13:12:56 +0000 (14:12 +0100)] 
[efi] Split device path functions out to efi_path.c

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[efi] Provide EFI_INTF_OP for EFI-only interface operations
Michael Brown [Fri, 16 Oct 2020 14:02:46 +0000 (15:02 +0100)] 
[efi] Provide EFI_INTF_OP for EFI-only interface operations

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[interface] Allow for the definition of an unused interface operation
Michael Brown [Fri, 16 Oct 2020 13:59:36 +0000 (14:59 +0100)] 
[interface] Allow for the definition of an unused interface operation

Allow an interface operation to be declared as unused.  This will
perform full type-checking and compilation of the implementing method,
without including any code in the resulting object (other than a NULL
entry in the interface operations table).

The intention is to provide a relatively clean way for interface
operation methods to be omitted in builds for which the operation is
not required (such as an operation to describe an object using an EFI
device path, which would not be required in a non-EFI build).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[build] Provide a testable platform macro alongside -DPLATFORM
Michael Brown [Fri, 16 Oct 2020 13:34:14 +0000 (14:34 +0100)] 
[build] Provide a testable platform macro alongside -DPLATFORM

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[ipv6] Reduce time spent waiting for router discovery
Michael Brown [Wed, 14 Oct 2020 13:52:13 +0000 (14:52 +0100)] 
[ipv6] Reduce time spent waiting for router discovery

Now that IPv6 is enabled by default for UEFI builds, it is important
that iPXE does not delay unnecessarily in the (still relatively
common) case of a network that lacks IPv6 routers.

Apply the timeout values used for neighbour discovery to the router
discovery process.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[efi] Enable NET_PROTO_IPV6 by default
Tore Anderson [Sun, 18 Nov 2018 19:13:46 +0000 (20:13 +0100)] 
[efi] Enable NET_PROTO_IPV6 by default

IPv6 PXE was included in the UEFI specification over eight years ago,
specifically in version 2.3 (Errata D).


When iPXE is being chainloaded from a UEFI firmware performing a PXE
boot in an IPv6 network, it is essential that iPXE supports IPv6 as

I understand that the reason for NET_PROTO_IPV6 being disabled by
default (in src/config/general.h) is that it would cause certain
space-constrained build targets to become too large.  However, this
should not be an issue for EFI builds.

It is also worth noting that RFC 6540 makes a clear recommendation
that IPv6 support should not be considered optional.


Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Tore Anderson <tore@fud.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[lacp] Ignore (and do not echo) trailing padding on received packets
Michael Brown [Wed, 14 Oct 2020 13:05:03 +0000 (14:05 +0100)] 
[lacp] Ignore (and do not echo) trailing padding on received packets

The LACP responder reuses the received I/O buffer to construct the
response LACP (or marker) packet.  Any received padding will therefore
be unintentionally included within the response.

Truncate the received I/O buffer to the expected length (which is
already defined in a way to allow for future protocol expansion)
before reusing it to construct the response.

Reported-by: Tore Anderson <tore@fud.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[lacp] Detect and ignore erroneously looped back LACP packets
Michael Brown [Tue, 13 Oct 2020 12:35:39 +0000 (13:35 +0100)] 
[lacp] Detect and ignore erroneously looped back LACP packets

Some external drivers (observed with the UEFI NII driver provided by
an HPE-branded Mellanox ConnectX-3 Pro) seem to cause LACP packets
transmitted by iPXE to be looped back as received packets.  Since
iPXE's trivial LACP responder will send one response per received
packet, this results in an immediate LACP packet storm.

Detect looped back LACP packets (based on the received LACP actor MAC
address), and refuse to respond to such packets.

Reported-by: Tore Anderson <tore@fud.no>
Tested-by: Tore Anderson <tore@fud.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[efi] Defer local download process until file has been opened
Michael Brown [Tue, 13 Oct 2020 18:08:25 +0000 (19:08 +0100)] 
[efi] Defer local download process until file has been opened

When iPXE is downloading a file from an EFI_FILE_PROTOCOL instance
backed by an EFI_BLOCK_IO_PROTOCOL instance provided by the same iPXE
binary (e.g. via a hooked SAN device), then it is possible for step()
to be invoked as a result of the calls into the EFI_BLOCK_IO_PROTOCOL
methods.  This can potentially result in efi_local_step() being run
prematurely, before the file has been opened and before the parent
interface has been attached.

Fix by deferring starting the download process until immediately prior
to returning from efi_local_open().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[usbblk] Add support for USB mass storage devices
Michael Brown [Mon, 12 Oct 2020 14:31:49 +0000 (15:31 +0100)] 
[usbblk] Add support for USB mass storage devices

Some UEFI BIOSes (observed with at least the Insyde UEFI BIOS on a
Microsoft Surface Go) provide a very broken version of the
UsbMassStorageDxe driver that is incapable of binding to the standard
EFI_USB_IO_PROTOCOL instances and instead relies on an undocumented
proprietary protocol (with GUID c965c76a-d71e-4e66-ab06-c6230d528425)
installed by the platform's custom version of UsbCoreDxe.

The upshot is that USB mass storage devices become inaccessible once
iPXE's native USB host controller drivers are loaded.

One possible workaround is to load a known working version of
UsbMassStorageDxe (e.g. from the EDK2 tree): this driver will
correctly bind to the standard EFI_USB_IO_PROTOCOL instances exposed
by iPXE.  This workaround is ugly in practice, since it involves
embedding UsbMassStorageDxe.efi into the iPXE binary and including an
embedded script to perform the required "chain UsbMassStorageDxe.efi".

Provide a native USB mass storage driver for iPXE, allowing USB mass
storage devices to be exposed as iPXE SAN devices.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[usb] Move usbio driver to end of USB driver list
Michael Brown [Tue, 13 Oct 2020 14:29:23 +0000 (15:29 +0100)] 
[usb] Move usbio driver to end of USB driver list

iPXE will often have multiple drivers available for a USB device.  For
example: some USB network devices will support both RNDIS and CDC-ECM,
and any device may be consumed by the fallback "usbio" driver under
UEFI in order to expose an EFI_USB_IO_PROTOCOL instance.

The driver scoring mechanism is used to select a device configuration
based on the availability of drivers for the interfaces exposed in
each configuration.

For the case of RNDIS versus CDC-ECM, this mechanism will always
produce the correct result since RNDIS and CDC-ECM will not exist
within the same configuration and so each configuration will receive a
score based on the relevant driver.

This guarantee does not hold for the "usbio" driver, which will match
against any device.  It is a surprising coincidence that the "usbio"
driver seems to usually end up at the tail end of the USB drivers
list, thereby resulting in the expected behaviour.

Guarantee the expected behaviour by explicitly placing the "usbio"
driver at the end of the USB drivers list.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[usb] Allow endpoints to be refilled to a specified upper limit
Michael Brown [Mon, 12 Oct 2020 14:28:26 +0000 (15:28 +0100)] 
[usb] Allow endpoints to be refilled to a specified upper limit

For USB mass storage devices, we do not want to submit more bulk IN
packets than are required for the inbound data, since this will waste

Allow an upper limit to be specified on each refill attempt.  The
endpoint will be refilled to the lower of this limit or the limit
specified by usb_refill_init().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 weeks ago[usb] Allow device halt to be cleared independently of host controller
Michael Brown [Mon, 12 Oct 2020 14:21:25 +0000 (15:21 +0100)] 
[usb] Allow device halt to be cleared independently of host controller

Closing and reopening a USB endpoint will clear any halt status
recorded by the host controller, but may leave the endpoint halted at
the device.  This will cause the first packet submitted to the
reopened endpoint to be lost, before the automatic stall recovery
mechanism detects the halt and resets the endpoint.

This is relatively harmless for USB network or HID devices, since the
wire protocols will recover gracefully from dropped packets.  Some
protocols (e.g. for USB mass storage devices) assume zero packet loss
and so would be adversely affected.

Fix by allowing any device endpoint halt status to be cleared on a
freshly opened endpoint.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Always enable recursion when calling ConnectController()
Michael Brown [Thu, 1 Oct 2020 22:23:10 +0000 (23:23 +0100)] 
[efi] Always enable recursion when calling ConnectController()

There appears to be no reason for avoiding recursion when calling
ConnectController(), and recursion provides the least surprising

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Connect controllers after loading an EFI driver
Michael Brown [Thu, 1 Oct 2020 15:07:23 +0000 (16:07 +0100)] 
[efi] Connect controllers after loading an EFI driver

iPXE is already capable of loading EFI drivers on demand (via
e.g. "chain UsbMassStorageDxe.efi") but there is currently no way to
trigger connection of the driver to any preexisting handles.

Add an explicit call to (re)connect all drivers after successfully
loading an image with a code type that indicates a boot services

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[ncm] Treat a zero divisor as indicating no alignment requirements
Michael Brown [Thu, 1 Oct 2020 23:04:26 +0000 (00:04 +0100)] 
[ncm] Treat a zero divisor as indicating no alignment requirements

A zero divisor will currently lead to a 16-bit integer overflow when
calculating the transmit padding, and a potential division by zero if
assertions are enabled.

Avoid these problems by treating a divisor value of zero as equivalent
to a divisor value of one (i.e. no alignment requirements).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Fix reporting of USB supported languages array
Michael Brown [Thu, 1 Oct 2020 17:41:37 +0000 (18:41 +0100)] 
[efi] Fix reporting of USB supported languages array

The length as returned by UsbGetSupportedLanguages() should not
include the length of the descriptor header itself.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Avoid integer underflow on malformed USB string descriptors
Michael Brown [Thu, 1 Oct 2020 17:33:12 +0000 (18:33 +0100)] 
[efi] Avoid integer underflow on malformed USB string descriptors

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[usb] Avoid integer underflow on malformed string descriptors
Michael Brown [Thu, 1 Oct 2020 17:26:37 +0000 (18:26 +0100)] 
[usb] Avoid integer underflow on malformed string descriptors

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Allow DEBUG=efi_wrap to be used independently of a loaded image
Michael Brown [Thu, 1 Oct 2020 14:44:05 +0000 (15:44 +0100)] 
[efi] Allow DEBUG=efi_wrap to be used independently of a loaded image

Allow temporary debugging code to call efi_wrap_systab() to obtain a
pointer to the wrapper EFI system table.  This can then be used to
e.g. forcibly overwrite the boot services table pointer used by an
already loaded and running UEFI driver, in order to trace calls made
by that driver.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Disconnect controllers before uninstalling EFI_USB_IO_PROTOCOL
Michael Brown [Tue, 29 Sep 2020 20:13:10 +0000 (21:13 +0100)] 
[efi] Disconnect controllers before uninstalling EFI_USB_IO_PROTOCOL

The call to UninstallMultipleProtocolInterfaces() will implicitly
disconnect any relevant controllers, and there is no specified
requirement to explicitly call DisconnectController() prior to
callling UninstallMultipleProtocolInterfaces().

However, some UEFI implementations (observed with the USB keyboard
driver on a Microsoft Surface Go) will fail to implicitly disconnect
the controller and will consequently fail to uninstall the protocols.

The net effect is that unplugging and replugging a USB keyboard may
leave the keyboard in a non-functional state.

Work around these broken UEFI implementations by including an
unnecessary call to DisconnectController() before the call to

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[usb] Show debug message on device removal
Michael Brown [Tue, 29 Sep 2020 13:39:54 +0000 (14:39 +0100)] 
[usb] Show debug message on device removal

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Report any USB errors as EFI_USB_ERR_SYSTEM
Michael Brown [Tue, 29 Sep 2020 13:32:57 +0000 (14:32 +0100)] 
[efi] Report any USB errors as EFI_USB_ERR_SYSTEM

Some UEFI USB drivers (e.g. the UsbKbDxe driver in EDK2) will react to
a reported EFI_USB_ERR_STALL by attempting to clear the endpoint halt.
This is redundant with iPXE's EFI_USB_IO_PROTOCOL implementation,
since endpoint stalls are cleared automatically by the USB core as

The UEFI USB driver's attempt to clear the endpoint halt can introduce
an unwanted 5 second delay per endpoint if the USB error was the
result of a device being physically removed, since the control
transfer will always time out.

Fix by reporting all USB errors as EFI_USB_ERR_SYSTEM instead of

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[efi] Leave USB endpoint descriptors in existence until device is removed
Michael Brown [Tue, 29 Sep 2020 13:26:54 +0000 (14:26 +0100)] 
[efi] Leave USB endpoint descriptors in existence until device is removed

Some UEFI USB drivers (observed with the keyboard driver on a
Microsoft Surface Go) will react to an asynchronous USB transfer
failure by terminating the transfer from within the completion
handler.  This closes the USB endpoint and, in the current
implementation, frees the containing structure.

This can lead to use-after-free bugs after the UEFI USB driver's
completion handler returns, since the calling code in iPXE expects
that a completion handler will not perform a control-flow action such
as terminating the transfer.

Fix by leaving the USB endpoint structure allocated until the device
is finally removed, as is already done (as an optimisation) for
control and bulk transfers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 weeks ago[usb] Reset control endpoints immediately after failure
Michael Brown [Tue, 29 Sep 2020 09:16:14 +0000 (10:16 +0100)] 
[usb] Reset control endpoints immediately after failure

The current error handling mechanism defers the endpoint reset until
the next use of the endpoint, on the basis that errors are detected
during completions and completion handling should not recursively call

In the case of usb_control(), we are already at the level that calls
usb_poll() and can therefore safely perform the endpoint reset
immediately.  This has no impact on functionality, but does make
debugging traces easier to read since the reset will appear
immediately after the causative error.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 months ago[efi] Use address offset as reported by EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL
Michael Brown [Thu, 24 Sep 2020 20:41:35 +0000 (21:41 +0100)] 
[efi] Use address offset as reported by EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL

Retrieve the address windows and translation offsets for the
appropriate PCI root bridge and use them to adjust the PCI BAR address
prior to calling ioremap().

Originally-implemented-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 months ago[pci] Update drivers to use pci_ioremap()
Michael Brown [Thu, 24 Sep 2020 20:45:03 +0000 (21:45 +0100)] 
[pci] Update drivers to use pci_ioremap()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 months ago[pci] Define pci_ioremap() for mapping PCI bus addresses
Michael Brown [Thu, 24 Sep 2020 15:58:14 +0000 (16:58 +0100)] 
[pci] Define pci_ioremap() for mapping PCI bus addresses

Define pci_ioremap() as a wrapper around ioremap() that could allow
for a non-zero address translation offset.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 months ago[efi] Provide a single implementation of efipci_root_close()
Michael Brown [Thu, 24 Sep 2020 16:00:29 +0000 (17:00 +0100)] 
[efi] Provide a single implementation of efipci_root_close()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 months ago[efi] Show memory map returned by wrapped calls to GetMemoryMap
Michael Brown [Tue, 22 Sep 2020 12:59:37 +0000 (13:59 +0100)] 
[efi] Show memory map returned by wrapped calls to GetMemoryMap

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 months ago[efi] Add debug wrappers for all boot services functions of interest
Michael Brown [Fri, 18 Sep 2020 21:49:02 +0000 (22:49 +0100)] 
[efi] Add debug wrappers for all boot services functions of interest

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 months ago[build] Fix building on older versions of gcc asn1fix github/asn1fix
Michael Brown [Sun, 23 Aug 2020 16:52:41 +0000 (17:52 +0100)] 
[build] Fix building on older versions of gcc

Older versions of gcc (observed with gcc 4.5.3) require attributes to
be specified on the first declaration of a symbol, and will silently
ignore attributes specified after the initial declaration.  This
causes the ASN.1 OID-identified algorithms to end up misaligned.

Fix by adding __asn1_algorithm to the initial declarations in asn1.h.

Debugged-by: Dentcho Bankov <dbankov@vmware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 months ago[efi] Attempt NII initialisation both with and without cable detection
Michael Brown [Mon, 17 Aug 2020 12:08:05 +0000 (13:08 +0100)] 
[efi] Attempt NII initialisation both with and without cable detection

We currently use a heuristic to determine whether or not to request
cable detection in PXE_OPCODE_INITIALIZE, based on the need to work
around a known Emulex driver bug (see commit c0b61ba "[efi] Work
around bugs in Emulex NII driver") and the need to accommodate links
that are legitimately slow to come up (see commit 6324227 "[efi] Skip
cable detection at initialisation where possible").

This heuristic appears to fail with newer Emulex drivers.  Attempt to
support all known drivers (past and present) by first attempting
initialisation with cable detection, then falling back to attempting
initialisation without cable detection.

Reported-by: Kwang Woo Lee <kwleeyh@gmail.com>
Tested-by: Kwang Woo Lee <kwleeyh@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 months ago[efi] Use device path to locate filesystem from which we were loaded issue123 github/issue123
Michael Brown [Mon, 3 Aug 2020 14:26:25 +0000 (15:26 +0100)] 
[efi] Use device path to locate filesystem from which we were loaded

The file:/ URI syntax may be used to refer to local files on the
filesystem from which the iPXE binary was loaded.  This is currently
implemented by directly using the DeviceHandle recorded in our

This mechanism will fail when a USB-enabled build of iPXE is loaded
from USB storage and subsequently installs its own USB host controller
drivers, since doing so will disconnect and reconnect the existing USB
storage drivers and thereby invalidate the original storage device

Fix by recording the device path for the loaded image's DeviceHandle
at initialisation time and later using the recorded device path to
locate the appropriate device handle.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 months ago[efi] Match EDK2 numbering for USB ports
Michael Brown [Mon, 3 Aug 2020 13:42:18 +0000 (14:42 +0100)] 
[efi] Match EDK2 numbering for USB ports

The various USB specifications all use one-based numbering for ports.
This scheme is applied consistently across the various relevant
specifications, covering both port numbers that appear on the wire
(i.e. downstream hub port numbers) and port numbers that exist only
logically (i.e. root hub port numbers).

The UEFI specification is ambiguous about the port numbers as used for
the ParentPortNumber field within a USB_DEVICE_PATH structure.  As of
UEFI specification version 2.8 errata B:

- section just states "USB Parent Port Number" with no
  indication of being zero-based or one-based

- section 17.1.1 notes that for the EFI_USB2_HC_PROTOCOL, references
  to PortNumber parameters are zero-based for root hub ports

- section 17.1.1 also mentions a TranslatorPortNumber used by
  EFI_USB2_HC_PROTOCOL, with no indication of being zero-based or

- there are no other mentions of USB port numbering schemes.

Experimentation and inspection of the EDK2 codebase reveals that at
least the EDK2 reference implementation will use zero-based numbering
for both root and non-root hub ports when populating a USB_DEVICE_PATH
structure (though will inconsistently use one-based numbering for the
TranslatorPortNumber parameter).

Use zero-based numbering for both root and non-root hub ports when
constructing a USB_DEVICE_PATH in order to match the behaviour of the
EDK2 implementation.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[comboot] Fix stack pointer retrieval after COM32 binary returns
Dentcho Ludmilov Bankov [Fri, 1 Feb 2019 22:20:21 +0000 (00:20 +0200)] 
[comboot] Fix stack pointer retrieval after COM32 binary returns

This change fixes the offset used when retrieving the iPXE stack
pointer after a COM32 binary returns.  The iPXE stack pointer is saved
at the top of the available memory then the the top of the stack for
the COM32 binary is set just below it.  However seven more items are
pushed on the COM32 stack before the entry point is invoked so when
the COM32 binary returns the location of the iPXE stack pointer is 28
(and not 24) bytes above the current stack pointer.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[efi] Check the status code from AllocatePool()
Ignat Korchagin [Tue, 21 Jul 2020 21:27:08 +0000 (22:27 +0100)] 
[efi] Check the status code from AllocatePool()

According to the latest UEFI specification (Version 2.8 Errata B)
p. 7.2:

  "Buffer: A pointer to a pointer to the allocated buffer if the call
   succeeds; undefined otherwise."

So implementations are obliged neither to return NULL, if the
allocation fails, nor to preserve the contents of the pointer.

Make the logic more reliable by checking the status code from
AllocatePool() instead of checking the returned pointer for NULL

Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[cmdline] Add "--timeout" parameter to "ifconf" command
Joe Groocock [Fri, 20 Sep 2019 12:41:29 +0000 (13:41 +0100)] 
[cmdline] Add "--timeout" parameter to "ifconf" command

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[intelx] Added PCI_ROM entry for Intel x553/x557-AT and x553 (SFP+) NICs
Rob Taglang [Tue, 2 Oct 2018 19:41:51 +0000 (15:41 -0400)] 
[intelx] Added PCI_ROM entry for Intel x553/x557-AT and x553 (SFP+) NICs

Signed-off-by: Rob Taglang <rob@taglang.io>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[intel] Set INTEL_NO_PHY_RST on i218v
Ben Bleything [Sun, 4 Nov 2018 06:53:27 +0000 (23:53 -0700)] 
[intel] Set INTEL_NO_PHY_RST on i218v

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[intel] Add INTEL_NO_PHY_RST for I218LM
Andrew Grasso [Thu, 13 Jul 2017 13:04:01 +0000 (09:04 -0400)] 
[intel] Add INTEL_NO_PHY_RST for I218LM

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[deflate] Fix typo in comment describing length codes
Daniel Johnson [Tue, 21 Jul 2020 05:20:43 +0000 (22:20 -0700)] 
[deflate] Fix typo in comment describing length codes

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[build] Fix a GNUism that FreeBSD's sed(1) cannot deal with
Tobias Kortkamp [Sun, 25 Nov 2018 16:57:13 +0000 (17:57 +0100)] 
[build] Fix a GNUism that FreeBSD's sed(1) cannot deal with

At the moment '\s*' is silently interpreted as just 's*', but in the
future it will be an error:

sed: 1: "s/\.o\s*:/_DEPS +=/": RE error: trailing backslash (\)

cf. https://bugs.freebsd.org/229925

Signed-off-by: Tobias Kortkamp <t@tobik.me>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[wpa] Fix erroneous debug message in wpa_derive_ptk
Michael Brown [Tue, 21 Jul 2020 14:34:39 +0000 (15:34 +0100)] 
[wpa] Fix erroneous debug message in wpa_derive_ptk

Split debug message since eth_ntoa() uses a static result buffer.

Originally-fixed-by: Michael Bazzinotti <bazz@bazz1.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[libc] Fix memcmp() to return proper values
Michael J. Bazzinotti [Tue, 14 Jan 2020 18:15:02 +0000 (13:15 -0500)] 
[libc] Fix memcmp() to return proper values

Fix memcmp() to return proper standard positive/negative values for
unequal comparisons.  Current implementation is backwards (i.e. the
functions are returning negative when should be positive and

Currently most consumers of these functions only check the return value
for ==0 or !=0 and so we can safely change the implementation without
breaking things.

However, there is one call that checks the polarity of this function,
and that is prf_sha1() for wireless WPA 4-way handshake.  Due to the
incorrect memcmp() polarity, the WPA handshake creates an incorrect
PTK, and the handshake would fail after step 2.  Undoubtedly, the AP
noticed the supplicant failed the mic check.  This commit fixes that

Similar to commit 3946aa9 ("[libc] Fix strcmp()/strncmp() to return
proper values").

Signed-off-by: Michael Bazzinotti <bazz@bazz1.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[pcbios] Take alignment into account when checking for available space
David Decotigny [Wed, 15 Jan 2020 07:42:05 +0000 (23:42 -0800)] 
[pcbios] Take alignment into account when checking for available space

Signed-off-by: David Decotigny <ddecotig@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[pcbios] Fix "out of memory" detection when expanding bottom area
David Decotigny [Wed, 15 Jan 2020 07:31:03 +0000 (23:31 -0800)] 
[pcbios] Fix "out of memory" detection when expanding bottom area

This caused iPXE to reject images even when enough memory was

Signed-off-by: David Decotigny <ddecotig@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[libgcc] Change __divmoddi4 from int64 [unknown] to int64_t
Bobby Lockwood [Mon, 19 Dec 2016 12:01:15 +0000 (12:01 +0000)] 
[libgcc] Change __divmoddi4 from int64 [unknown] to int64_t

Matches the header file libgcc.h and solves

  __divmoddi4.c:3:56: error: unknown type name ‘int64’

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[build] Fix default target in sdsk image
bit [Sun, 19 Aug 2018 14:30:43 +0000 (16:30 +0200)] 
[build] Fix default target in sdsk image

gensdsk currently creates a syslinux.cfg file that is invalid if the
filename ends in lkrn.  Fix by setting the default target to label($b)
instead of filename($g).

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[dns] Use all configured DNS servers
Michael Brown [Wed, 15 Jul 2020 18:10:30 +0000 (19:10 +0100)] 
[dns] Use all configured DNS servers

When no response is obtained from the first configured DNS server,
fall back to attempting the other configured servers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[xfer] Remove address family from definition of a socket opener
Michael Brown [Wed, 15 Jul 2020 17:46:58 +0000 (18:46 +0100)] 
[xfer] Remove address family from definition of a socket opener

All implemented socket openers provide definitions for both IPv4 and
IPv6 using exactly the same opener method.  Simplify the logic by
omitting the address family from the definition.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[sfc] Add PCI ID for Solarflare SFC9120 and Solarflare SFC9140
LaDerrick H [Tue, 14 Jul 2020 15:59:59 +0000 (10:59 -0500)] 
[sfc] Add PCI ID for Solarflare SFC9120 and Solarflare SFC9140

This patch adds support for 2 Solarflare NICs.

Signed-off-by: LaDerrick H <ipxelist243@lacutt.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[efi] Claim SNP devices early in efi_download_start() tpl github/tpl
Michael Brown [Tue, 14 Jul 2020 17:24:02 +0000 (18:24 +0100)] 
[efi] Claim SNP devices early in efi_download_start()

Claiming the SNP devices has the side effect of raising the TPL to
iPXE's normal operating level of TPL_CALLBACK (see the commit message
for c89a446 ("[efi] Run at TPL_CALLBACK to protect against UEFI
timers") for details).  This must happen before executing any code
that relies upon the TPL having been raised to TPL_CALLBACK.

The call to efi_snp_claim() in efi_download_start() currently happens
only after the call to xfer_open().  Calling xfer_open() will
typically result in a retry timer being started, which will result in
a call to currticks() in order to initialise the timer.  The call to
currticks() will drop to TPL_APPLICATION and restore to TPL_CALLBACK
in order to allow a timer tick to occur.  Since this call happened
before the call to efi_snp_claim(), the restored TPL is incorrect.

This in turn results in efi_snp_claim() recording the incorrect
original TPL, causing efi_snp_release() to eventually restore the
incorrect TPL, causing the system to lock up when ExitBootServices()
is called at TPL_CALLBACK.

Fix by moving the call to efi_snp_claim() to the start of

Debugged-by: Jarrod Johnson <jjohnson2@lenovo.com>
Debugged-by: He He4 Huang <huanghe4@lenovo.com>
Debugged-by: James Wang <jameswang@ami.com.tw>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[efi] Ensure NUL byte is at lowest address within stack cookie cookie github/cookie
Michael Brown [Thu, 9 Jul 2020 13:20:53 +0000 (14:20 +0100)] 
[efi] Ensure NUL byte is at lowest address within stack cookie

The NUL byte included within the stack cookie to act as a string
terminator should be placed at the lowest byte address within the
stack cookie, in order to avoid potentially including the stack cookie
value within an accidentally unterminated string.

Suggested-by: Pete Beck <pete.beck@ioactive.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[efi] Distribute available entropy within stack cookie
Michael Brown [Thu, 9 Jul 2020 12:56:50 +0000 (13:56 +0100)] 
[efi] Distribute available entropy within stack cookie

Several of the values used to compute a stack cookie (in the absence
of a viable entropy source) will tend to have either all-zeroes or
all-ones in the higher order bits.  Rotate the values in order to
distribute the (minimal) available entropy more evenly.

Suggested-by: Pete Beck <pete.beck@ioactive.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[libc] Add bit-rotation functions for unsigned long values
Michael Brown [Thu, 9 Jul 2020 12:51:30 +0000 (13:51 +0100)] 
[libc] Add bit-rotation functions for unsigned long values

Generalise the bit rotation implementations to use a common macro, and
add roll() and rorl() to handle unsigned long values.

Each function will still compile down to a single instruction.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[efi] Avoid setting direction flag on EFI platforms
Michael Brown [Tue, 7 Jul 2020 12:49:17 +0000 (13:49 +0100)] 
[efi] Avoid setting direction flag on EFI platforms

The only remaining use case in iPXE for the CPU direction flag is in
__memcpy_reverse() where it is set to allow the use of "rep movsb" to
perform the memory copy.  This matches the equivalent functionality in
the EDK2 codebase, which has functions such as InternalMemCopyMem that
also temporarily set the direction flag in order to use "rep movsb".

As noted in commit d2fb317 ("[crypto] Avoid temporarily setting
direction flag in bigint_is_geq()"), some UEFI implementations are
known to have buggy interrupt handlers that may reboot the machine if
a timer interrupt happens to occur while the direction flag is set.

Work around these buggy UEFI implementations by using the
(unoptimised) generic_memcpy_reverse() on i386 or x86_64 UEFI

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[libc] Provide an unoptimised generic_memcpy_reverse()
Michael Brown [Tue, 7 Jul 2020 12:13:28 +0000 (13:13 +0100)] 
[libc] Provide an unoptimised generic_memcpy_reverse()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[crypto] Avoid temporarily setting direction flag in bigint_is_geq()
Michael Brown [Mon, 6 Jul 2020 23:09:40 +0000 (00:09 +0100)] 
[crypto] Avoid temporarily setting direction flag in bigint_is_geq()

The UEFI specification states that the calling convention for IA-32
and x64 includes "Direction flag in EFLAGS is clear".  This
specification covers only the calling convention used at the point of
calling functions annotated with EFIAPI.  The specification explicitly
states that other functions (such as private functions or static
library calls) are not required to follow the UEFI calling

The reference EDK2 implementation follows this specification.  In
particular, the EDK2 interrupt handlers will clear the direction flag
before calling any EFIAPI functions, and will restore the direction
flag when returning from the interrupt handler.  Some EDK2 private
library functions (most notably InternalMemCopyMem) may set the
direction flag temporarily in order to make efficient use of CPU
string operations.

The current implementation of iPXE's bigint_is_geq() for i386 and
x86_64 will similarly set the direction flag temporarily in order to
make efficient use of CPU string operations.

On some UEFI implementations (observed with a Getac RX10 tablet), a
timer interrupt that happens to occur while the direction flag is set
will reboot the machine.  This very strongly indicates that the UEFI
timer interrupt handler is failing to clear the direction flag before
performing an affected operation (such as copying a block of memory).

Work around such buggy UEFI implementations by rewriting
bigint_is_geq() to avoid the use of string operations and so obviate
the requirement to temporarily set the direction flag.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[usb] Leave port enabled after a failed device registration
Michael Brown [Sat, 4 Jul 2020 10:52:26 +0000 (11:52 +0100)] 
[usb] Leave port enabled after a failed device registration

A failure in device registration (e.g. due to a device with malformed
descriptors) will currently result in the port being disabled as part
of the error path.  This in turn causes the hardware to detect the
device as newly connected, leading to an endless loop of failed device

Fix by leaving the port enabled in the case of a registration failure.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[axge] Reapply USB device configuration when opening network device
Michael Brown [Fri, 3 Jul 2020 19:17:25 +0000 (20:17 +0100)] 
[axge] Reapply USB device configuration when opening network device

When connected to a USB3 port, the AX88179 seems to have an
approximately 50% chance of producing a USB transaction error on each
of its three endpoints after being closed and reopened.  The root
cause is unclear, but rewriting the USB device configuration value
seems to clear whatever internal error state has accumulated.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[xhci] Increase link state settling delay to 100ms
Michael Brown [Fri, 3 Jul 2020 11:52:05 +0000 (12:52 +0100)] 
[xhci] Increase link state settling delay to 100ms

Experimentation shows that the existing 20ms delay is insufficient,
and often results in device detection being deferred until after iPXE
has completed startup.

Fix by increasing the delay to 100ms.

Signed-off-by: Michael Brown <mcb30@ipxe.org>