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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Use the discovery protocol pointer field (rather than the running
state of the discovery timer) to determine whether or not neighbour
discovery is ongoing, as a precursor to allowing the timer to be
(ab)used for adding deliberate latency to transmitted packets.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The API for neighbour_tx() allows for an explicit source link-layer
address, but this will be ignored if the packet is deferred for
transmission after completion of neighbour discovery. The network
device's own link-layer address will always be used when sending
neighbour discovery packets, and when sending any deferred packets
after discovery completes.
All callers pass in the network device's own link-layer address as the
source address anyway, and so this explicit source link-layer address
is never used for any meaningful purpose.
Simplify the neighbour_tx() API by removing the ability to pass in an
explicit source link-layer address.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Ensure that zero-length big integer literals are treated as containing
a zero value. Avoid tests on every big integer arithmetic operation
by ensuring that bigint_required_size() always returns a non-zero
value: the zero-length tests can therefore be restricted to only
bigint_init() and bigint_done().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a public-key algorithm to the definition of the "ecPublicKey"
OID-identified algorithm, and move this definition to ecdsa.c to avoid
unconditionally dragging in ECDSA support.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ECDSA requires the ability to add two arbitrary curve points, either
of which may legitimately be the point at infinity.
Update the API so that curves must choose an explicit affine
representation for the point at infinity, and provide a method to test
for this representation. Multiplication and addition will now allow
this representation to be provided as an input, and will not fail if
the result is the point at infinity. Callers must explicitly check
for the point at infinity where needed (e.g. after computing the ECDHE
shared secret curve point).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ECDSA signature values and private keys are fixed-length unsigned
integers modulo N (the group order of the elliptic curve) and are
therefore most naturally represented in ASN.1 using ASN1_OCTET_STRING.
Private key representations do use ASN1_OCTET_STRING, but signature
values tend to use ASN1_INTEGER, which adds no value but does ensure
that the encoding becomes variable-length and requires handling a
pointless extra zero byte if the MSB of the unsigned value happens to
be set.
RSA also makes use of ASN1_INTEGER for modulus and exponent values.
Generalise the existing rsa_parse_integer() to asn1_enter_unsigned()
to allow this code to be reused for ECDSA.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ECDSA verification requires the ability to add two arbitrary curve
points (as well as the ability to multiply a curve point by a scalar).
Add an elliptic curve method to perform arbitrary point addition.
Pass in curve points as affine coordinates: this will require some
redundant conversions between affine coorfinates and the internal
representation as projective coordinates in Montgomery form, but keeps
the API as simple as possible. Since we do not expect to perform a
high volume of ECDSA signature verifications, these redundant
calculations are an acceptable cost for keeping the code simple.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ECDSA requires knowledge of the group order of the base point, and is
defined only for curves with a prime group order (e.g. the NIST
curves).
Add the group order as an explicit property of an elliptic curve, and
add tests to verify that the order is correct.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add the generator base point as an explicit property of an elliptic
curve, and remove the ability to pass a NULL to elliptic_multiply() to
imply the use of the generator base point.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Once an HTTP download has started (i.e. once all request headers have
been sent), we generally have no more data to transmit. If an HTTP
connection dies silently (e.g. due to a network failure, a NIC driver
bug, or a server crash) then there is no mechanism that will currently
detect this situation by default.
We do send TCP keep-alives (to maintain state in intermediate routers
and firewalls), but we do not attempt to elicit a response from the
server. RFC 9293 explicitly states that the absence of a response to
a TCP keep-alive probe must not be interpreted as indicating a dead
connection, since TCP cannot guarantee reliable delivery of packets
that do not advance the sequence number.
Scripts may use the "--timeout" option to impose an overall time limit
on downloads, but this mechanism is off by default and requires
additional thought and configuration by the user (which goes against
iPXE's general philosophy of being as automatic as possible).
Add an idle connection watchdog timer which will cause the HTTP
download to abort after 120 seconds of inactivity. Activity is
defined as an I/O buffer being delivered to the HTTP transaction's
upstream data transfer interface.
Downloads over HTTPS may experience a substantial delay until the
first recorded activity, since all TLS negotiation (including
cross-chained certificate downloads and OCSP checks) must complete
before any application data can be sent. We choose to not reset the
watchdog timer during TLS negotiation, on the basis that 120 seconds
is already an unreasonably long time for a TLS negotiation to take to
complete. If necessary, resetting the watchdog timer could be
accomplished by having the TLS layer deliver zero-length I/O buffers
(via xfer_seek()) to indicate forward progress being made.
When using PeerDist content encoding, the downloaded content
information is not passed through to the content-decoded interface and
so will not be classed as activity. Any activity in the individual
PeerDist block downloads (either from peers or as range requests from
the origin server) will be classed as activity in the overall
download, since individual block downloads do not buffer data but
instead pass it through directly via the PeerDist download
multiplexer.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Elliptic curves in X.509 certificates are identified via the
id-ecPublicKey object identifier (1.2.840.10045.2.1), with the
specific elliptic curve identified via a second OID in the algorithm
parameters.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Now that public-key algorithms use ASN.1 builders to dynamically
allocate the output data, there is no further need for callers to be
able to determine the maximum output length.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Signature values in ASN.1 tend to be encoded as bit strings rather
than octet strings. In practice, no existent signature scheme uses a
non-integral number of bytes.
Switch to using a standard ASN.1 cursor to hold signature values, to
simplify consuming code. Restructure the API to treat entering an
ASN.1 bit string in the same way as entering any other ASN.1 type.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On some systems (observed on an AWS m8g.medium instance in eu-west-2),
the UEFI firmware fails to enumerate some of the underlying hardware
devices. On these systems, we cannot comply with the UEFI device
model by adding our SNP device as a child of the hardware device and
appending to the parent hardware device path, since no parent hardware
device has been created.
Work around these systems by allowing for the creation of SNP devices
with no parent device.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On some systems (observed on an AWS m8g.medium instance in eu-west-2),
the UEFI firmware omits the PCI host bridge drivers for all but the
first PCI bus. The observable result is that any devices on other PCI
buses (such as the ENA network device) are not enumerated by the UEFI
firmware and are therefore unusable by iPXE.
Support these systems by switching to using PCIAPI_CLOUD for EFI cloud
builds, trying the EFI PCI I/O API first and falling back to direct
access (via ECAM) for devices that the UEFI firmware has failed to
enumerate itself.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
