The all-drivers targets (e.g. ipxe.efi) cannot currently be used in a
Secure Boot build since the permissibility check will (correctly) fail
due to the inclusion of non-permitted drivers.
In a Secure Boot build, filter the all-drivers list to include only
the subset of drivers that are marked as being permitted for UEFI
Secure Boot.
Note that this automatic filter is a convenience shortcut: it is not
the enforcement mechanism. The filter exists only to provide a
meaningful definition for the otherwise unusable all-drivers targets
in Secure Boot builds. The enforcement mechanism remains the
permissiblity check introduced in commit 1d5b1d9 ("[build] Fail Secure
Boot builds unless all files are permitted").
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Include Xen and Hyper-V support in the all-drivers build by dragging
in the netfront and netvsc drivers, since these are the functional
drivers that provide network interfaces.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Parse USB_ROM() lines to create build rules to allow for e.g.
make bin/smsc9500.usb
(i.e. using the driver name as a build target, rather than having to
use the source file name).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Include the underlying bus type (e.g. "pci" or "isa") within the lists
constructed to describe the available drivers, to allow for the
possibility that platforms may want to define a platform-specific
subset of drivers to be present in the all-drivers build. For
example, non-x86 platforms such as RISC-V SBI do not need to include
the ISA network drivers since the corresponding hardware cannot ever
be present on a RISC-V system.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add USB_ROM() and USB_ID() macros following the pattern for PCI_ROM()
and PCI_ID(), to allow for the possibility of including USB network
devices within the "all-drivers" build of iPXE.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Detailed experiments show that at least one model of 386 CPU has a
previously undocumented errata in the "popal" instruction.
Specifically: when the stack-address size is 16 bits and the operand
size is 32 bits, the "popal" instruction will erroneously load the
high 16 bits of %esp from the value stored on the stack.
The "movl -20(%esp), %esp" instruction near the end of virt_call()
currently relies on the assumption that the high 16 bits of %esp will
already be zero, since they were set to zero by the "movzwl %bp, %esp"
instruction at the end of prot_to_real() and will not have been
subsequently modified by the "popal". This 386 CPU errata invalidates
that assumption, with the result that we end up loading the stack
pointer from an essentially undefined memory location.
Fix by inserting a "movzwl %sp, %esp" after the "popal" to explicitly
zero the high 16 bits of %esp.
Inserting this instruction also happens to work around another (known
and documented) errata in the 386, in which the CPU may malfunction if
"popal" is followed immediately by an instruction that uses a base
address register to form an effective address.
Debugged-by: Jaromir Capik <jaromir.capik@email.cz>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The original implementation in commit 943b300 ("[syslog] Add basic
support for encrypted syslog via TLS") was based on examples found in
the rsyslog documentation rather than on RFC 5425, and unfortunately
used the default syslog port number 514 rather than the syslog-tls
port number 6514 defined in the RFC.
Extend parsing of the syslog server name to allow for an optional port
number (in the relatively intuitive format "server[:port]"). Retain
the existing (and incorrect) default port number to avoid breaking
backwards compatibility with existing setups.
Reported-by: Christian Nilsson <nikize@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The initial code contribution from Loongson defined ASM_NO_PREFIX as
being "a" for this architecture. This seems to result in small values
such as error line numbers being rendered as "$r0, <value>" rather
than just "<value>".
This seems to hit an undocumented behaviour path in the GNU assembler.
For some reason ".long $r0" is not treated as a syntax error but will
instead be treated as a zero value. The net effect is therefore that
an extra zero value is emitted before the line number in the einfo
structure, which in turn causes the error information parser to see
all source code line numbers as zero. (The overall structure remains
valid since the length and all string offsets are encoded within the
structure itself, so nothing breaks when a spurious extra integer
field is appended.)
Fix by setting ASM_NO_PREFIX to the empty string (as for RISC-V),
since there are no literal value prefixes anyway in LoongArch64
assembly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some systems (observed on a Dell C6615) fail to correctly populate the
subordinate PCI bus number on some PCI bridges. We do not currently
guard against this behaviour, causing us to subsequently scan through
a huge expanse of the PCI bus:dev.fn address range.
Fix by ignoring the subordinate bus number if it is lower than the
bridge's own bus number.
Reported-by: Anisse Astier <an.astier@criteo.com>
Reported-by: Ahmad Mahagna <ahmhad@nvidia.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Reduce the overhead of PCI configuration space accesses (and the
verbosity of debug messages) by caching the identified PCI root bridge
I/O protocol handle for the most recently accessed PCI device.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
MS-CHAPv2 and the underlying DES algorithm are cryptographically
obsolete, but still relatively widely used. There is no impact to
UEFI Secure Boot from using these obsolete algorithms: the only
untrusted inputs are the username, password, and received network
packets, and all of these are thoroughly validated before use.
Review these files and mark them as permitted for UEFI Secure Boot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The core/version.c file is built into multiple objects (since it
incorporates the build target name such as "snponly.efi"), and is
handled separately from the standard build rules.
Add the missing line (taken from the standard build rules template) to
ensure that the dependency file is itself updated when the
dependencies change.
In particular, this ensures that the dependencies for core/version.c
will be updated when switching named configurations.
Reported-by: Christian I. Nilsson <ChristianN@2PintSoftware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit dee71adda ("[build] Exclude external files from annotation
checks") excluded local top-level config headers from annotation
checks, but not local named config headers.
These are generated if missing when building with CONFIG= and will
most of the time be empty. Exclude these files from the list of
annotated files used to perform licensing and UEFI Secure Boot
eligibility checks.
Non-local named config headers intended to be used with Secure Boot
can be annotated with FILE_SECBOOT().
Signed-off-by: Christian I. Nilsson <ChristianN@2PintSoftware.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
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>
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>
