[libc] Redefine low 8 bits of error code as "platform error code"
The low 8 bits of an iPXE error code are currently defined as the
closest equivalent PXE error code. Generalise this scheme to
platforms other than PC-BIOS by extending this definition to "closest
equivalent platform error code". This allows for the possibility of
returning meaningful errors via EFI APIs.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Abstract out the ability to reboot the system to a separate reboot()
function (with platform-specific implementations), add an EFI
implementation, and make the existing "reboot" command available under
EFI.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Add our own EFI_LOAD_FILE_PROTOCOL implementation
When iPXE is used as a UEFI driver, the UEFI PXE base code currently
provides the TCP/IP stack, network protocols, and user interface.
This represents a substantial downgrade from the standard BIOS iPXE
user experience.
Fix by installing our own EFI_LOAD_FILE_PROTOCOL implementation which
initiates the standard iPXE boot procedure. This upgrades the UEFI
iPXE user experience to match the standard BIOS iPXE user experience.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Expose downloaded images via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
Expose iPXE's images as a UEFI file system, allowing the booted image
to access all images downloaded by iPXE.
This functionality is complementary to the custom iPXE download
protocol. The iPXE download protocol allows a booted image to utilise
iPXE to download arbitrary URIs, but requires the booted image to
specifically support the custom iPXE download protocol. The new
functionality limits the booted image to accessing only files that
were already downloaded by iPXE (e.g. as part of a script), but can
work with any generic UEFI image (e.g. the UEFI shell). Both
protocols are provided simultaneously, and are attached to the SNP
device handle.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tftp] Allow TFTP block size to be controlled via the PXE TFTP API
The PXE TFTP API allows the caller to request a particular TFTP block
size. Since mid-2008, iPXE has appended a "?blksize=xxx" parameter to
the TFTP URI constructed internally; nothing has ever parsed this
parameter. Nobody seems to have cared that this parameter has been
ignored for almost five years.
Fix by using xfer_window(), which provides a fairly natural way to
convey the block size information from the PXE TFTP API to the TFTP
protocol layer.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[netdevice] Add vlan_tag() to get the VLAN tag of a network device
The iBFT has a VLAN field that should be filled in. Add the
vlan_tag() function to extract the VLAN tag of a network device.
Since VLAN support is optional, define a weak function that returns 0
when iPXE is built without VLAN support.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tls] Concatenate received non-data records before processing
Allow non-data records to be split across multiple received I/O
buffers, to accommodate large certificate chains.
Reported-by: Nicola Volpini <Nicola.Volpini@kambi.com>
Tested-by: Nicola Volpini <Nicola.Volpini@kambi.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[serial] Don't enable serial console without serial support
serial_console_init() would enable serial console support without
knowing if the serial driver succeeded or not. As a result, the
serial console would interfere with a normal keyboard on a system
lacking serial support.
Reported-by: Jan ONDREJ (SAL) <ondrejj(at)salstar.sk>
Signed-off-by: Shao Miller <sha0.miller@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tls] Split received records over multiple I/O buffers
TLS servers are not obliged to implement the RFC3546 maximum fragment
length extension, and many common servers (including OpenSSL, as used
in Apache's mod_ssl) do not do so. iPXE may therefore have to cope
with TLS records of up to 16kB. Allocations for 16kB have a
non-negligible chance of failing, causing the TLS connection to abort.
Fix by maintaining the received record as a linked list of I/O
buffers, rather than a single contiguous buffer. To reduce memory
pressure, we also decrypt in situ, and deliver the decrypted data via
xfer_deliver_iob() rather than xfer_deliver_raw().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Use a generic setting's own type as its default type
When fetching a named setting using a name that does not explicitly
specify a type, default to using the type stored when the setting was
created, rather than always defaulting to "string". This allows the
behaviour of user-defined settings to match the behaviour of
predefined settings (which have a sensible default type).
For example:
set server:ipv4 192.168.0.1
echo ${server}
will now print "192.168.0.1", rather than trying to print out the raw
IPv4 address bytes as a string.
The downside of this change is that existing tricks for printing
special characters within scripts may require (backwards-compatible)
modification. For example, the "clear screen" sequence:
set esc:hex 1b
set cls ${esc}[2J
echo ${cls}
will now have to become
set esc:hex 1b
set cls ${esc:string}[2J # Must now explicitly specify ":string"
echo ${cls}
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ipoib] Expose Ethernet-compatible eIPoIB link-layer addresses and headers
Almost all clients of the raw-packet interfaces (UNDI and SNP) can
handle only Ethernet link layers. Expose an Ethernet-compatible link
layer to local clients, while remaining compatible with IPoIB on the
wire. This requires manipulation of ARP (but not DHCP) packets within
the IPoIB driver.
This is ugly, but it's the only viable way to allow IPoIB devices to
be driven via the raw-packet interfaces.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[malloc] Allow allocation of memory with a specified alignment offset
Allow for allocation of memory blocks having a specified offset from a
specified physical alignment, such as being 12 bytes before a 2kB
boundary.
Signed-off-by: Michael Brown <mcb30@ipxe.org>