summaryrefslogtreecommitdiffstats
path: root/src/arch/x86/include/bits
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-143-0/+3
| | | | | | | | | 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>
* [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-1414-0/+14
| | | | | | | | | | | | 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>
* [crypto] Allow for zero-length big integer literalsMichael Brown2025-12-291-2/+6
| | | | | | | | | | 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>
* [pci] Use linker tables for runtime selectable PCI APIsMichael Brown2025-11-241-1/+0Star
| | | | | | | Use the linker table mechanism to enumerate the underlying PCI I/O APIs, to allow PCIAPI_CLOUD to become architecture-independent code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uart] Support 16550 UARTs accessed via either MMIO or port I/OMichael Brown2025-11-041-2/+2
| | | | | | | | | | | Use the combined accessors ioread8() and iowrite8() to read and write 16550 UART registers, to allow the decision between using MMIO and port I/O to be made at runtime. Minimise the increase in code size for x86 by ignoring the register shift, since this is essentially used only for non-x86 SoCs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uart] Allow for dynamically registered 16550 UARTsMichael Brown2025-06-221-8/+8
| | | | | | | Use the generic UART driver-private data pointer, rather than embedding the generic UART within the 16550 UART structure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uart] Allow for the existence of non-16550 UARTsMichael Brown2025-06-202-41/+60
| | | | | | | | | | | | | | | | | | | Remove the assumption that all platforms use a fixed number of 16550 UARTs identifiable by a simple numeric index. Create an abstraction allowing for dynamic instantiation and registration of any number of arbitrary UART models. The common case of the serial console on x86 uses a single fixed UART specified at compile time. Avoid unnecessarily dragging in the dynamic instantiation code in this use case by allowing COMCONSOLE to refer to a single static UART object representing the relevant port. When selecting a UART by command-line argument (as used in the "gdbstub serial <port>" command), allow the UART to be specified as either a numeric index (to retain backwards compatiblity) or a case-insensitive port name such as "COM2". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [initrd] Move initrd reshuffling to be architecture-independent codeMichael Brown2025-05-211-1/+0Star
| | | | | | | | There is nothing x86-specific in initrd.c, and a variant of the reshuffling logic will be required for executing bare-metal kernels on RISC-V and AArch64. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Use generic external heap based on the system memory mapMichael Brown2025-05-192-15/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Update to use the generic system memory map APIMichael Brown2025-05-161-0/+14
| | | | | | | | Provide an implementation of the system memory map API based on the assorted BIOS INT 15 calls, and a temporary implementation of the legacy get_memmap() function using the new API. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Rename memmap.c to int15.cMichael Brown2025-05-141-1/+1
| | | | | | | Create namespace for an architecture-independent memmap.c by renaming the BIOS-specific memmap.c to int15.c. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Generalise librm's virt_offset mechanism for RISC-VMichael Brown2025-05-081-14/+0Star
| | | | | | | | | | | | | | The virtual offset memory model used for i386-pcbios and x86_64-pcbios can be generalised to also cover riscv32-sbi and riscv64-sbi. In both architectures, the 32-bit builds will use a circular map of the 32-bit address space, and the 64-bit builds will use an identity map for the relevant portion of the physical address space, with iPXE itself placed in the negative (kernel) address space. Generalise and document the virt_offset mechanism, and set it as the default for both PCBIOS and SBI platforms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose shifted out bit from big integer shiftsMichael Brown2025-02-131-6/+13
| | | | | | | Expose the bit shifted out as a result of shifting a big integer left or right. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose carry flag from big integer addition and subtractionMichael Brown2024-11-261-6/+14
| | | | | | | | Expose the effective carry (or borrow) out flag from big integer addition and subtraction, and use this to elide an explicit bit test when performing x25519 reduction. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use architecture-independent bigint_is_set()Michael Brown2024-10-101-19/+0Star
| | | | | | | | | | | Every architecture uses the same implementation for bigint_is_set(), and there is no reason to suspect that a future CPU architecture will provide a more efficient way to implement this operation. Simplify the code by providing a single architecture-independent implementation of bigint_is_set(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Rename bigint_rol()/bigint_ror() to bigint_shl()/bigint_shr()Michael Brown2024-10-071-4/+4
| | | | | | | | | | | The big integer shift operations are misleadingly described as rotations since the original x86 implementations are essentially trivial loops around the relevant rotate-through-carry instruction. The overall operation performed is a shift rather than a rotation. Update the function names and descriptions to reflect this. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Eliminate temporary carry space for big integer multiplicationMichael Brown2024-09-271-13/+12Star
| | | | | | | | | | | | An n-bit multiplication product may be added to up to two n-bit integers without exceeding the range of a (2n)-bit integer: (2^n - 1)*(2^n - 1) + (2^n - 1) + (2^n - 1) = 2^(2n) - 1 Exploit this to perform big integer multiplication in constant time without requiring the caller to provide temporary carry space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use constant-time big integer multiplicationMichael Brown2024-09-231-5/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Big integer multiplication currently performs immediate carry propagation from each step of the long multiplication, relying on the fact that the overall result has a known maximum value to minimise the number of carries performed without ever needing to explicitly check against the result buffer size. This is not a constant-time algorithm, since the number of carries performed will be a function of the input values. We could make it constant-time by always continuing to propagate the carry until reaching the end of the result buffer, but this would introduce a large number of redundant zero carries. Require callers of bigint_multiply() to provide a temporary carry storage buffer, of the same size as the result buffer. This allows the carry-out from the accumulation of each double-element product to be accumulated in the temporary carry space, and then added in via a single call to bigint_add() after the multiplication is complete. Since the structure of big integer multiplication is identical across all current CPU architectures, provide a single shared implementation of bigint_multiply(). The architecture-specific operation then becomes the multiplication of two big integer elements and the accumulation of the double-element product. Note that any intermediate carry arising from accumulating the lower half of the double-element product may be added to the upper half of the double-element product without risk of overflow, since the result of multiplying two n-bit integers can never have all n bits set in its upper half. This simplifies the carry calculations for architectures such as RISC-V and LoongArch64 that do not have a carry flag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise definition of efi_cpu_nap()Michael Brown2024-09-131-2/+9
| | | | | | | | | Define a cpu_halt() function which is architecture-specific but platform-independent, and merge the multiple architecture-specific implementations of the EFI cpu_nap() function into a single central efi_cpu_nap() that uses cpu_halt() if applicable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ucode] Add support for updating x86 microcodeMichael Brown2024-03-151-0/+1
| | | | | | | | | | | | | | | | | | | Intel and AMD distribute microcode updates, which are typically applied by the BIOS and/or the booted operating system. BIOS updates can be difficult to obtain and cumbersome to apply, and are often neglected. Operating system updates may be subject to strict change control processes, particularly for production workloads. There is therefore value in being able to update the microcode at boot time using a freshly downloaded microcode update file, particularly in scenarios where the physical hardware and the installed operating system are controlled by different parties (such as in a public cloud infrastructure). Add support for parsing Intel and AMD microcode update images, and for applying the updates to all CPUs in the system. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Provide a multiprocessor API for BIOSMichael Brown2024-03-151-0/+2
| | | | | | | | Provide an implementation of the iPXE multiprocessor API for BIOS, based on sending broadcast INIT and SIPI interprocessor interrupts to start up all application processors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [mp] Define an API for multiprocessor functionsMichael Brown2024-03-151-0/+12
| | | | | | | | | | | | | Define an API for executing very limited functions on application processors in a multiprocessor system, along with an x86-only implementation. The normal iPXE runtime environment is effectively non-existent on application processors. There is no ability to make firmware calls (e.g. to write to a console), and there may be no stack space available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow multiplicand and multiplier to differ in sizeMichael Brown2024-01-161-1/+3
| | | | | | | | | | | Big integer multiplication is currently used only as part of modular exponentiation, where both multiplicand and multiplier will be the same size. Relax this requirement to allow for the use of big integer multiplication in other contexts. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Allow entropy source to be selected at runtimeMichael Brown2023-02-171-15/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* [rng] Add RDRAND as an entropy sourceMichael Brown2023-02-152-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Move PAGE_SHIFT to bits/io.hMichael Brown2023-02-061-0/+3
| | | | | | | | | | | 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>
* [pci] Select PCI I/O API at runtime for cloud imagesMichael Brown2022-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pretty much all physical machines and off-the-shelf virtual machines will provide a functional PCI BIOS. We therefore default to using only the PCI BIOS, with no fallback to an alternative mechanism if the PCI BIOS fails. AWS EC2 provides the opportunity to experience some exceptions to this rule. For example, the t3a.nano instances in eu-west-1 have no functional PCI BIOS at all. As of commit 83516ba ("[cloud] Use PCIAPI_DIRECT for cloud images") we therefore use direct Type 1 configuration space accesses in the images built and published for use in the cloud. Recent experience has discovered yet more variation in AWS EC2 instances. For example, some of the metal instance types have multiple PCI host bridges and the direct Type 1 accesses therefore see only a subset of the PCI devices. Attempt to accommodate future such variations by making the PCI I/O API selectable at runtime and choosing ECAM (if available), falling back to the PCI BIOS (if available), then finally falling back to direct Type 1 accesses. This is implemented as a dedicated PCIAPI_CLOUD API, rather than by having the PCI core select a suitable API at runtime (as was done for timers in commit 302f1ee ("[time] Allow timer to be selected at runtime"). The common case will remain that only the PCI BIOS API is required, and we would prefer to retain the optimisations that come from inlining the configuration space accesses in this common case. Cloud images are (at present) disk images rather than ROM images, and so the increased code size required for this design approach in the PCIAPI_CLOUD case is acceptable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add memory output constraints for big-integer inline assemblyMichael Brown2021-06-031-17/+37
| | | | | | | | | | | | | | | The ARM versions of the big-integer inline assembly functions include constraints to indicate that the output value is modified by the assembly code. These constraints are not present in the equivalent code for the x86 versions. As of GCC 11, this results in the compiler reporting that the output values may be uninitialized. Fix by including the relevant memory output constraints. Reported-by: Christian Hesse <mail@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Use host glibc system call wrappersMichael Brown2021-03-011-6/+0Star
| | | | | | | | | | | | | | | | | | | | | | When building as a Linux userspace application, iPXE currently implements its own system calls to the host kernel rather than relying on the host's C library. The output binary is statically linked and has no external dependencies. This matches the general philosophy of other platforms on which iPXE runs, since there are no external libraries available on either BIOS or UEFI bare metal. However, it would be useful for the Linux userspace application to be able to link against host libraries such as libslirp. Modify the build process to perform a two-stage link: first picking out the requested objects in the usual way from blib.a but with relocations left present, then linking again with a helper object to create a standard hosted application. The helper object provides the standard main() entry point and wrappers for the Linux system calls required by the iPXE Linux drivers and interface code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bitops] Provide an explicit operand size for bit test instructionsMichael Brown2021-02-271-4/+4
| | | | | | | | | | | | | | | | | | Recent versions of the GNU assembler (observed with GNU as 2.35 on Fedora 33) will produce a warning message Warning: no instruction mnemonic suffix given and no register operands; using default for `bts' The operand size affects only the potential range for the bit number. Since we pass the bit number as an unsigned int, it is already constrained to 32 bits for both i386 and x86_64. Silence the assembler warning by specifying an explicit 32-bit operand size (and thereby matching the choice that the assembler would otherwise make automatically). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Avoid temporarily setting direction flag in bigint_is_geq()Michael Brown2020-07-071-17/+8Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The UEFI specification states that the calling convention for IA-32 and x64 includes "Direction flag in EFLAGS is clear". This specification covers only the calling convention used at the point of calling functions annotated with EFIAPI. The specification explicitly states that other functions (such as private functions or static library calls) are not required to follow the UEFI calling conventions. The reference EDK2 implementation follows this specification. In particular, the EDK2 interrupt handlers will clear the direction flag before calling any EFIAPI functions, and will restore the direction flag when returning from the interrupt handler. Some EDK2 private library functions (most notably InternalMemCopyMem) may set the direction flag temporarily in order to make efficient use of CPU string operations. The current implementation of iPXE's bigint_is_geq() for i386 and x86_64 will similarly set the direction flag temporarily in order to make efficient use of CPU string operations. On some UEFI implementations (observed with a Getac RX10 tablet), a timer interrupt that happens to occur while the direction flag is set will reboot the machine. This very strongly indicates that the UEFI timer interrupt handler is failing to clear the direction flag before performing an affected operation (such as copying a block of memory). Work around such buggy UEFI implementations by rewriting bigint_is_geq() to avoid the use of string operations and so obviate the requirement to temporarily set the direction flag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [time] Add support for the ACPI power management timerMichael Brown2018-03-201-0/+1
| | | | | | | | Allow the ACPI power management timer to be used if enabled via TIMER_ACPI in config/timer.h. This provides an alternative timer on systems where the standard 8254 PIT is unavailable or unreliable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Make acpi_find_rsdt() a per-platform methodMichael Brown2017-05-231-0/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [time] Allow timer to be selected at runtimeMichael Brown2017-01-262-15/+1Star
| | | | | | | | | | | | | | | | | | | | | | Allow the active timer (providing udelay() and currticks()) to be selected at runtime based on probing during the INIT_EARLY stage of initialisation. TICKS_PER_SEC is now a fixed compile-time constant for all builds, and is independent of the underlying clock tick rate. We choose the value 1024 to allow multiplications and divisions on seconds to be converted to bit shifts. TICKS_PER_MS is defined as 1, allowing multiplications and divisions on milliseconds to be omitted entirely. The 2% inaccuracy in this definition is negligible when using the standard BIOS timer (running at around 18.2Hz). TIMER_RDTSC now checks for a constant TSC before claiming to be a usable timer. (This timer can be tested in KVM via the command-line option "-cpu host,+invtsc".) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cpuid] Provide cpuid_supported() to test for supported functionsMichael Brown2017-01-251-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Add support for ACPI power offMichael Brown2016-07-111-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Check for functioning RTC interruptMichael Brown2016-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | On some platforms (observed in a small subset of Microsoft Azure (Hyper-V) virtual machines), the RTC appears to be incapable of generating an interrupt via the legacy PIC. The RTC status registers show that a periodic interrupt has been asserted, but the PIC IRR shows that IRQ8 remains inactive. On such systems, iPXE will currently freeze during the "iPXE initialising devices..." message. Work around this problem by checking that RTC interrupts are being raised before returning from rtc_entropy_enable(). If no interrupt is seen within 100ms, then we assume that the RTC interrupt mechanism is broken. In these circumstances, iPXE will continue to initialise but any subsequent attempt to generate entropy will fail. In particular, HTTPS connections will fail with an error indicating that no entropy is available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise EFI entropy generation to non-x86 CPUsMichael Brown2016-05-041-1/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tcpip] Do not fall back to using unoptimised TCP/IP checksummingMichael Brown2016-05-041-4/+2Star
| | | | | | | | Require architecture-specific code to make a deliberate choice to use the unoptimised generic_tcpip_continue_chksum() function, if there is no optimised version available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gdb] Add support for x86_64Michael Brown2016-03-221-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Use generic test_and_clear_bit() functionMichael Brown2016-03-161-19/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bitops] Add generic atomic bit test, set, and clear functionsMichael Brown2016-03-161-0/+94
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Support ioremap() for addresses above 4GB in a 64-bit buildMichael Brown2016-02-261-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Split ioremap() out to a separate IOMAP APIMichael Brown2016-02-261-0/+12
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Add bin-x86_64-pcbios build platformMichael Brown2016-02-169-0/+128
| | | | | | | | | | | | | | Move most arch/i386 files to arch/x86, and adjust the contents of the Makefiles and the include/bits/*.h headers to reflect the new locations. This patch makes no substantive code changes, as can be seen using a rename-aware diff (e.g. "git show -M5"). This patch does not make the pcbios platform functional for x86_64; it merely allows it to compile without errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Wait for and clear XenStore event before receiving dataMichael Brown2015-06-301-0/+19
| | | | | | | | | | | | | | | Older, out-of-tree Xen kernel modules (such as those provided with SuSE Linux Enterprise Server 11) do not clear the leftover "event pending" bit when opening an event channel. Consequently, no event is ever delivered to indicate that there is information in the XenStore ring buffer, and the system hangs shortly after loading the xen-platform-pci kernel module. Work around this problem by always waiting for the XenStore event channel to be signalled, and clearing the event before processing the received data. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [serial] Add general abstraction of a 16550-compatible UARTMichael Brown2015-06-292-0/+42
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [int13con] Add basic ability to log to a local disk via INT 13Michael Brown2015-05-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Several popular public cloud providers do not provide any sensible mechanism for obtaining debug output from an OS which is failing to boot. For example, Amazon EC2 provides the "Get System Log" facility, which occasionally deigns to report a random subset of the characters emitted via the VM's serial port, but usually returns only a blank screen. (Amazingly, this is still superior to the debugging facilities provided by Azure.) Work around these shortcomings by adding a console type which sends output to a magically detected raw disk partition, and including such a partition within any iPXE .usb-format image. To use this facility: - build an iPXE .usb image with CONSOLE_INT13 enabled - boot the cloud VM from this image - after the boot fails, attach the VM's boot disk to a second VM - from this second VM, use "less -f -R /dev/sdb3" (or similar) to view the iPXE output. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI entropy sourceMichael Brown2015-04-141-0/+1
| | | | | Originally-implemented-by: Jarrod Johnson <jbjohnso@us.ibm.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Rewrite byte-swapping codeMichael Brown2015-03-021-0/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-05 02:02:53 +0100