Michael Brown [Sun, 18 Sep 2022 12:41:21 +0000 (13:41 +0100)]
[pci] Select PCI I/O API at runtime for cloud images
Pretty much all physical machines and off-the-shelf virtual machines
will provide a functional PCI BIOS. We therefore default to using
only the PCI BIOS, with no fallback to an alternative mechanism if the
PCI BIOS fails.
AWS EC2 provides the opportunity to experience some exceptions to this
rule. For example, the t3a.nano instances in eu-west-1 have no
functional PCI BIOS at all. As of commit 83516ba ("[cloud] Use
PCIAPI_DIRECT for cloud images") we therefore use direct Type 1
configuration space accesses in the images built and published for use
in the cloud.
Recent experience has discovered yet more variation in AWS EC2
instances. For example, some of the metal instance types have
multiple PCI host bridges and the direct Type 1 accesses therefore
see only a subset of the PCI devices.
Attempt to accommodate future such variations by making the PCI I/O
API selectable at runtime and choosing ECAM (if available), falling
back to the PCI BIOS (if available), then finally falling back to
direct Type 1 accesses.
This is implemented as a dedicated PCIAPI_CLOUD API, rather than by
having the PCI core select a suitable API at runtime (as was done for
timers in commit 302f1ee ("[time] Allow timer to be selected at
runtime"). The common case will remain that only the PCI BIOS API is
required, and we would prefer to retain the optimisations that come
from inlining the configuration space accesses in this common case.
Cloud images are (at present) disk images rather than ROM images, and
so the increased code size required for this design approach in the
PCIAPI_CLOUD case is acceptable.
Michael Brown [Wed, 14 Sep 2022 13:29:52 +0000 (14:29 +0100)]
[pci] Add support for the Enhanced Configuration Access Mechanism (ECAM)
The ACPI MCFG table describes a direct mapping of PCI configuration
space into MMIO space. This mapping allows access to extended
configuration space (up to 4096 bytes) and also provides for the
existence of multiple host bridges.
Add support for the ECAM mechanism described by the ACPI MCFG table,
as a selectable PCI I/O API alongside the existing PCI BIOS and Type 1
mechanisms.
Michael Brown [Thu, 15 Sep 2022 15:47:04 +0000 (16:47 +0100)]
[pci] Generalise pci_num_bus() to pci_discover()
Allow pci_find_next() to discover devices beyond the first PCI
segment, by generalising pci_num_bus() (which implicitly assumes that
there is only a single PCI segment) with pci_discover() (which has the
ability to return an arbitrary contiguous chunk of PCI bus:dev.fn
address space).
Michael Brown [Thu, 15 Sep 2022 14:04:01 +0000 (15:04 +0100)]
[pci] Check for wraparound in callers of pci_find_next()
The semantics of the bus:dev.fn parameter passed to pci_find_next()
are "find the first existent PCI device at this address or higher",
with the caller expected to increment the address between finding
devices. This does not allow the parameter to distinguish between the
two cases "start from address zero" and "wrapped after incrementing
maximal possible address", which could therefore lead to an infinite
loop in the degenerate case that a device with address ffff:ff:1f.7
really exists.
Fix by checking for wraparound in the caller (which is already
responsible for performing the increment).
Michael Brown [Thu, 15 Sep 2022 13:55:26 +0000 (14:55 +0100)]
[pci] Allow pci_find_next() to return non-zero PCI segments
Separate the return status code from the returned PCI bus:dev.fn
address, in order to allow pci_find_next() to be used to find devices
with a non-zero PCI segment number.
Michael Brown [Tue, 13 Sep 2022 12:25:19 +0000 (13:25 +0100)]
[ipv6] Ignore SLAAC on prefixes with an incompatible prefix length
Experience suggests that routers are often misconfigured to advertise
SLAAC even on prefixes that do not have a SLAAC-compatible prefix
length. iPXE will currently treat this as an error, resulting in the
prefix being ignored completely.
Handle this misconfiguration by ignoring the autonomous address flag
when the prefix length is unsuitable for SLAAC.
Reported-by: Malte Janduda <mail@janduda.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Fri, 26 Aug 2022 12:17:48 +0000 (13:17 +0100)]
[ena] Increase receive ring size to 128 entries
Some versions of the ENA hardware (observed on a c6i.large instance in
eu-west-2) seem to require a receive ring containing at least 128
entries: any smaller ring will never see receive completions or will
stall after the first few completions.
Increase the receive ring size to 128 entries (determined empirically)
for compatibility with these hardware versions. Limit the receive
ring fill level to 16 (as at present) to avoid consuming more memory
than will typically be available in the internal heap.
Michael Brown [Fri, 26 Aug 2022 12:37:23 +0000 (13:37 +0100)]
[ena] Provide a host information page
Some versions of the ENA firmware (observed on a c6i.large instance in
eu-west-2) seem to require a host information page, without which the
CREATE_CQ command will fail with ENA_ADMIN_UNKNOWN_ERROR.
These firmware versions also seem to require us to claim that we are a
Linux kernel with a specific driver major version number. This
appears to be a firmware bug, as revealed by Linux kernel commit 1a63443af ("net/amazon: Ensure that driver version is aligned to the
linux kernel"): this commit changed the value of the driver version
number field to be the Linux kernel version, and was hastily reverted
in commit 92040c6da ("net: ena: fix broken interface between ENA
driver and FW") which clarified that the version number field does
actually have some undocumented significance to some versions of the
firmware.
Fix by providing a host information page via the SET_FEATURE command,
incorporating the apparently necessary lies about our identity.
Michael Brown [Fri, 26 Aug 2022 12:15:07 +0000 (13:15 +0100)]
[ena] Specify the unused completion queue MSI-X vector as 0xffffffff
Some versions of the ENA firmware (observed on a c6i.large instance in
eu-west-2) will complain if the completion queue's MSI-X vector field
is left empty, even though the queue configuration specifies that
interrupts are not used.
Work around these firmware versions by passing in what appears to be
the magic "no MSI-X vector" value in this field.
Michael Brown [Fri, 26 Aug 2022 14:48:52 +0000 (15:48 +0100)]
[ena] Allow for out-of-order completions
The ENA data path design has separate submission and completion
queues. Submission queues must be refilled in strict order (since
there is only a single linear tail pointer used to communicate the
existence of new entries to the hardware), and completion queue
entries include a request identifier copied verbatim from the
submission queue entry. Once the submission queue doorbell has been
rung, software never again reads from the submission queue entry and
nothing ever needs to write back to the submission queue entry since
completions are reported via the separate completion queue.
This design allows the hardware to complete submission queue entries
out of order, provided that it internally caches at least as many
entries as it leaves gaps.
Record and identify I/O buffers by request identifier (using a
circular ring buffer of unique request identifiers), and remove the
assumption that submission queue entries will be completed in order.
Michael Brown [Fri, 26 Aug 2022 13:13:52 +0000 (14:13 +0100)]
[ena] Limit submission queue fill level to completion queue size
The CREATE_CQ command is permitted to return a size smaller than
requested, which could leave us in a situation where the completion
queue could overflow.
Avoid overflow by limiting the submission queue fill level to the
actual size of the completion queue.
Michael Brown [Tue, 16 Aug 2022 14:53:41 +0000 (15:53 +0100)]
[intelxl] Explicitly request a single queue pair for virtual functions
Current versions of the E810 PF driver fail to set the number of
in-use queue pairs in response to the CONFIG_VSI_QUEUES message. When
the number of in-use queue pairs is less than the number of available
queue pairs, this results in some packets being directed to
nonexistent receive queues and hence silently dropped.
Work around this PF driver bug by explicitly configuring the number of
available queue pairs via the REQUEST_QUEUES message. This message
triggers a VF reset that, in turn, requires us to reopen the admin
queue and issue an additional GET_RESOURCES message to restore the VF
to a functional state.
Michael Brown [Tue, 16 Aug 2022 16:59:37 +0000 (17:59 +0100)]
[intelxl] Allow for admin commands that trigger a VF reset
The RESET_VF admin queue command does not complete via the usual
mechanism, but instead requires us to poll registers to wait for the
reset to take effect and then reopen the admin queue.
Allow for the existence of other admin queue commands that also
trigger a VF reset, by separating out the logic that waits for the
reset to complete.
Michael Brown [Mon, 8 Aug 2022 14:02:44 +0000 (15:02 +0100)]
[intelxl] Add driver for Intel 100 Gigabit Ethernet NICs
Add a driver for the E810 family of 100 Gigabit Ethernet NICs. The
core datapath is identical to that of the 40 Gigabit XL710, and this
part of the code is shared between both drivers. The admin queue
mechanism is sufficiently similar to make it worth reusing substantial
portions of the code, with separate implementations for several
commands to handle the (unnecessarily) breaking changes in data
structure layouts. The major differences are in the mechanisms for
programming queue contexts (where the E810 abandons TX/RX symmetry)
and for configuring the transmit scheduler and receive filters: these
portions are sufficiently different to justify a separate driver.
Michael Brown [Fri, 12 Aug 2022 11:48:35 +0000 (12:48 +0100)]
[intelxl] Set maximum frame size to 9728 bytes as per datasheet
The PRTGL_SAH register contains the current maximum frame size, and is
not guaranteed on reset to contain the actual maximum frame size
supported by the hardware, which the datasheet specifies as 9728 bytes
(including the 4-byte CRC).
Set the maximum packet size to a hardcoded 9728 bytes instead of
reading from the PRTGL_SAH register.
Remove knowledge of the GLLAN_RCTL_0 register (which changes location
between the XL810 and E810 register maps), and instead unconditionally
issue the "clear PXE mode" command with the EEXIST error silenced.
Michael Brown [Thu, 17 Mar 2022 13:01:50 +0000 (13:01 +0000)]
[intelxl] Allow expected admin queue command errors to be silenced
The "clear PXE mode" admin queue command will return an EEXIST error
if the device is already in non-PXE mode, but there is no other admin
queue command that can be used to determine whether the device has
already been switched into non-PXE mode.
Provide a mechanism to allow expected errors from a command to be
silenced, to allow the "clear PXE mode" command to be cleanly used
without needing to first check the GLLAN_RCTL_0 register value.
Michael Brown [Thu, 11 Aug 2022 14:21:44 +0000 (15:21 +0100)]
[intelxl] Increase data buffer size to 4kB
At least one E810 admin queue command (Query Default Scheduling Tree
Topology) insists upon being provided with a 4kB data buffer, even
when the data to be returned is much smaller.
Work around this requirement by increasing the admin queue data buffer
size to 4kB.
Michael Brown [Mon, 8 Aug 2022 13:48:25 +0000 (14:48 +0100)]
[intelxl] Reuse admin command descriptor and buffer for VF responses
Remove the large static admin data buffer structure embedded within
struct intelxl_nic, and instead copy the response received via the
"send to VF" admin queue event to the (already consumed and completed)
admin command descriptor and data buffer.
Michael Brown [Mon, 8 Aug 2022 13:34:47 +0000 (14:34 +0100)]
[intelxl] Handle admin events via a callback
The physical and virtual function drivers each care about precisely
one admin queue event type. Simplify event handling by using a
per-driver callback instead of the existing weak function symbol.
Michael Brown [Sun, 13 Mar 2022 14:37:11 +0000 (14:37 +0000)]
[intelxl] Rename 8086:1889 PCI ID to "iavf"
The PCI device ID 8086:1889 is for the Intel Ethernet Adaptive Virtual
Function, which is a generic virtual function that can be exposed by
different generations of Intel hardware.
Rename the PCI ID from "xl710-vf-ad" to "iavf" to reflect that the
driver is not XL710-specific.
Michael Brown [Wed, 9 Mar 2022 00:30:14 +0000 (00:30 +0000)]
[intelxl] Negotiate API version for virtual function via admin queue
Do not attempt to use the admin commands to get the firmware version
and report the driver version for the virtual function driver, since
these will be rejected by the E810 firmware as invalid commands when
issued by a virtual function. Instead, use the mailbox interface to
negotiate the API version with the physical function driver.
Michael Brown [Wed, 9 Mar 2022 00:24:22 +0000 (00:24 +0000)]
[intelxl] Use non-zero MSI-X vector for virtual function interrupts
The 100 Gigabit physical function driver requires a virtual function
driver to request that transmit and receive queues are mapped to MSI-X
vector 1 or higher.
Michael Brown [Thu, 17 Mar 2022 13:45:31 +0000 (13:45 +0000)]
[intelxl] Use function-level reset instead of PFGEN_CTRL.PFSWR
Remove knowledge of the PFGEN_CTRL register (which changes location
between XL710 and E810 register maps), and instead use PCIe FLR to
reset the physical function.
Michael Brown [Mon, 14 Mar 2022 16:28:24 +0000 (16:28 +0000)]
[intelxl] Fix retrieval of switch configuration via admin queue
Commit 8f3e648 ("[intelxl] Use one admin queue buffer per admin queue
descriptor") changed the API for intelxl_admin_command() such that the
caller now constructs the command directly within the next available
descriptor ring entry, rather than relying on intelxl_admin_command()
to copy the descriptor to and from the descriptor ring.
This introduced a regression in intelxl_admin_switch(), since the
second and subsequent iterations of the loop will not have constructed
a valid command in the new descriptor ring entry before calling
intelxl_admin_command().
Michael Brown [Fri, 10 Jun 2022 12:42:01 +0000 (13:42 +0100)]
[acpi] Expose system MAC address via ${sysmac} setting
Expose the system MAC address (if any) via the ${sysmac} setting.
This allows scripts to access the system MAC address even when iPXE
has decided not to apply it to a network device (e.g. because the
cached DHCPACK MAC address was selected in order to match the
behaviour of a previous boot stage).
The setting is named ${sysmac} rather than ${acpimac} in order to
allow for forward compatibility with non-ACPI mechanisms that may
exist in future for specifying a system MAC address.
Michael Brown [Mon, 23 May 2022 12:05:24 +0000 (13:05 +0100)]
[cachedhcp] Allow cached DHCPACK to override a temporary MAC address
When running on a system with an ACPI-provided system-specific MAC
address, iPXE will apply this address to an ECM or NCM USB NIC. If
iPXE has been chainloaded from a previous stage that does not
understand the ACPI MAC mechanism then this can result in iPXE using a
different MAC address than the previous stage, which is surprising to
users.
Attempt to minimise surprise by allowing the MAC address found in a
cached DHCPACK packet to override a temporary MAC address, if the
DHCPACK MAC address matches the network device's permanent MAC
address. When a previous stage has chosen to use the network device's
permanent MAC address (e.g. because it does not understand the ACPI
MAC mechanism), this will cause iPXE to make the same choice.
Michael Brown [Mon, 23 May 2022 11:23:53 +0000 (12:23 +0100)]
[ecm] Treat ACPI MAC address as being a non-permanent MAC address
When applying an ACPI-provided system-specific MAC address, apply it
to netdev->ll_addr rather than netdev->hw_addr. This allows iPXE
scripts to access the permanent MAC address via the ${netX/hwaddr}
setting (and thereby provides scripts with a mechanism to ascertain
that the NIC is using a MAC address other than its own permanent
hardware address).
Michael Brown [Wed, 23 Mar 2022 15:02:17 +0000 (15:02 +0000)]
[acpi] Support the "_RTXMAC_" format for ACPI-based MAC addresses
Some newer HP products expose the host-based MAC (HBMAC) address using
an ACPI method named "RTMA" returning a part-binary string of the form
"_RTXMAC_#<mac>#", where "<mac>" comprises the raw MAC address bytes.
Extend the existing support to handle this format alongside the older
"_AUXMAC_" format (which uses a base16-encoded MAC address).
Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Wed, 23 Mar 2022 14:41:36 +0000 (14:41 +0000)]
[linux] Add stub phys_to_user() implementation
For symmetry with the stub user_to_phys() implementation, provide
phys_to_user() with the same underlying assumption that virtual
addresses are physical (since there is no way to know the real
physical address when running as a Linux userspace executable).
Michael Brown [Wed, 23 Feb 2022 22:52:08 +0000 (22:52 +0000)]
[dns] Always start DNS queries using the first configured DNS server
We currently define the active DNS server as a global variable. All
queries will start by attempting to contact the active DNS server, and
the active DNS server will be changed only if we fail to get a
response. This effectively treats the DNS server list as expressing a
weak preference ordering: we will try servers in order, but once we
have found a working server we will stick with that server for as long
as it continues to respond to queries.
Some sites are misconfigured to hand out DNS servers that do not have
a consistent worldview. For example: the site may hand out two DNS
server addresses, the first being an internal DNS server (which is
able to resolve names in private DNS domains) and the second being a
public DNS server such as 8.8.8.8 (which will correctly return
NXDOMAIN for any private DNS domains). This type of configuration is
fundamentally broken and should never be used, since any DNS resolver
performing a query for a name within a private DNS domain may obtain a
spurious NXDOMAIN response for a valid private DNS name.
Work around these broken configurations by treating the DNS server
list as expressing a strong preference ordering, and always starting
DNS queries from the first server in the list (rather than maintaining
a global concept of the active server). This will have the debatable
benefit of converting permanent spurious NXDOMAIN errors into
transient spurious NXDOMAIN errors, which can at least be worked
around at a higher level (e.g. by retrying a download in a loop within
an iPXE script).
The cost of always starting DNS queries from the first server in the
list is a slight delay introduced when the first server is genuinely
unavailable. This should be negligible in practice since DNS queries
are relatively infrequent and the failover expiry time is short.
Treating the DNS server list as a preference ordering is permitted by
the language of RFC 2132, which defines DHCP option 6 as a list in
which "[DNS] servers SHOULD be listed in order of preference". No
specification defines a precise algorithm for how this preference
order should be applied in practice: this new approach seems as good
as any.
Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Wed, 16 Feb 2022 15:19:35 +0000 (15:19 +0000)]
[console] Include mappings for AltGr-Shift-<key>
The BIOS console's interpretation of LShift+RShift as equivalent to
AltGr requires the shifted ASCII characters to be present in the AltGr
mapping table, to allow AltGr-Shift-<key> to be interpreted in the
same way as AltGr-<key>.
For keyboard layouts that have different ASCII characters for
AltGr-<key> and AltGr-Shift-<key>, this will potentially leave the
character for AltGr-<key> inaccessible via the BIOS console if the
BIOS requires the use of the LShift+RShift workaround. This
theoretically affects the numeric keys in the Lithuanian ("lt")
keyboard layout (where the numerals are accessed via AltGr-<key> and
punctuation characters via AltGr-Shift-<key>), but the simple
workaround for that keyboard layout is to avoid using AltGr and Shift
entirely since the unmodified numeric keys are not remapped anyway.
Michael Brown [Wed, 16 Feb 2022 00:12:55 +0000 (00:12 +0000)]
[settings] Always process all settings applicators
Settings applicators are entirely independent, and there is no reason
why a failure in one applicator should prevent other applicators from
being processed.
Michael Brown [Wed, 16 Feb 2022 13:22:56 +0000 (13:22 +0000)]
[xsigo] Avoid storing unused uninitialised fields in gateway address
As reported by Coverity, xsmp_rx_xve_modify() currently passes a
partially initialised struct ib_address_vector to xve_update_tca() and
thence to eoib_set_gateway(), which uses memcpy() to store the whole
structure including the (unused and unneeded) uninitialised fields.
Silence the Coverity warning by zeroing the whole structure.
Michael Brown [Wed, 16 Feb 2022 12:30:02 +0000 (12:30 +0000)]
[pci] Ensure that pci_read_config() initialises all fields
As per the general pattern for initialisation functions in iPXE,
pci_init() saves code size by assuming that the caller has already
zeroed the underlying storage (e.g. as part of zeroing a larger
containing structure). There are several places within the code where
pci_init() is deliberately used to initialise a transient struct
pci_device without zeroing the entire structure, because the calling
code knows that only the PCI bus:dev.fn address is required to be
initialised (e.g. when reading from PCI configuration space).
Ensure that using pci_init() followed by pci_read_config() will fully
initialise the struct pci_device even if the caller did not previously
zero the underlying storage, since Coverity reports that there are
several places in the code that rely upon this.
Michael Brown [Tue, 15 Feb 2022 14:28:01 +0000 (14:28 +0000)]
[image] Do not clear current working URI when executing embedded image
Embedded images do not have an associated URI. This currently causes
the current working URI (cwuri) to be cleared when starting an
embedded image.
If the current working URI has been set via a ${next-server} setting
from a cached DHCP packet then this will result in unexpected
behaviour. An attempt by the embedded script to use a relative URI to
download files from the TFTP server will fail with the error:
Could not start download: Operation not supported (ipxe.org/3c092083)
Rerunning the "dhcp" command will not fix this error, since the TFTP
settings applicator will not see any change to the ${next-server}
setting and so will not reset the current working URI.
Fix by setting the current working URI to the image's URI only if the
image actually has an associated URI.
Debugged-by: Ignat Korchagin <ignat@cloudflare.com> Originally-fixed-by: Ignat Korchagin <ignat@cloudflare.com> Tested-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Tue, 15 Feb 2022 16:41:19 +0000 (16:41 +0000)]
[console] Fix definition of unreachability for remapped keys
The AltGr remapping table is constructed to include only keys that are
not reachable after applying the basic remapping table. The logic
currently fails to include keys that are omitted entirely from the
basic remapping table since they would map to a non-ASCII character.
Fix this logic by allowing the remapping tables to include null
mappings, which are then elided only at the point of constructing the
C code fragment.
Reported-by: Christian Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Tue, 15 Feb 2022 11:28:57 +0000 (11:28 +0000)]
[console] Treat dead keys as producing their ASCII equivalents
Treat dead keys in target keymaps as producing the closest equivalent
ASCII character, since many of these characters are otherwise
unrepresented on the keyboard.
Michael Brown [Mon, 14 Feb 2022 13:45:59 +0000 (13:45 +0000)]
[console] Support AltGr to access ASCII characters via remapping
Several keyboard layouts define ASCII characters as accessible only
via the AltGr modifier. Add support for this modifier to ensure that
all ASCII characters are accessible.
Experiments suggest that the BIOS console is likely to fail to
generate ASCII characters when the AltGr key is pressed. Work around
this limitation by accepting LShift+RShift (which will definitely
produce an ASCII character) as a synonym for AltGr.
Michael Brown [Mon, 14 Feb 2022 13:22:48 +0000 (13:22 +0000)]
[console] Allow for named keyboard mappings
Separate the concept of a keyboard mapping from a list of remapped
keys, to allow for the possibility of supporting multiple keyboard
mappings at runtime.
Michael Brown [Wed, 9 Feb 2022 15:43:42 +0000 (15:43 +0000)]
[console] Handle remapping of scancode 86
The key with scancode 86 appears in the position between left shift
and Z on a US keyboard, where it typically fails to exist entirely.
Most US keyboard maps define this nonexistent key as generating "\|",
with the notable exception of "loadkeys" which instead reports it as
generating "<>". Both of these mapping choices duplicate keys that
exist elsewhere in the map, which causes problems for our ASCII-based
remapping mechanism.
Work around these quirks by treating the key as generating "\|" with
the high bit set, and making it subject to remapping. Where the BIOS
generates "\|" as expected, this allows us to remap to the correct
ASCII value.
Michael Brown [Sun, 6 Feb 2022 19:33:20 +0000 (19:33 +0000)]
[console] Update genkeymap to work with current databases
Rewrite genkeymap.pl in Python with added sanity checks, and update
the list of keyboard mappings to remove those no longer supported by
the underlying "loadkeys" tool.
Michael Brown [Thu, 10 Feb 2022 11:55:54 +0000 (11:55 +0000)]
[usb] Handle upper/lower case and Ctrl-<key> after applying remapping
Some keyboard layouts (e.g. "fr") swap letter and punctuation keys.
Apply the logic for upper and lower case and for Ctrl-<key> only after
applying remapping, in order to handle these layouts correctly.
Michael Brown [Wed, 9 Feb 2022 16:06:11 +0000 (16:06 +0000)]
[console] Avoid attempting to remap numeric keypad on BIOS console
To minimise code size, our keyboard mapping works on the basis of
allowing the BIOS to convert the keyboard scancode into an ASCII
character and then remapping the ASCII character.
This causes problems with keyboard layouts such as "fr" that swap the
shifted and unshifted digit keys, since the ASCII-based remapping will
spuriously remap the numeric keypad (which produces the same ASCII
values as the digit keys).
Fix by checking that the keyboard scancode is within the range of keys
that vary between keyboard mappings before attempting to remap the
ASCII character.
Michael Brown [Thu, 10 Feb 2022 12:47:25 +0000 (12:47 +0000)]
[efi] Enable IMAGE_GZIP by default for AArch64
AArch64 kernels tend to be distributed as gzip compressed images.
Enable IMAGE_GZIP by default for AArch64 to avoid the need for
uncompressed images to be provided.
Originally-implemented-by: Alessandro Di Stefano <aleskandro@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Wed, 2 Feb 2022 03:26:20 +0000 (03:26 +0000)]
[prefix] Fix use of writable code segment on 486 and earlier CPUs
In real mode, code segments are always writable. In protected mode,
code segments can never be writable. The precise implementation of
this attribute differs between CPU generations, with subtly different
behaviour arising on the transitions from protected mode to real mode.
At the point of transition (when the PE bit is cleared in CR0) the
hidden portion of the %cs descriptor will retain whatever attributes
were in place for the protected-mode code segment, including the fact
that the segment is not writable. The immediately following code will
perform a far control flow transfer (such as ljmp or lret) in order to
load a real-mode value into %cs.
On the Pentium and later CPUs, the retained protected-mode attributes
will be ignored for any accesses via %cs while the CPU is in real
mode. A write via %cs will therefore be allowed even though the
hidden portion of the %cs descriptor still describes a non-writable
segment.
On the 486 and earlier CPUs, the retained protected-mode attributes
will not be ignored for accesses via %cs. A write via %cs will
therefore cause a CPU fault. To obtain normal real-mode behaviour
(i.e. a writable %cs descriptor), special logic is added to the ljmp
instruction that populates the hidden portion of the %cs descriptor
with real-mode attributes when a far jump is executed in real mode.
The result is that writes via %cs will cause a CPU fault until the
first ljmp instruction is executed, after which writes via %cs will be
allowed as expected in real mode.
The transition code in libprefix.S currently uses lret to load a
real-mode value into %cs after clearing the PE bit. Experimentation
shows that only the ljmp instruction will work to load real-mode
attributes into the hidden portion of the %cs descriptor: other far
control flow transfers (such as lret, lcall, or int) do not do so.
When running on a 486 or earlier CPU, this results in code within
libprefix.S running with a non-writable code segment after a mode
transition, which in turn results in a CPU fault when real-mode code
in liba20.S attempts to write to %cs:enable_a20_method.
Fix by constructing and executing an ljmp instruction, to trigger the
relevant descriptor population logic on 486 and earlier CPUs. This
ljmp instruction is constructed on the stack, since the .prefix
section may be executing directly from ROM (or from memory that the
BIOS has write-protected in order to emulate an ISA ROM region) and so
cannot be modified.
Reported-by: Nikolai Zhubr <n-a-zhubr@yandex.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 17 Jan 2022 16:17:17 +0000 (16:17 +0000)]
[efi] Attempt to fetch autoexec script via TFTP
Attempt to fetch the autoexec.ipxe script via TFTP using the PXE base
code protocol installed on the loaded image's device handle, if
present.
This provides a generic alternative to the use of an embedded script
for chainloaded binaries, which is particularly useful in a UEFI
Secure Boot environment since it allows the script to be modified
without the need to sign a new binary.
As a side effect, this also provides a third method for breaking the
PXE chainloading loop (as an alternative to requiring an embedded
script or custom DHCP server configuration).
Michael Brown [Thu, 13 Jan 2022 14:53:36 +0000 (14:53 +0000)]
[uri] Allow for relative URIs that include colons within the path
RFC3986 allows for colons to appear within the path component of a
relative URI, but iPXE will currently parse such URIs incorrectly by
interpreting the text before the colon as the URI scheme.
Fix by checking for valid characters when identifying the URI scheme.
Deliberately deviate from the RFC3986 definition of valid characters
by accepting "_" (which was incorrectly used in the iPXE-specific
"ib_srp" URI scheme and so must be accepted for compatibility with
existing deployments), and by omitting the code to check for
characters that are not used in any URI scheme supported by iPXE.
Reported-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Thu, 13 Jan 2022 14:10:03 +0000 (14:10 +0000)]
[efi] Include Secure Boot Advanced Targeting (SBAT) metadata
SBAT defines an encoding for security generation numbers stored as a
CSV file within a special ".sbat" section in the signed binary. If a
Secure Boot exploit is discovered then the generation number will be
incremented alongside the corresponding fix.
Platforms may then record the minimum generation number required for
any given product. This allows for an efficient revocation mechanism
that consumes minimal flash storage space (in contrast to the DBX
mechanism, which allows for only a single-digit number of revocation
events to ever take place across all possible signed binaries).
Add SBAT metadata to iPXE EFI binaries to support this mechanism.
Michael Brown [Tue, 11 Jan 2022 15:27:14 +0000 (15:27 +0000)]
[efi] Do not align VirtualSize for .reloc and .debug sections
As of commit f1e9e2b ("[efi] Align EFI image sections by page size"),
the VirtualSize fields for the .reloc and .debug sections have been
rounded up to the (4kB) image alignment. This breaks the PE
relocation logic in the UEFI shim, which requires the VirtualSize
field to exactly match the size as recorded in the data directory.
Fix by setting the VirtualSize field to the unaligned size of the
section, as is already done for normal PE sections (i.e. those other
than .reloc and .debug).
Michael Brown [Tue, 4 Jan 2022 13:31:15 +0000 (13:31 +0000)]
[settings] Support formatting UUIDs as little-endian GUIDs
The RFC4122 specification defines UUIDs as being in network byte
order, but an unfortunately significant amount of (mostly Microsoft)
software treats them as having the first three fields in little-endian
byte order.
In an ideal world, any server-side software that compares UUIDs for
equality would perform an endian-insensitive comparison (analogous to
comparing strings for equality using a case-insensitive comparison),
and would therefore not care about byte order differences.
Define a setting type name ":guid" to allow a UUID setting to be
formatted in little-endian order, to simplify interoperability with
server-side software that expects such a formatting.
Michael Brown [Wed, 24 Nov 2021 15:43:46 +0000 (15:43 +0000)]
[efi] Disable EFI watchdog timer when shutting down to boot an OS
The UEFI specification mandates that the EFI watchdog timer should be
disabled by the platform firmware as part of the ExitBootServices()
call, but some platforms (e.g. Hyper-V) are observed to occasionally
forget to do so, resulting in a reboot approximately five minutes
after starting the operating system.
Work around these firmware bugs by disabling the watchdog timer
ourselves.
Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 22 Nov 2021 14:53:33 +0000 (14:53 +0000)]
[efi] Run ExitBootServices shutdown hook at TPL_NOTIFY
On some systems (observed with the Thunderbolt ports on a ThinkPad X1
Extreme Gen3 and a ThinkPad P53), if the IOMMU is enabled then the
system firmware will install an ExitBootServices notification event
that disables bus mastering on the Thunderbolt xHCI controller and all
PCI bridges, and destroys any extant IOMMU mappings. This leaves the
xHCI controller unable to perform any DMA operations.
As described in commit 236299b ("[xhci] Avoid DMA during shutdown if
firmware has disabled bus mastering"), any subsequent DMA operation
attempted by the xHCI controller will end up completing after the
operating system kernel has reenabled bus mastering, resulting in a
DMA operation to an area of memory that the hardware is no longer
permitted to access and, on Windows with the Driver Verifier enabled,
a STOP 0xE6 (DRIVER_VERIFIER_DMA_VIOLATION).
That commit avoids triggering any DMA attempts during the shutdown of
the xHCI controller itself. However, this is not a complete solution
since any attached and opened USB device (e.g. a USB NIC) may
asynchronously trigger DMA attempts that happen to occur after bus
mastering has been disabled but before we reset the xHCI controller.
Avoid this problem by installing our own ExitBootServices notification
event at TPL_NOTIFY, thereby causing it to be invoked before the
firmware's own ExitBootServices notification event that disables bus
mastering.
This unsurprisingly causes the shutdown hook itself to be invoked at
TPL_NOTIFY, which causes a fatal error when later code attempts to
raise the TPL to TPL_CALLBACK (which is a lower TPL). Work around
this problem by redefining the "internal" iPXE TPL to be variable, and
set this internal TPL to TPL_NOTIFY when the shutdown hook is invoked.
Avoid calling into an underlying SNP protocol instance from within our
shutdown hook at TPL_NOTIFY, since the underlying SNP driver may
attempt to raise the TPL to TPL_CALLBACK (which would cause a fatal
error). Failing to shut down the underlying SNP device is safe to do
since the underlying device must, in any case, have installed its own
ExitBootServices hook if any shutdown actions are required.
Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Tue, 23 Nov 2021 15:20:09 +0000 (15:20 +0000)]
[build] Include EFI system partition table entry in isohybrid images
Add the "--uefi" option when invoking isohybrid on an EFI-bootable
image, to create a partition mapping to the EFI system partition
embedded within the ISO image.
This allows the resulting isohybrid image to be booted on UEFI systems
that will not recognise an El Torito boot catalog on a non-CDROM
device.
Originally-fixed-by: Christian Hesse <mail@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 22 Nov 2021 12:50:38 +0000 (12:50 +0000)]
[efi] Raise TPL during driver unload entry point
The efi_unload() function is currently missing the calls to raise and
restore the TPL. This has the side effect of causing iPXE to return
from the driver unload entry point at TPL_CALLBACK, which will cause
unexpected behaviour (typically a system lockup) shortly afterwards.
Fix by adding the missing calls to raise and restore the TPL.
Debugged-by: Petr Borsodi <petr.borsodi@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Sun, 21 Nov 2021 13:27:14 +0000 (13:27 +0000)]
[efi] Modify global system table when wrapping a loaded image
The EFI loaded image protocol allows an image to be provided with a
custom system table, and we currently use this mechanism to wrap any
boot services calls made by the loaded image in order to provide
strace-like debugging via DEBUG=efi_wrap.
The ExitBootServices() call will modify the global system table,
leaving the loaded image using a system table that is no longer
current. When DEBUG=efi_wrap is used, this generally results in the
machine locking up at the point that the loaded operating system calls
ExitBootServices().
Fix by modifying the global EFI system table to point to our wrapper
functions, instead of providing a custom system table via the loaded
image protocol.
projects / thirdparty / ipxe.git / log
