aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* WIP - refactoredshim4Michael Brown2023-05-233-80/+142
|
* WIP - tidyingMichael Brown2023-05-232-44/+56
|
* WIP - first successful sbat hackMichael Brown2023-05-233-1/+59
|
* [efi] Add "shim" commandMichael Brown2023-05-224-0/+117
| | | | | | | | | | | | Allow a shim to be used to facilitate booting a kernel using a script such as: kernel /images/vmlinuz console=ttyS0,115200n8 initrd /images/initrd.img shim /images/shimx64.efi boot Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for executing images via a shimMichael Brown2023-05-228-3/+413
| | | | | | | | | | | | | | | | | | | | | | | Add support for using a shim as a helper to execute an EFI image. When a shim has been specified via shim(), the shim image will be passed to LoadImage() instead of the selected EFI image and the command line will be prepended with the name of the selected EFI image. The selected EFI image will be accessible to the shim via the virtual filesystem as a hidden file. Reduce the Secure Boot attack surface by removing, where possible, the spurious requirement for a third party second stage loader binary such as GRUB to be used solely in order to call the "shim lock protocol" entry point. Do not install the EFI PXE APIs when using a shim, since if shim finds EFI_PXE_BASE_CODE_PROTOCOL on the loaded image's device handle then it will attempt to download files afresh instead of using the files already downloaded by iPXE and exposed via the EFI_SIMPLE_FILE_SYSTEM protocol. (Experience shows that there is no point in trying to get a fix for this upstreamed into shim.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add definitions for the UEFI shim lock protocolMichael Brown2023-05-224-0/+39
| | | | | | | | | The UEFI shim includes a "shim lock protocol" that can be used by a third party second stage loader such as GRUB to verify a kernel image. Add definitions for the relevant portions of this protocol interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_asprintf() and efi_vasprintf()Michael Brown2023-05-224-10/+53
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Generalise concept of selected imageMichael Brown2023-05-176-50/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most image flags are independent values: any combination of flags may be set for any image, and the flags for one image are independent of the flags for any other image. The "selected" flag does not follow this pattern: at most one image may be marked as selected at any time. When invoking a kernel via the UEFI shim, there will be multiple "special" images: the selected kernel itself, the shim image, and potentially a shim-signed GRUB binary to be used as a crutch to assist shim in loading the kernel (since current versions of the UEFI shim are not capable of directly loading a Linux kernel). Remove the "selected" image flag and replace it with a general concept of an image tag with the same semantics: a given tag may be assigned to at most one image, an image may be found by its tag only while the image is currently registered, and a tag will survive unregistration and reregistration of an image (if it has not already been assigned to a new image). For visual consistency, also replace the current image pointer with a current image tag. The image pointer stored within the image tag holds only a weak reference to the image, since the selection of an image should not prevent that image from being freed. (The strong reference to the currently executing image is held locally within the execution scope of image_exec(), and is logically separate from the current image pointer.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Attempt to detect EFI images that fail Secure Boot verificationMichael Brown2023-05-171-5/+71
| | | | | | | | | | | | An EFI image that is rejected by LoadImage() due to failing Secure Boot verification is still an EFI image. Unfortunately, the extremely broken UEFI Secure Boot model provides no way for us to unambiguously determine that a valid EFI executable image was rejected only because it failed signature verification. We must therefore use heuristics to guess whether not an image that was rejected by LoadImage() could still be loaded via a separate PE loader such as the UEFI shim. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ci] Work around Ubuntu packaging metadata issuesMichael Brown2023-05-151-1/+2
| | | | | | | | | | | | | The libc6-dbg:i386 package has spontaneously started failing to install from the Azure package repositories used by the GitHub Actions runners, with the somewhat recalcitrant error message: libc6:i386: Depends: libgcc-s1:i386 but it is not going to be installed Work around this unexplained issue by explicitly requesting installation of the libgcc-s1:i386 package. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow currently selected image to be opened as "grub*.efi"Michael Brown2023-05-051-0/+11
| | | | | | | | | | | | | | | | | | | | | Versions 15.4 and earlier of the UEFI shim are incapable of correctly parsing the command line in order to extract the second stage loader filename, and will always attempt to load "grubx64.efi" or equivalent. Versions 15.3 and later of the UEFI shim are currently incapable of loading a Linux kernel directly anyway, since the kernel does not include SBAT metadata. These versions will require a genuine shim-signed GRUB binary to be used as a crutch to assist shim in loading a Linux kernel. This leaves versions 15.2 and earlier of the UEFI shim (as currently used in e.g. RHEL7) as being capable of directly loading a Linux kernel, but incorrectly attempting to load it using the filename "grubx64.efi" or equivalent. To support the bugs in these older versions of the UEFI shim, allow the currently selected image to be opened via any filename of the form "grub*.efi". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow currently executing image to be opened via virtual filesystemMichael Brown2023-05-051-0/+10
| | | | | | | | | | | | | When invoking a kernel via the UEFI shim, the kernel image must be accessible via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL but must not be present in the magic initrd constructed from all registered images. Re-register a currently executing EFI image and mark it as hidden, thereby allowing it to be accessed via the virtual filesystem exposed via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL without appearing in the magic initrd contents. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Allow for images to be hidden from lists of all imagesMichael Brown2023-05-055-19/+39
| | | | | | | | | | | | | | | When invoking a kernel via the UEFI shim, the kernel (and potentially also a helper binary such as GRUB) must be accessible via the virtual filesystem exposed via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL but must not be present in the magic initrd constructed from all registered images. Allow for images to be flagged as hidden, which will cause them to be excluded from API-level lists of all images such as the virtual filesystem directory contents, the magic initrd, or the Multiboot module list. Hidden images remain visible to iPXE commands including "imgstat", which will show a "[HIDDEN]" flag for such images. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Show original filenames in debug messagesMichael Brown2023-05-051-8/+16
| | | | | | | Show the original filename as used by the consumer when calling our EFI_SIMPLE_FILE_SYSTEM_PROTOCOL's Open() method. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow downloaded images to take precedence over constructed filesMichael Brown2023-05-051-22/+33
| | | | | | | | | Try searching for a matching registered image before checking for fixed filenames (such as "initrd.magic" for the dynamically generated magic initrd file). This minimises surprise by ensuring that an explicitly downloaded image will always be used verbatim. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for sections to be excluded from the generated PE fileMichael Brown2023-04-101-6/+17
| | | | | | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) include a bzImage header within a section starting at offset zero, with the PE header effectively occupying unused space within this section. This section should not appear as a named section in the resulting PE file. Allow for the existence of hidden sections that do not result in a section header being written to the PE file. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow elf2efi to be used for hybrid binariesMichael Brown2023-04-101-6/+27
| | | | | | | | | | | | | | | | Hybrid 32-bit BIOS and 64-bit UEFI binaries (such as wimboot) may include R_X86_64_32 relocation records for the 32-bit BIOS portions. These should be ignored when generating PE relocation records, since they apply only to code that cannot be executed within the context of the 64-bit UEFI binary, and creating a 4-byte relocation record is invalid in a binary that may be relocated anywhere within the 64-bit address space (see commit 907cffb "[efi] Disallow R_X86_64_32 relocations"). Add a "--hybrid" option to elf2efi, which will cause R_X86_64_32 relocation records to be silently discarded. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Shrink size of data directory in PE headerMichael Brown2023-04-101-4/+13
| | | | | | | | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) require the PE header to be kept as small as possible, since the bzImage header starts at a fixed offset 0x1f1. The EFI_IMAGE_OPTIONAL_HEADER structures in PeImage.h define an optional header containing 16 data directory entries, of which the last eight are unused in binaries that we create. Shrink the data directory to contain only the first eight entries, to minimise the overall size of the PE header. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove redundant zero padding in PE headerMichael Brown2023-04-101-1/+0
| | | | | | | | | | | | | | | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) require the PE header to be kept as small as possible, since the bzImage header starts at a fixed offset 0x1f1. The PE header currently includes 128 bytes of zero padding between the DOS and NT header portions. This padding has been present since commit 81d92c6 ("[efi] Add EFI image format and basic runtime environment") first added support for EFI images in iPXE, and was included on the basis of matching the observed behaviour of the Microsoft toolchain. There appears to be no requirement for this padding to exist: EDK2 binaries built with gcc include only 64 bytes of zero padding, Linux kernel binaries include 66 bytes of non-zero padding, and wimboot binaries include no padding at all. Remove the unnecessary padding between the DOS and NT header portions to minimise the overall size of the PE header. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Handle fragmented handshake recordsMichael Brown2023-03-302-18/+26
| | | | | Originally-implemented-by: Christopher Schenk <christopher@cschenk.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Pass I/O buffer to received record handlersMichael Brown2023-03-301-58/+98
| | | | | | | | Prepare for the possibility that a record handler may choose not to consume the entire record by passing the I/O buffer and requiring the handler to mark consumed data using iob_pull(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Clean up change cipher spec record handlingMichael Brown2023-03-302-4/+18
| | | | | | | Define and use data structures and constants for the (single-byte) change cipher spec records. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Claim fixed device paths by uninstalling device path protocolinitrdMichael Brown2023-03-151-122/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | As documented in commits 6a004be ("[efi] Support the initrd autodetection mechanism in newer Linux kernels") and 04e60a2 ("[efi] Omit EFI_LOAD_FILE2_PROTOCOL for a zero-length initrd"), the choice in Linux of using a fixed device path requires bootloaders to allow for the fact that a previous bootloader may have already installed a handle with the fixed device path. We currently deal with this situation by reusing the existing handle, replacing the EFI_LOAD_FILE2_PROTOCOL instance with our own. Simplify the code by instead uninstalling the EFI_DEVICE_PATH_PROTOCOL instance from the existing handle (if present), thereby allowing the creation of a new handle to succeed. Create the new handle only if we have a non-empty initrd to provide. This works around bugs in bootloaders such as the systemd EFI stub that fail to allow for the existence of multiple-bootloader chains. (The workaround is not comprehensive: if the user has downloaded other images in iPXE before invoking the systemd Unified Kernel Image (UKI), then the systemd EFI stub will still crash and burn since it fails to allow for the fact that a previous bootloader has already installed a handle with the fixed device path.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add workaround for I210 reset hardware bugsMatt Parrella2023-03-142-2/+24
| | | | | | | | | | | | | | | | | | The Intel I210's packet buffer size registers reset only on power up, not when a reset signal is asserted. This can lead to the inability to pass traffic in the event that the DMA TX Maximum Packet Size (which does reset to its default value on reset) is bigger than the TX Packet Buffer Size. For example, an operating system may be using the time sensitive networking features of the I210 and the registers may be programmed correctly, but then a reset signal is asserted and iPXE on the next boot will be unable to use the I210. Mimic what Linux does and forcibly set the registers to their default values. Signed-off-by: Matt Parrella <parrella.matthew@gmail.com>
* [dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACKMichael Brown2023-03-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | When a DHCP transaction does not result in the registration of a new "proxydhcp" or "pxebs" settings block, any existing settings blocks are currently left unaltered. This can cause surprising behaviour. For example: when chainloading iPXE, the "proxydhcp" and "pxebs" settings blocks may be prepopulated using cached values from the previous PXE bootloader. If iPXE performs a subsequent DHCP request, then the DHCP or ProxyDHCP servers may choose to respond differently to iPXE. The response may choose to omit the ProxyDHCP or PXEBS stages, in which case no new "proxydhcp" or "pxebs" settings blocks may be registered. This will result in iPXE using a combination of both old and new DHCP responses. Fix by assuming that a successful DHCPACK effectively acquires ownership of the "proxydhcp" and "pxebs" settings blocks, and that any existing settings blocks should therefore be unregistered. Reported-by: Henry Tung <htung@palantir.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use image name instead of pointer value in debug messagesMichael Brown2023-03-071-21/+21
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Always unregister currently executing imageinterpreterMichael Brown2023-03-075-29/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We unregister script images during their execution, to prevent a "boot" command from re-executing the containing script. This also has the side effect of preventing executing scripts from showing up within the Linux magic initrd image (or the Multiboot module list). Additional logic in bzimage.c and efi_file.c prevents a currently executing kernel from showing up within the magic initrd image. Similar logic in multiboot.c prevents the Multiboot kernel from showing up as a Multiboot module. This still leaves some corner cases that are not covered correctly. For example: when using a gzip-compressed kernel image, nothing will currently hide the original compressed image from the magic initrd. Fix by moving the logic that temporarily unregisters the current image from script_exec() to image_exec(), so that it applies to all image types, and simplify the magic initrd and Multiboot module list construction logic on the basis that no further filtering of the registered image list is necessary. This change has the side effect of hiding currently executing EFI images from the virtual filesystem exposed by iPXE. For example, when using iPXE to boot wimboot, the wimboot binary itself will no longer be visible within the virtual filesystem. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Consistently use for_each_image() to iterate over imagesMichael Brown2023-03-062-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelx] Add PCI IDs for Intel 82599 10GBASE-T NICForest Crossman2023-03-051-0/+1
| | | | Signed-off-by: Forest Crossman <cyrozap@gmail.com>
* [params] Allow for arbitrary HTTP request headers to be specifiedMichael Brown2023-03-015-15/+73
| | | | | | | | | | | Extend the request parameter mechanism to allow for arbitrary HTTP headers to be specified via e.g.: params param --header Referer http://www.example.com imgfetch http://192.168.0.1/script.ipxe##params Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [params] Rename "form parameter" to "request parameter"Michael Brown2023-03-017-29/+29
| | | | | | | | Prepare for the parameter mechanism to be generalised to specifying request parameters that are passed via mechanisms other than an application/x-www-form-urlencoded form. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [http] Use POST method only if the form parameter list is non-emptyMichael Brown2023-03-011-44/+32
| | | | | | | | | | | | | An attempt to use an existent but empty form parameter list will currently result in an invalid POST request since the Content-Length header will be missing. Fix by using GET instead of POST if the form parameter list is empty. This is a non-breaking change (since the current behaviour produces an invalid request), and simplifies the imminent generalisation of the parameter list concept to handle both header and form parameters. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Omit EFI_LOAD_FILE2_PROTOCOL for a zero-length initrdnoinitrdMichael Brown2023-02-281-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the Linux kernel is being used with no initrd, iPXE will still provide a zero-length initrd.magic file within the virtual filesystem. As of commit 6a004be ("[efi] Support the initrd autodetection mechanism in newer Linux kernels"), this zero-length file will also be exposed via an EFI_LOAD_FILE2_PROTOCOL instance on a handle with a fixed device path. The correct handling of zero-length files via EFI_LOAD_FILE2_PROTOCOL is unfortunately not well defined. Linux expects the first call to LoadFile() to always fail with EFI_BUFFER_TOO_SMALL. When the initrd is genuinely zero-length, iPXE will return success since the buffer is not too small to hold the (zero-length) file. This causes Linux to immediately report a spurious EFI_LOAD_ERROR boot failure. We could change the logic in iPXE's efi_file_load() to always return EFI_BUFFER_TOO_SMALL if Buffer is NULL on entry. Since the correct behaviour of LoadFile() in the corner case of a zero-length file is left undefined by the UEFI specification, this would be permissible. Unfortunately this approach would not fix the problem. If we return EFI_BUFFER_TOO_SMALL and set the file length to zero, then Linux will call the boot services AllocatePages() method with a zero length. In at least the EDK2 implementation, this combination of parameters will cause AllocatePages() to return EFI_OUT_OF_RESOURCES, and Linux will again report a boot failure. Another approach would be to install the initrd device path handle only if we have a non-empty initrd to offer. Unfortunately this would lead to a failure in yet another corner case: if a previous bootloader has installed an initrd device path handle (e.g. to pass a boot script to iPXE) then we must not leave that initrd in place, since then our loaded kernel would end up seeing the wrong initrd content. The cleanest fix seems to be to ensure that the initrd device path handle is installed with the EFI_DEVICE_PATH_PROTOCOL instance present but with the EFI_LOAD_FILE2_PROTOCOL instance absent (and forcibly uninstalled if necessary), matching the state in which we leave the handle after uninstalling our virtual filesystem. Linux will then not find any handle that supports EFI_LOAD_FILE2_PROTOCOL within the fixed device path, and so will fall through to trying other mechanisms to locate the initrd. Reported-by: Chris Bradshaw <cwbshaw@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split out EFI_RNG_PROTOCOL as a separate entropy sourceentropyMichael Brown2023-02-205-92/+130
| | | | | | | | | | | | | | | | | | Commit 7ca801d ("[efi] Use the EFI_RNG_PROTOCOL as an entropy source if available") added EFI_RNG_PROTOCOL as an alternative entropy source via an ad-hoc mechanism specific to efi_entropy.c. Split out EFI_RNG_PROTOCOL to a separate entropy source, and allow the entropy core to handle the selection of RDRAND, EFI_RNG_PROTOCOL, or timer ticks as the active source. The fault detection logic added in commit a87537d ("[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementations") may be removed completely, since the failure will already be detected by the generic ANS X9.82-mandated repetition count test and will now be handled gracefully by the entropy core. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Allow for entropy sources that fail during startup testsMichael Brown2023-02-203-159/+349
| | | | | | | | | Provide per-source state variables for the repetition count test and adaptive proportion test, to allow for the situation in which an entropy source can be enabled but then fails during the startup tests, thereby requiring an alternative entropy source to be used. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tables] Allow any lvalue to be used as a table iteratorMichael Brown2023-02-201-12/+12
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Allow entropy source to be selected at runtimeMichael Brown2023-02-1718-591/+512
| | | | | | | | | | | | | | | | | | | | | | | | As noted in commit 3c83843 ("[rng] Check for several functioning RTC interrupts"), experimentation shows that Hyper-V cannot be trusted to reliably generate RTC interrupts. (As noted in commit f3ba0fb ("[hyperv] Provide timer based on the 10MHz time reference count MSR"), Hyper-V appears to suffer from a general problem in reliably generating any legacy interrupts.) An alternative entropy source is therefore required for an image that may be used in a Hyper-V Gen1 virtual machine. The x86 RDRAND instruction provides a suitable alternative entropy source, but may not be supported by all CPUs. We must therefore allow for multiple entropy sources to be compiled in, with the single active entropy source selected only at runtime. Restructure the internal entropy API to allow a working entropy source to be detected and chosen at runtime. Enable the RDRAND entropy source for all x86 builds, since it is likely to be substantially faster than any other source. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Limit maximum transfer size to MaxBurstLengthiscsicapMichael Brown2023-02-163-4/+77
| | | | | | | | | | | | | | | | | We currently specify only the iSCSI default value for MaxBurstLength and ignore any negotiated value, since our internal block device API allows only for receiving directly into caller-allocated buffers and so we have no intrinsic limit on burst length. A conscientious target may however refuse to attempt a transfer that we request for a number of blocks that would exceed the negotiated maximum burst length. Fix by recording the negotiated maximum burst length and using it to limit the maximum number of blocks per transfer as reported by the SCSI layer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Add RDRAND as an entropy sourceMichael Brown2023-02-155-0/+141
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Support the initrd autodetection mechanism in newer Linux kernelsMichael Brown2023-02-151-0/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 5.7 added the ability to autodetect an initrd by searching for a handle via a fixed vendor-specific "Linux initrd device path" and then locating and using the EFI_LOAD_FILE2_PROTOCOL instance on that handle. This maps quite naturally onto our existing concept of a "magic initrd" as introduced for EFI in commit e5f0255 ("[efi] Provide an "initrd.magic" file for use by UEFI kernels"). Add an EFI_LOAD_FILE2_PROTOCOL instance to our EFI virtual files (backed by simply calling the existing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL method to read from the file), and install the protocol instance for the "initrd.magic" virtual file onto a new device handle that also provides the Linux initrd device path. The design choice in Linux of using a single fixed device path makes this unfortunately messy to support, since device paths must be unique within a system. When multiple bootloaders are used (e.g. GRUB loading iPXE loading Linux) then only one bootloader can ever install the device path onto a handle. Subsequent bootloaders must locate the existing handle and replace the load file protocol instance with their own. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix debug message when reading from EFI virtual filesMichael Brown2023-02-151-1/+1
| | | | | | | Show the requested range when a caller reads from a virtual file via the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Check delimiters when parsing command-line key-value argumentsMichael Brown2023-02-144-28/+50
| | | | | | | | | | | | | | | | The Linux kernel bzImage image format and the CPIO archive constructor will parse the image command line for certain arguments of the form "key=value". This parsing is currently implemented using strstr() in a way that can cause a false positive suffix match. For example, a command line containing "highmem=<n>" would erroneously be treated as containing a value for "mem=<n>". Fix by centralising the logic used for parsing such arguments, and including a check that the argument immediately follows a whitespace delimiter (or is at the start of the string). Reported-by: Filippo Giunchedi <filippo@esaurito.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Check for several functioning RTC interruptsMichael Brown2023-02-111-3/+11
| | | | | | | | | | | | | | | | | | Commit 74222cd ("[rng] Check for functioning RTC interrupt") added a check that the RTC is capable of generating interrupts via the legacy PIC, since this mechanism appears to be broken in some Hyper-V virtual machines. Experimentation shows that the RTC is sometimes capable of generating a single interrupt, but will then generate no subsequent interrupts. This currently causes rtc_entropy_check() to falsely detect that the entropy gathering mechanism is functional. Fix by checking for several RTC interrupts before declaring that it is a functional entropy source. Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eisa] Check for system board presence before probing for slotseisaMichael Brown2023-02-101-0/+8
| | | | | | | | | | | | | | | EISA expansion slot I/O port addresses overlap space that may be assigned to PCI devices, which can lead to register reads and writes with unwanted side effects during EISA probing. Reduce the chances of performing EISA probing on PCI devices by probing EISA slot vendor and product ID registers only if the EISA system board vendor ID register indicates that the motherboard supports EISA. Debugged-by: Václav Ovsík <vaclav.ovsik@gmail.com> Tested-by: Václav Ovsík <vaclav.ovsik@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [loong64] Add initial support for LoongArch64Xiaotian Wu2023-02-0635-0/+1539
| | | | | | | | Add support for building a LoongArch64 Linux userspace binary. Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Include build architecture in test suite bannerMichael Brown2023-02-061-1/+1
| | | | | | | | | | | The test suites for the various architectures are often run back to back, and there is currently nothing to visually distinguish one test run from another. Include the architecture name within the self-test startup banner, to aid in visual identification of test results. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ci] Cache downloaded packages for GitHub actionsMichael Brown2023-02-061-0/+49
| | | | | | | | | | | Speed up the "Install packages" step for each CI run by caching the downloaded packages in /var/cache/apt. Do not include libc6-dbg:i386 within the cache, since apt seems to complain if asked to download both gcc-aarch64-linux-gnu and libc6-dbg:i386 at the same time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Move PAGE_SHIFT to bits/io.hMichael Brown2023-02-064-6/+6
| | | | | | | | | | | The PAGE_SHIFT definition is an architectural property, rather than an aspect of a particular I/O API implementation (of which, in theory, there may be more than one per architecture). Reflect this by moving the definition to the top-level bits/io.h for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow for per-architecture unprefixed constant operand modifierMichael Brown2023-02-055-2/+14
| | | | | | | | | | | | | | | | | | Over the years, the undocumented operand modifier used to produce the unprefixed constant values in __einfo_error() has varied from "%c0" to "%a0" in commit 1a77466 ("[build] Fix use of inline assembly on GCC 4.8 ARM64 builds") and back to "%c0" in commit 3fb3ffc ("[build] Fix use of inline assembly on GCC 8 ARM64 builds"), according to the evolving demands of the toolchain. LoongArch64 suffers from a similar issue: GCC 13 will allow either, but the currently released GCC 12 allows only the "%a0" form. Introduce a macro ASM_NO_PREFIX, defined in bits/compiler.h, to abstract away this difference and allow different architectures to use different operand modifiers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Allow for platforms that have no Xen supportMichael Brown2023-02-053-1/+81
| | | | | | | | | | | | | The Xen headers support only x86 and ARM. Allow for platforms such as LoongArch64 to build despite the absence of Xen support by providing an architecture-specific <bits/xen.h> that simply does: #ifndef _BITS_XEN_H #define _BITS_XEN_H #include <ipxe/nonxen.h> #endif /* _BITS_XEN_H */ Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 02:33:22 +0000