Add support for loading iPXE via a UEFI shim in ISO and USB images.
Since the iPXE shim's default loader filename is currently "ipxe.efi"
for all CPU architectures, at most one architecture within an image
may use a shim. (This limitation should be removed in the next signed
release of the iPXE shim.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
It is unintuitive to have to include an "ifopen" at the start of an
autoexec.ipxe script. Commit efe8126 ("[cachedhcp] Automatically open
network device matching cached DHCPACK") causes the chainloaded device
to be opened automatically, using the cached DHCPACK to identify the
chainloaded device.
In the case of a UEFI HTTP(S) boot, the firmware does not provide
access to the DHCPACK and we are forced to instead extract the very
limited amount of information encoded into the loaded image's device
path.
Mark the device matching the loaded image's device path to be opened
automatically, so that the chainloaded device will be opened in the
same way for both TFTP and HTTP(S) boots.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently set the working URI to "tftp://${next-server}/" whenever
the value of the next-server setting changes.
Many years ago this was required for the default boot sequence, which
would treat the boot filename as a potentially relative URI. Since
commit 481a217 ("[autoboot] Retain initial-slash (if present) when
constructing TFTP URIs"), the default boot sequence has always
constructed an absolute URI.
There is still a valid use case for setting the default working URI
based on the value of next-server: it allows command sequences such as
dhcp && chain ${filename}
or
set next-server 192.168.0.1
chain myscript.ipxe
to work as expected. Note that since "${filename}" may be a relative
path, it is necessary for the current working URI to be the root of
the TFTP server, i.e. "tftp://${next-server}/", rather than the full
path "tftp://${next-server}/${filename}".
In the case of a UEFI HTTP(S) boot, we already have a working URI set
on entry (to be the URI of the iPXE binary itself). Running "dhcp"
would change this current working URI, which is quite unintuitive.
Similarly, once we start executing an image (e.g. a script), the
current working URI is set to the image's own URI, so that relative
URIs may be used in a script to download files relative to the
location of the script itself. Running "dhcp" within the script may
or may not change the current working URI: it will happen to do so
only if the TFTP server address happens to change. This is also
somewhat unintuitive.
Change the behaviour of the TFTP settings applicator to treat the TFTP
server URI as a fallback, to be used only if nothing else has already
set a current working URI. This is technically a breaking change in
behaviour, but the new behaviour is almost certainly much less
surprising than the existing behaviour. (Scripts that do genuinely
expect to acquire a new TFTP server address can use full URIs of the
form "tftp://${next-server}/...": this is more explicit and will work
on iPXE builds both before and after this change.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
TLS defines a mechanism for gracefully closing a connection via a
closure alert. We currently ignore this alert since it is a warning
rather than an error, and warnings are allowed to be ignored.
In almost all cases, a higher-level protocol such as HTTP will already
give us the information required to know when the connection should be
closed. In the very rare case of an HTTPS server that does not send a
Content-Length header and does not close the TCP connection, only the
closure alert indicates that the whole file has been retrieved.
Handle a received closure alert by gracefully closing the connection.
Reported-by: Tuomo Tanskanen <tuomo.tanskanen@est.tech>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
It is unintuitive to have to include an "ifopen" at the start of an
autoexec.ipxe script. Provide a mechanism for upper-layer drivers to
mark a network device to be opened automatically upon registration,
and do so for the device to which the cached DHCPACK is applied.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When searching for a shortcut key, search first from the currently
selected menu item and then from the start of the list.
This allows several ways for a shortcut key to be meaningfully used
multiple times within the same menu. For example, two sections may
have the same shortcut key:
item --key s --gap (S)ection 1
item ...
item ...
item --key s --gap (S)ection 2
item ...
With the above menu, repeated "s" keypresses would cycle through the
sections.
As another example, entries within different sections may have the
same shortcut keys. For example:
item --key d --gap (D)ebian
item --key s debst Debian (s)table release
item --key u debun Debian (u)nstable release
item --key f --gap (F)edora
item --key s fedst Fedora (s)table release
item --key u fedun Fedora (u)nstable release
With the above menu, a shortcut key sequence such as "f", "s" can be
used to select an entry within a specific section, avoiding the need
to choose shortcut keys that are globally unique within the menu.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When multiple shims are present in the system (e.g. in a boot chain
such as UEFI -> iPXE shim -> iPXE -> distro shim -> distro kernel),
there may be more than one installed shim lock protocol.
There is no sensible way to identify which shim lock protocol belongs
to which shim. The shim lock protocol is installed on an anonymous
handle that has no device path, no other form of identifier, and no
connection to any other handle or protocol instance installed by the
shim.
The shim does include some extremely convoluted logic whereby a second
shim will attempt to uninstall a shim lock protocol installed by an
earlier shim. However, this logic is broken: the second shim calls
UninstallProtocolInterface() with the wrong handle and the wrong
protocol interface pointer. This logic error is silently ignored
since shim does not bother to check the return status.
Experience shows that there is unfortunately no point in trying to get
a fix for this upstreamed into shim, or even in raising the issue with
the shim project. We therefore work around the shim bug by calling
all instances of the shim lock protocol, rather than relying on shim
itself to ensure that only one such instance exists.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Support getting the size of a TFTP file via the EFI PXE API, as
required for booting OpenBSD.
Debugged-by: Eric Radman <ericshane@eradman.com>
Tested-by: Eric Radman <ericshane@eradman.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow data to be successfully written (and discarded) to a void data
transfer buffer, rather than throwing an error. This allows a void
data transfer buffer to be used when determining the length of a file
downloaded from a TFTP server that does not support the "tsize" option
defined in RFC 2349.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Record the maximum size required when writing into a data transfer
buffer. This allows the maximum size to be determined even if
allocation fails (e.g. due to a fixed-size buffer or an out-of-memory
condition).
In the case of a fixed-size buffer (which may already be larger than
required), this allows the caller to determine the actual size used
for written data.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use the ipxeboot.tar.gz artifact created by util/gensrvimg in the
"combine" job, and delete the dedicated "netboot" job that currently
creates the same artifact.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
In the spirit of util/genfsimg, create a script util/gensrvimg that
can be used to install compiled iPXE binaries to a directory tree
suitable for copying to a TFTP or HTTP server.
The script detects the CPU architecture for each input file and
installs it into the appropriate subdirectory. Top-level symlinks are
created for each filename, with earlier files taking precedence.
Signed binaries are detected and automatically placed into a Secure
Boot specific subdirectory, thereby allowing the reduced-feature
Secure Boot binaries to coexist with full-feature binaries in a single
installation directory tree. An iPXE shim may be specified and will
be automatically installed alongside the signed binaries, with the
relevant symlink created for each signed binary.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Fix potential memory leak in probe() if initialization fails after
HWRM memory has been allocated.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Add a check for VFs in HWRM backing store related functions to return
immediately as these function are not needed.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
TLS versions 1.2 and earlier define a 4-byte gmt_unix_time field as
part of the 32-byte ClientHello random data block, as a (minimal) form
of protection against a broken random number generator. iPXE has
never set this field to a correct value. Early versions had only
relative timers and so set this field to zero. Commit 5da7123 ("[tls]
Include current time within the client random bytes") did set this
field to the current time, but neglected to use the correct byte
ordering.
TLS version 1.3 (defined in RFC 8446) omits the gmt_unix_time field
completely and just defines the whole 32-byte value as random data.
Simplify the code by using the approach defined in RFC 8446.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
RA contains MTU setting, this is especially needed in some networks
which don't have a a full 1500 MTU link to IPv6 internet. Mostly due
to some providers (such as Microsoft Azure) not having a working pMTUd
setup.
Signed-off-by: Christian I. Nilsson <nikize@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Remove access of deprecated link speed variables for 5750x devices.
Update test flag to include CHIP_P5_PLUS when excluding access of
certain NVM variables.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Fix typo in function declaration. Duplicate declaration of
bnxt_adv_cq_index(). Modified to include function declaration for
bnxt_adv_nq_index().
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Ensure whitespace and indentation adhere to iPXE coding standards.
Fix vertical alignment of multi-line function calls.
No functional changes.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Use port index value retrieved from the firmware when calling
bnxt_hwrm_queue_qportcfg() to retrieve the queue_id. This function
is available for all devices.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
There is no fixed structure for a PXE NBP: the format is just an
opaque block of executable code that is loaded into memory verbatim
and executed by jumping to the first byte. It is consequently
impossible for external code to unambiguously identify a PXE NBP, or
to inspect any metadata about the NBP's functionality.
The first five bytes of an iPXE NBP are already fixed as being an ljmp
instruction that resets the code segment to 0x7c0 and continues
execution from the following byte. We can extend this to include a
minimal header as follows:
Offset Content
------ -------
0 ljmp instruction (0xea)
1-2 ljmp offset (and therefore length of header)
3-4 ljmp segment (0x07c0)
5+ Metadata fields
\_ 5 CPU architecture (0x32=i386, 0x64=x86_64)
\_ 6-7 Magic value (0x18ae)
This is backwards-compatible to existing binaries (which effectively
have zero bytes of metadata following the ljmp instruction), and
allows for future expansion by appending metadata fields (with the
ljmp offset used to determine the overall header length and therefore
the presence of further fields).
In this initial version of the header, define a magic value (used to
differentiate an iPXE NBP from other binaries that happen to start
with an ljmp instruction), and a single-byte value that encodes
whether this binary is built for 32-bit or 64-bit CPUs.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The genfsimg script extracts 16-bit word values from binary files
using the POSIX-compatible subset of options to "od". This subset
does not include the "--endian" option supported by GNU od. The
16-bit values are therefore effectively extracted and compared as byte
sequences. Since all quantities in PE files are little-endian, this
requires all literals to be written in a byte-reversed form.
Switch to implementing get_word() in a marginally less efficient way
(by issuing two separate calls to get_byte()), so that the value
returned is the real 16-bit word value. This allows several of the
constants to be written in a more meaningful form (e.g. "8664" for
x86_64, "aa64" for AArch64, etc).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a job that will automatically create a (draft) release for any
suitable tag, using the build artifacts and release notes already
constructed by earlier jobs. Minimise the logic within the release
job itself, since by definition it cannot be tested on every commit.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The version.txt file is now created by the "version" job (which also
generates the release name, release title, and release notes). Remove
the now-redundant generation of version.txt in the BIOS build job.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for automatic generation of the release name, release title, and
release notes (derived from the relevant section of the changelog).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a rule to construct bin/version.txt containing the version number,
to allow a GitHub Actions workflow to verify that a tagged release
embeds a version number that matches the tag.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Create an archive designed to be extracted to a web server (or TFTP
server) directory, containing the network bootable files such as
undionly.kpxe, ipxe.efi, etc.
Incorporate the iPXE shim binaries, complete with the required
symlinks such as snponly-shim.efi -> shimx64.efi.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Prepare for the possibility of creating ISO and USB disk images that
support UEFI Secure Boot by downloading the Microsoft-signed binaries
from the latest release of the iPXE shim.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently use the ipxe-signer container for the step that combines
the BIOS and UEFI build artifacts to produce the multi-architecture
ISO and USB images.
Switch to using the generic architecture-independent utility toolchain
container, thereby allowing the ipxe-signer container to minimise its
attack surface by removing tools that are not required for the signing
operation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Include the relevant CA certificate in the UEFI Secure Boot build
artifacts. This allows for easy identification of test-signed builds
without having to extract the certificate from the signed binary.
This also eases the process of adding the ephemeral test-signing
certificate to the UEFI trusted certificate list, if a user wants to
test a non-release build with Secure Boot enabled. (The corresponding
private key is deliberately not preserved, to minimise the attack
surface that this would otherwise open up on the user's system.)
Include the commit hash and build architecture within the ephemeral
test-signing certificate's subject name, to make it obvious that the
scope is limited to signing only that single build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a job that takes the bin-x86_64-efi-sb and bin-arm64-efi-sb build
artifacts and signs them for UEFI Secure Boot.
The hardware token containing the trusted signing key is attached to a
dedicated self-hosted GitHub Actions runner. Only tagged release
versions (and commits on the "sbsign" testing branch) will be signed
on this dedicated runner. All other commits will be signed on a
standard GitHub hosted runner using an ephemeral test certificate that
is not trusted for UEFI Secure Boot.
No other work is done as part of the signing job. The iPXE source
code is not even checked out, minimising any opportunity to grant
untrusted code access to the hardware token.
The hardware token password is held as a deployment environment
secret, with the environment being restricted to allow access only for
tagged release versions (and commits on the "sbsign" testing branch)
to provide an additional layer of security.
The signing certificates and intermediate certificates are obtained
from the iPXE Secure Boot CA repository, with the certificate selected
via deployment environment variables.
To minimise hidden state held on the self-hosted runner, the pcscd
service is run via a service container, with the hardware token passed
in via "--devices /dev/bus/usb".
Select the deployment environment name (and hence runner tag) via a
repository variable SBSIGN_ENVIRONMENT, so that forks do not attempt
to start jobs on a non-existent self-hosted runner.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Trigger the daily Coverity Scan submission via a GitHub Actions
schedule (or via a manual workflow run), rather than relying on an
external process pushing to the "coverity_scan" branch.
Since the scheduled workflow will run even on forks of the repository,
add a check to cause the submission to be skipped if the relevant
secret is not configured.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Including USB drivers has some unavoidable side effects. With a BIOS
firmware, attaching the host controller drivers will necessarily
disable the SMM-based USB legacy support which emulates a PS/2
keyboard. With a UEFI firmware, loading the host controller drivers
may disconnect some of the less compliant vendor USB device drivers.
We have historically erred on the side of caution and avoided
including any USB drivers in the all-drivers build. Time has moved
on, USB NICs have become more common (especially for laptops, which
now rarely include physical Ethernet ports), and the UEFI Secure Boot
model makes it prohibitively difficult for users to compile their own
binaries to add support for non-default drivers.
Switch to including USB drivers by default in the all-drivers build.
Provide a fallback build target that matches the existing driver set
(i.e. excluding any USB drivers) and can be built using e.g.:
make bin/ipxe-legacy.iso
make bin-x86_64-efi/ipxe-legacy.efi
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Handle construction of the EFI, Linux, Xen, and VMBus driver build
rules via parserom.pl to ensure consistency. In particular, this
allows those drivers to appear in the DRIVERS_SECBOOT list used to
filter out non-permitted drivers in a Secure Boot build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The Xen netfront driver and the core architecture-independent files
such as xenstore.c and xenbus.c are already marked as permitted for
UEFI Secure Boot, but the x86-specific HVM driver (which attaches to
the PCI device and instantiates the Xen devices) is not.
Review the HVM-specific files and mark them as permitted for UEFI
Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
libslirp introduced a new API for constructing polling lists, to
accommodate Windows platforms where a handle descriptor may be too
large for an int.
Older versions of libslirp do not have the new API calls, and the
older API calls were immediately marked as deprecated, with no
overlap. We would therefore need to use #ifdef and always have some
code that is deliberately not compiled, depending on the version of
libslirp that we find on the user's system. This is highly
undesirable.
Work around this by disabling the deprecation warning (which is what
libslirp itself does for the portions of its code that necessarily
touch the deprecated functions).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently have no PCI bus abstractions for Linux userspace or for
RISC-V SBI. Limit PCI drivers to being included in the all-drivers
build only for BIOS and UEFI platforms.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add DT_ROM() and DT_ID() macros following the pattern for PCI_ROM()
and PCI_ID(), to allow for the possibility of including devicetree
network devices within the "all-drivers" build of iPXE.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The Xen and Hyper-V drivers cannot be included in the Linux userspace
build since they require MMIO accesses. Limit these drivers to being
included in the all-drivers build only for BIOS and UEFI platforms.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Include all three of the Linux-specific network drivers (af_packet,
slirp, and tap) in the all-drivers Linux userspace build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
