Most TPL manipulation is handled by efi_raise_tpl()/efi_restore_tpl()
pairs. The exceptions are the places where we need to temporarily
drop to a lower TPL in order to allow a timer interrupt to occur.
These currently assume that they are called only from code that is
already running at the internal TPL (generally TPL_CALLBACK). This
assumption is not always correct. In particular, the call from
_efi_start() to efi_driver_reconnect_all() takes place after the SNP
devices have been released and so will be running at the external TPL.
Create an efi_drop_tpl()/efi_undrop_tpl() pair to abstract away the
temporary lowering of the TPL, and ensure that the TPL is always
raised back to its original level rather than being unconditionally
raised to the internal TPL.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When chainloaded from another iPXE, there will be both a virtual
filesystem and a managed network protocol available through which we
could attempt to load autoexec.ipxe.
Try both of these, with the virtual filesystem attempted first so that
an autoexec.ipxe that was explicitly downloaded by the chainloading
iPXE will have the highest priority.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently expect to find either a cached DHCP packet (from a UEFI
PXE boot) or a URI device path (from a UEFI HTTP boot), but not both
simultaneously. When both are present, the cached DHCP packet will
currently override any current working URI that was previously derived
from a URI device path.
Treat the URI device path as being more informative than the cached
DHCP packet by swapping the order in which these are processed.
Leave the boot option device path as being a lower priority than a
cached DHCP packet, since the boot option device path may well refer
to an earlier boot stage.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
For a UEFI HTTP boot, we set the current working URI based on the
loaded image device path. The autoexec.ipxe script will be fetched
from the same directory as the iPXE binary itself.
For a BIOS or UEFI PXE boot, we do not explicitly set a current
working URI, but rely on the fact that registering the cached DHCP
settings block will cause the TFTP code to set the current working URI
to "tftp://${next-server}/". The autoexec.ipxe script will therefore
be fetched from the default directory (which is most probably the root
directory) of the TFTP server.
When using a UEFI shim, the shim will always fetch iPXE from the same
directory as the shim itself. This leads to a somewhat unintuitive
requirement for a UEFI PXE boot: the shim and iPXE must be placed in
the same directory, but the corresponding autoexec.ipxe script must be
placed in the root directory.
As with the loaded image device path for a UEFI HTTP boot, the
existence of a cached DHCP packet gives us a way to construct the URI
of our own binary. We can therefore choose to use this to set the
current working URI, so that the autoexec.ipxe script may be placed in
the same directory as the iPXE binary itself. This is the least
surprising location, and avoids the need for lengthy explanations in
documentation.
Choose to set the current working URI at the point that the cached
DHCP packet is recorded, rather than the point at which it is applied
and registered as a settings block. This avoids some awkward corner
cases (such as failing to find a matching network device for the
DHCPACK), and naturally ensures that we retrieve the next-server
address and filename from the same DHCP packet. We rely on the order
in which cached DHCP packets are recorded to impose a priority
ordering: later packets (e.g. PxeBSACK) will override earlier ones.
To avoid breaking existing setups that do place the autoexec.ipxe
script in the root directory, we modify the fetching logic to first
attempt to retrieve autoexec.ipxe from the current working URI, then
from the root directory of that URI.
As with commit a69afd7 ("[tftp] Use TFTP server URI only if no other
working URI is set"), this is technically a breaking change in
behaviour, but the new behaviour is almost certainly less surprising
than the existing behaviour. Scripts that rely on the current working
URI being set to the root of the TFTP server can use absolute URIs
(i.e. add an initial slash): this is more explicit and will work on
iPXE builds both before and after this change.
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>
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>
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>
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>
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>
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>
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>
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>
The UEFI specification allows GetRNG() to return EFI_NOT_READY, which
is not a particularly helpful error status since there is nothing that
can sensibly be done except to retry immediately.
Retry failed calls to GetRNG() up to a maximum number of attempts.
Debugged-by: Stoo Davies <sdavies@nvidia.com>
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>
Allow DEBUG=efi_wrap to trace various runtime services calls as well
as the existing boot services calls.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 670810b ("[efi] Use standard va_args macros instead of
VA_START() etc") fixed a 32-bit RISC-V build error, but broke the
functionality of the InstallMultipleProtocolInterfaces() and
UninstallMultipleProtocolInterfaces() wrapper functions. GCC does not
automatically check the ABI of the current function when using the
__builtin_va_start() and related macros, and it is therefore necessary
for code to use __builtin_ms_va_start() etc from within functions
marked as EFIAPI.
Since commit 9016f2e ("[efi] Skip including the EDK2 ProcessorBind.h
header for 32-bit RISC-V") has now fixed the original 32-bit RISC-V
build error, we can switch back to using the EDK2 VA_START() etc
macros to obtain the correct behaviour.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some systems (observed with a Lenovo X1) fail to populate the loaded
image device path with a Uri() component when performing a UEFI HTTP
boot, instead creating a broken loaded image device path that
represents a DHCP+TFTP boot that has not actually taken place.
If no URI is found within the loaded image device path, then fall back
to looking for a URI within the current boot option.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
An EFI boot option (stored in a BootXXXX variable) comprises an
EFI_LOAD_OPTION structure, which includes some undefined number of EFI
device paths. (The structure is extremely messy and awkward to parse
in C, but that's par for the course with EFI.)
Add a function to extract the first device path from an EFI load
option, along with wrapper functions to read and extract the first
device path from an EFI boot variable.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The WaitForKeyEx event in EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL is
redundant: by definition it has to signal under exactly the same
conditions as the WaitForKey event in EFI_SIMPLE_TEXT_INPUT_PROTOCOL
and cannot provide any "extended" information since EFI events do not
convey any information beyond their own occurrence.
UEFI keyboard drivers such as Ps2KeyboardDxe and UsbKbDxe invariably
use a single notification function to implement both events. The
console multiplexer driver ConSplitterDxe uses a single notification
function for both events, which ends up checking only the WaitForKey
event on the underlying console devices. (Since all console input is
routed through the console multiplexer, this means that in practice
nothing will ever check the underlying devices' WaitForKeyEx events.)
UEFI console consumers such as the UEFI shell tend to use only the
EFI_SIMPLE_TEXT_INPUT_PROTOCOL instance provided as ConIn in the EFI
system table. With the exception of the UEFI text editor (the "edit"
command in the UEFI shell), almost nothing bothers to open the
EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL instance on the same handle.
The Lenovo ThinkPad T14s Gen 5 has a very peculiar firmware bug.
Enabling the "UEFI Wi-Fi Network Boot" feature in the BIOS setup will
cause the completely unrelated WaitForKeyEx event pointer to be
overwritten with a pointer to a FAT_DIRENT structure representing the
"BOOT" directory in the EFI system partition. This happens with 100%
repeatability. It is not necessary to attempt to boot from Wi-Fi: it
is only necessary to have the feature enabled. The root cause is
unknown, but is presumably an uninitialised pointer or similar
memory-related bug in Lenovo's UEFI Wi-Fi driver.
Work around this Lenovo firmware bug by checking only the WaitForKey
event, ignoring the WaitForKeyEx event even if we will subsequently
use ReadKeyStrokeEx() to read the keypress. Since almost all other
UEFI console consumers use only WaitForKey, this ensures that we will
be using code paths that the firmware vendor is likely to have tested
at least once.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
As with EFI_HANDLE, the EFI headers define EFI_EVENT as a void
pointer, rendering EFI_EVENT compatible with a pointer to itself and
hence guaranteeing that pointer type bugs will be introduced.
Redefine EFI_EVENT as a pointer to an anonymous structure (as we
already do for EFI_HANDLE) to allow the compiler to perform type
checking as expected.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There is nothing in the current versions of the UEFI specification
that limits the TPL at which we may call ConnectController() or
DisconnectController(). However, at least some platforms (observed
with a Lenovo ThinkPad T14s Gen 5) will occasionally and unpredictably
lock up before returning from ConnectController() if called at a TPL
higher than TPL_APPLICATION.
Work around whatever defect is present on these systems by dropping to
the current external TPL for all calls to ConnectController() or
DisconnectController().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The data cache must be invalidated twice for RX DMA buffers: once
before passing ownership to the DMA device (in case the cache happens
to contain dirty data that will be written back at an undefined future
point), and once after receiving ownership from the DMA device (in
case the CPU happens to have speculatively accessed data in the buffer
while it was owned by the hardware).
Only the used portion of the buffer needs to be invalidated after
completion, since we do not care about data within the unused portion.
Update the DMA API to include the used length as an additional
parameter to dma_unmap(), and add the necessary second cache
invalidation pass to the RISC-V DMA API implementation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Cache management operations must generally be performed on virtual
addresses rather than physical addresses.
Change the address parameter in dma_map() to be a virtual address, and
make dma() the API-level primitive instead of dma_phys().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Alignment of initrd lengths is applicable to all Linux kernels, not
just those in the x86 bzImage format.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow an initrd location to be specified in our constructed device
tree via the "linux,initrd-start" and "linux,initrd-end" properties.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Remove the last remaining traces of the concept of a user pointer,
leaving iPXE with a simpler and cleaner memory model that implicitly
assumes that all memory locations can be reached through pointer
dereferences.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The uaccess.h header is no longer required for any code that touches
external ("user") memory, since such memory accesses are now performed
through pointer dereferences. Reduce the number of files including
this header.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Almost all image consumers do not need to modify the content of the
image. Now that the image data is a pointer type (rather than the
opaque userptr_t type), we can rely on the compiler to enforce this at
build time.
Change the .data field to be a const pointer, so that the compiler can
verify that image consumers do not modify the image content. Provide
a transparent .rwdata field for consumers who have a legitimate (and
now explicit) reason to modify the image content.
We do not attempt to impose any runtime restriction on checking
whether or not an image is writable. The only existing instances of
genuinely read-only images are the various unit test images, and it is
acceptable for defective test cases to result in a segfault rather
than a runtime error.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Not all images are allocated via alloc_image(). For example: embedded
images, the static images created to hold a runtime command line, and
the images used by unit tests are all static structures.
Using image_set_cmdline() (via e.g. the "imgargs" command) to set the
command-line arguments of a static image will succeed but will leak
memory, since nothing will ever free the allocated command line.
There are no code paths that can lead to calling image_set_len() on a
static image, but there is no safety check against future code paths
attempting this.
Define a flag IMAGE_STATIC to mark an image as statically allocated,
generalise free_image() to also handle freeing dynamically allocated
portions of static images (such as the command line), and expose
free_image() for use by static images.
Define a related flag IMAGE_STATIC_NAME to mark the name as statically
allocated. Allow a statically allocated name to be replaced with a
dynamically allocated name since this is a potentially valid use case
(e.g. if "imgdecrypt --name <name>" is used on an embedded image).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Since all data transfer buffer contents are now accessible via direct
pointer dereferences, remove the unnecessary abstractions for read and
write operations and create two new data transfer buffer types: a
fixed-size buffer, and a void buffer that records its size but can
never receive non-zero lengths of data. These replace the custom data
buffer types currently implemented for EFI PXE TFTP downloads and for
block device translations.
A new operation xferbuf_detach() is required to take ownership of the
data accumulated in the data transfer buffer, since we no longer rely
on the existence of an independently owned external data pointer for
data transfer buffers allocated via umalloc().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add the ability to reboot to the firmware setup menu (if supported) by
setting the relevant value in the OsIndications variable.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for the possibility of additional reboot types by extending the
reboot() function to use a flags bitmask rather than a single flag.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
GCC 15 defaults to C23, which reserves bool, true, and false as
keywords. Avoid using these as parameter or variable names.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Simplify the framebuffer console drivers by assuming that the raw
framebuffer, character cell array, background picture, and glyph data
are all directly accessible via pointer dereferences.
In particular, this avoids the need to copy each glyph during drawing:
the VESA framebuffer driver can simply return a pointer to the glyph
data stored in the video ROM.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Simplify the block device code by assuming that all read/write buffers
are directly accessible via pointer dereferences.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
