Publish the binaries built from commits on the master branch under
stable URLs such as:
https://github.com/ipxe/ipxe/releases/download/rolling/bin/undionly.kpxe
Since filenames such as "ipxe.iso" may exist in each of several build
directories, we implement this as one release tag per build directory.
The GitHub Actions workflow automatically moves the tag to the most
recent commit and overwrites the existing release assets.
One downside of this is that running a local "git log" or similar may
show a large number of uninformative tags of the form "rolling/bin",
"rolling/bin-x86_64-efi", "rolling-arm64-efi", etc, all pointing at
the most recent commit. This clutter may be hidden using:
git config --local log.excludeDecoration refs/tags/rolling/*
To avoid the unintentional creation of rolling release tags on forks,
we skip the whole publication job unless the environment variable
ROLLING_PREFIX is defined.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use util/genfsimg to combine the 64-bit BIOS and all UEFI builds into
a single multi-architecture image in both ISO and USB formats.
Include an editable autoexec.ipxe script (that matches the default
iPXE behaviour) in the USB image, so that users can just mount and
edit this file.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
External files such as embedded scripts or X.509 certificates are not
expected to include source file annotations such as FILE_LICENCE() or
FILE_SECBOOT(). Exclude these external files from the list of
annotated files used to perform licensing and UEFI Secure Boot
eligibility checks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some older distributions (such as RHEL 8) provide their AArch64
kernels as gzip-compressed EFI binaries (with no self-decompressing
EFI stub present). We therefore enable support for gzip images by
default for arm64 EFI builds.
Review the files used to implement the gzip (and zlib) formats and
mark these as permitted for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
An EFI build of iPXE does not directly make use of a flattened device
tree (FDT) itself, but may pass on a device tree that the user chose
to download using the "fdt" command.
Review the simple files used to implement the "fdt" command and mark
these as permitted for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Update to the headers from the latest Xen stable release, and mark all
imported headers as permitted for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The dummy header files in include/bits/*.h are placeholders for
architectures that do not need to define any architecture-specific
functionality in these areas. Mark these trivial files as permitted
for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Our long-standing policy for EFI platforms is that we support invoking
binary executables only via the LoadImage() and StartImage() boot
services calls, so that all security policy decisions are delegated to
the platform firmware.
Most binary executable formats that we support are BIOS-only and
cannot in any case be linked in to an EFI executable. The only
cross-platform format is the generic Linux kernel image format as used
for RISC-V (and potentially also for AArch64).
Mark all files associated with direct loading of a kernel binary as
explicitly forbidden for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Enabling the GDB debugger functionality would provide an immediate and
trivial Secure Boot exploit. Mark all GDB-related files as explicitly
forbidden for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The Realtek driver and its dependencies are cleanly structured, easy
to review, directly maintained, and very well tested. Review these
files and mark them as permitted for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The efi_path_settings[] array includes symbol references to
&ip_setting, &ip6_setting, &dns_setting (and others) that currently
result in IPv4, IPv6, and DNS support being linked in even if disabled
in the build configuration.
Provide weak versions of these symbols to avoid the unconditional
inclusion of these features.
Reported-by: Pavitter Ghotra <pavitterghotra@yahoo.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The EFI SNP/MNP driver wrapper is a trivial layer that exists only to
allow for the separation of "snponly.efi" as a build target. Review
this trivial wrapper and mark it as permitted for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace the bswap instruction with xchgb and roll and change the
module architecture from i486 to i386 to be consistent with the rest
of the project.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use the prebuilt containers from https://github.com/ipxe/ipxe-builder
to build BIOS, SBI, UEFI, and Linux userspace versions of iPXE for all
supported CPU architectures, and to run the Linux userspace test suite
(via valgrind or qemu as applicable).
This reduces the time taken for GitHub CI runs by around 80%, while
increasing the build coverage to include RISC-V SBI, RISC-V UEFI, and
LoongArch64 UEFI, and increasing the test coverage to include running
the Linux userspace test suite on all supported CPU architectures.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When using GitHub Actions with a job container that does not have the
git tools installed, the actions/checkout step will download a
snapshot instead of performing a git clone, and will therefore not
create a .git directory. Allow the GITVERSION variable to be
specified externally, so that the test suite logs can still display
the commit of the build being tested.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Using "git log" to automatically construct the build timestamp is of
minimal value. Reproducible builds should be using SOURCE_DATE_EPOCH
anyway, and for ad hoc builds it is arguable that the time at which
the build was performed is more relevant than the commit timestamp.
(For example, the user may be trying to deliberately use an older
version of iPXE in order to track down a regression via bisection.)
Remove the use of "git log", and thereby remove any requirement for
the git tools to be available at the point of building iPXE.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Using "git describe" to automatically construct the version number has
caused more problems than it has solved. In particular, it causes
errors when building from a shallow clone of the repository, which is
a common scenario in modern automated build environments.
Define the base version number (currently 1.21.1+) as a set of
hardcoded constants within the Makefile, to be updated whenever a
release is made.
It is extremely useful to have the git commit ID present in the
startup banner. End users tend to provide screenshots of failures,
and having the commit ID printed at startup makes it trivial to
identify which version of the code is in use. Identify the git
version (if building from a git tree) by directly reading from
.git/HEAD and associated files. This allows the git commit ID to
potentially be included even if the build environment does not have
the git tools installed.
Use the default shallow clone in the GitHub Actions workflow, since we
no longer require access to the full commit history.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
As done for CROSS_COMPILE in commit 8fc11d8 ("[build] Allow for
per-architecture cross-compilation prefixes"), allow a default sysroot
for each architecture to be specified via the SYSROOT_<arch>
variables. These may then be provided as environment variables,
e.g. using
export SYSROOT_riscv32=/usr/riscv32-linux-gnu/sys-root
This is particularly useful for architectures such as RISC-V where the
64-bit compiler is also used to build 32-bit binaries, since in those
cases the compiler will default to using the 64-bit sysroot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The current usage model for iPXE is that the default configuration is
relatively minimal to reduce code size, with users encouraged to build
from source if necessary to enable additional features. This approach
is somewhat incompatible with the Secure Boot model, which by design
makes it prohibitively difficult for users to use their own compiled
binaries. For published Secure Boot signed binaries to be useful,
they will have to already include all features that the majority of
users will need.
Extend the default configuration for EFI (and other non-BIOS
platforms) to include HTTPS support, framebuffer support, and a
selection of commands and features that are reasonably expected to be
used by large numbers of users.
The default configuration for BIOS platforms is deliberately left
unchanged, since BIOS binaries are typically subject to severe size
constraints.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all console configuration from config/defaults/<platform>.h to
the top-level config/console.h, using indented conditional blocks to
clarify which console types are supported and enabled on each
platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all USB configuration from config/defaults/<platform>.h to the
top-level config/usb.h, using indented conditional blocks to clarify
which options are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all settings source selection from config/defaults/<platform>.h
to the top-level config/settings.h, using indented conditional blocks
to clarify which sources are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Reorder sections within config/general.h so that portions that are
easier to understand and more likely to be modified are towards the
top of the file, with more obscure and less frequently modified
options moved lower down.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move remaining general configuration from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which features are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all SAN boot protocol selection from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which protocols are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all download protocol selection from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which protocols are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all network protocol selection from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which protocols are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all command selection from config/defaults/<platform>.h to the
top-level config/general.h, using indented conditional blocks to
clarify which commands are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move all image type selection from config/defaults/<platform>.h to the
top-level config/general.h, using indented conditional blocks to
clarify which image types are supported and enabled on each platform.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Mark dynamic keyboard map support and the "pciscan", "usbscan", and
"time" commands as permitted for UEFI Secure Boot, on the basis that
these features have previously been present in binaries signed by
Microsoft.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add the Secure Boot permissibility check as a dependency for targets
built with the Secure Boot flag enabled. Attempting to build e.g.
make bin-x86_64-efi-sb/snponly.efi
will now fail unless all files used in the final binary are marked as
being permitted for Secure Boot.
This does not affect the standard build targets (without the "-sb"
suffix on the build directory).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
A past security review identified MD4 and MD5 support as features that
ought to be disabled by default. (There is zero impact on UEFI Secure
Boot itself from having these algorithms enabled: this was just a side
comment in the review.)
As noted in the resulting commit 7f2006a ("[crypto] Disable MD5 as an
OID-identifiable algorithm by default"), the actual MD5 code will
almost certainly still be present in the binary due to its implicit
use by various features. Disabling MD5 support via config/crypto.h
simply removes the OID-identified algorithm, which prevents it from
being used as an explicitly identified algorithm (e.g. in an X.509
certificate digest).
Match the intent of this review comment by marking the OID-identified
algorithms for MD4 and MD5 as forbidden for UEFI Secure Boot.
Extend this to also disable the "md4sum" command and the use of the
md5WithRSAEncryption OID-identified algorithm. (The "md5sum" command
is left enabled for historical reasons, and we have no definition for
md4WithRSAEncryption anyway.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some past security reviews carried out for UEFI Secure Boot signing
submissions have covered specific drivers or functional areas of iPXE.
Mark all of the files comprising these areas as permitted for UEFI
Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Mark all files used in a standard build of bin-x86_64-efi/snponly.efi
as permitted for UEFI Secure Boot. These files represent the core
functionality of iPXE that is guaranteed to have been included in
every binary that was previously subject to a security review and
signed by Microsoft. It is therefore legitimate to assume that at
least these files have already been reviewed to the required standard
multiple times.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Tighten up the regular expression used to check for FILE_LICENCE() and
FILE_SECBOOT() declarations: ensure that they appear at the start of a
line (with optional whitespace) and include the expected opening
parenthesis.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The third-party 802.11 stack and NFS protocol code are known to
include multiple potential vulnerabilities and are explicitly
forbidden from being included in Secure Boot signed builds. This is
currently handled at the per-directory level by defining a list of
source directories (SRCDIRS_INSEC) that are to be excluded from Secure
Boot builds.
Annotate all files in these directories with FILE_SECBOOT() to convey
this information to the new per-file Secure Boot permissibility check,
and remove the old separation between SRCDIRS and SRCDIRS_INSEC.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Not all files within the iPXE codebase are allowed to be included in
UEFI Secure Boot signed builds.
Following the pattern used by the existing FILE_LICENCE() macro and
licensing check: define a FILE_SECBOOT() macro that can be used to
declare a file as being permitted (or forbidden) in a UEFI Secure Boot
signed build, and a corresponding build target to perform the check.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Treat each delayed transmission as a pending operation, so that the
"sync" command can be used to ensure that all delayed packets have
been transmitted.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Gather some basic statistics on TCP connections to allow out-of-order
packets and duplicate packets to be observed even in non-debug builds.
Report these statistics via the existing "ipstat" command, rather than
introducing a separate "tcpstat" command, on the basis that we do not
need the additional overhead of a separate command.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 2d180ce ("[tcp] Update maximum window size to 2MB") increased
the TCP window size to avoid filling the TCP window on typical modern
links.
The total heap size is only 512kB. Given that RX I/O buffers are
typically subject to alignment constraints, it is plausible that we
may be able to actually buffer only 256kB of data before having to
discard queued out-of-order packets.
On a low latency network, this behaviour is not a problem: the sender
will rapidly retransmit the lost or discarded packets. On a high
latency network, the sender's congestion control algorithm will end up
calculating a congestion window that is substantially smaller than our
advertised 2MB, which will result in a drastic reduction in actual
throughput.
We do not want to increase the heap size arbitrarily, since we still
have the constraint that memory used by iPXE may be permanently lost
to the operating system (depending on how the operating system is
booted). However, the cost of keeping the heap size down to 512kB is
no longer acceptable given that large downloads over high-speed
wide-area networks are now routine.
Increase the heap size from 512kB to 4MB. This should be sufficient
to hold an entire 2MB TCP window for a single connection under most
sensible conditions. For example:
* 1460-byte MSS => 1436 packets => 2872kB of 2kB RX I/O buffers
* 8960-byte MSS => 234 packets => 3744kB of 16kB RX I/O buffers
The notable exception is that of a network where jumbo frames are in
use, but the TCP connection ends up using a standard 1460-byte MSS.
If this is found to be an issue in practice, then one possible
solution would be to shrink (or reallocate) I/O buffers for
out-of-order queued data.
Experimentation shows that before this change, an induced latency of
25ms (representative of a typical connection to a public cloud
provider) would cause the download speed to vary unpredictably between
2MB/s and 25MB/s. After this change, the speed in this test scenario
remains consistently high at 25MB/s.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We will currently enqueue (rather than discard) retransmitted packets
that lie immediately before the current receive window. These packets
will be harmlessly discarded when the receive queue is processed
immediately afterwards, but cause confusion when attempting to debug
TCP performance issues.
Fix by adjusting the comparison so that packets that lie immediately
before the receive window will be discarded immediately and never
enqueued.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a fault-injection mechanism that allows an arbitrary delay
(configured via config/fault.h) to be added to any packets transmitted
via the neighbour resolution mechanism, as a way of reproducing
symptoms that occur only on high-latency connections such as a
satellite uplink.
The neighbour discovery mechanism is not a natural conceptual fit for
this artficial delay, since neighbour discovery has nothing to do with
transmit latency. However, the neighbour discovery mechanism happens
to already include a deferred transmission queue that can be (ab)used
to implement this artifical delay in a minimally intrusive way. In
particular, there is zero code size impact on a standard build with no
artificial delay configured.
Implementing the delay only for packets transmitted via neighbour
resolution has the side effect that broadcast packets (such as DHCP
and ARP) are unaffected. This is likely in practice to produce a
better emulation of a high-latency uplink scenario, where local
network traffic such as DHCP and ARP will complete quickly and only
the subsequent TCP/UDP traffic will experience delays.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
