summaryrefslogtreecommitdiffstats
path: root/src/arch/x86/include
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-1426-0/+26
| | | | | | | | | | | | 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] Allow probing permission to vary by rangeMichael Brown2025-11-252-2/+4
| | | | | | | Make pci_can_probe() part of the runtime selectable PCI I/O API, and defer this check to the per-range API. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Use linker tables for runtime selectable PCI APIsMichael Brown2025-11-244-33/+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>
* [ioapi] Allow iounmap() to be called for port I/O addressesMichael Brown2025-11-051-0/+4
| | | | | | | | | | | | | | | | | Allow code using the combined MMIO and port I/O accessors to safely call iounmap() to unmap the MMIO or port I/O region. In the virtual offset I/O mapping API as used for UEFI, 32-bit BIOS, and 32-bit RISC-V SBI, iounmap() is a no-op anyway. In 64-bit RISC-V SBI, we have no concept of port I/O and so the issue is moot. This leaves only 64-bit BIOS, where it suffices to simply do nothing for any pages outside of the chosen MMIO virtual address range. For symmetry, we implement the equivalent change in the very closely related RISC-V page management 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-212-24/+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-193-33/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Describe umalloc() heap as an in-use memory areaMichael Brown2025-05-162-5/+1Star
| | | | | | | Use the concept of an in-use memory region defined as part of the system memory map API to describe the umalloc() heap. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Update to use the generic system memory map APIMichael Brown2025-05-162-0/+34
| | | | | | | | 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>
* [build] Formalise mechanism for accessing absolute symbolsMichael Brown2025-05-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | In a position-dependent executable, where all addresses are fixed at link time, we can use the standard technique as documented by GNU ld to get the value of an absolute symbol, e.g.: extern char _my_symbol[]; printf ( "Absolute symbol value is %x\n", ( ( int ) _my_symbol ) ); This technique may not work in a position-independent executable. When dynamic relocations are applied, the runtime addresses will no longer be equal to the link-time addresses. If the code to obtain the address of _my_symbol uses PC-relative addressing, then it will calculate the runtime "address" of the absolute symbol, which will no longer be equal the the link-time "address" (i.e. the correct value) of the absolute symbol. Define macros ABS_SYMBOL(), ABS_VALUE_INIT(), and ABS_VALUE() that provide access to the correct values of absolute symbols even in position-independent code, and use these macros wherever absolute symbols are accessed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Generalise librm's virt_offset mechanism for RISC-VMichael Brown2025-05-083-67/+1Star
| | | | | | | | | | | | | | 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>
* [uaccess] Remove redundant virt_to_user() and userptr_tMichael Brown2025-04-301-5/+0Star
| | | | | | | | | 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>
* [uaccess] Remove redundant copy_from_user() and copy_to_user()Michael Brown2025-04-301-0/+1
| | | | | | | Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove some long-obsolete unused header filesMichael Brown2025-04-291-69/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [comboot] Remove userptr_t from COM32 API implementationMichael Brown2025-04-291-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [initrd] Use physical addresses for calculations on initrd locationsMichael Brown2025-04-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | Commit ef03849 ("[uaccess] Remove redundant userptr_add() and userptr_diff()") exposed a signedness bug in the comparison of initrd locations, since the expression (initrd->data - current) was effectively no longer coerced to a signed type. In particular, the common case will be that the top of the initrd region is the start of the iPXE .textdata region, which has virtual address zero. This causes initrd->data to compare as being above the top of the initrd region for all images, when this bug would previously have been limited to affecting only initrds placed 2GB or more below the start of .textdata. Fix by using physical addresses for all comparisons on initrd locations. Reported-by: Sven Dreyer <sven@dreyer-net.de> Reported-by: Harald Jensås <hjensas@redhat.com> Reported-by: Jan ONDREJ (SAL) <ondrejj@salstar.sk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Remove userptr_t from PXE API call dispatcherMichael Brown2025-04-251-3/+0Star
| | | | | | | | | Simplify the PXE API call dispatcher code by assuming that the PXE parameter block is accessible via a direct pointer dereference. This avoids the need for the API call dispatcher to know the size of the parameter block. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove now-obsolete memchr_user()Michael Brown2025-04-241-7/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove trivial uses of userptr_tMichael Brown2025-04-241-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Remove userptr_t from ACPI table parsingMichael Brown2025-04-221-2/+2
| | | | | | | Simplify the ACPI table parsing code by assuming that all table content is fully accessible via pointer dereferences. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Replace real_to_user() with real_to_virt()Michael Brown2025-04-212-8/+8
| | | | | | | | Remove the intermediate concept of a user pointer from real address conversion, leaving real_to_virt() as the directly implemented function. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove user_to_phys() and phys_to_user()Michael Brown2025-04-212-14/+13Star
| | | | | | | | Remove the intermediate concept of a user pointer from physical address conversions, leaving virt_to_phys() and phys_to_virt() as the directly implemented functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove redundant user_to_virt()Michael Brown2025-04-211-5/+0Star
| | | | | | | | | The user_to_virt() function is now a straightforward wrapper around addition, with the addend almost invariably being zero. Remove this redundant wrapper. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove redundant memcpy_user() and related string functionsMichael Brown2025-04-211-32/+0Star
| | | | | | | | | | The memcpy_user(), memmove_user(), memcmp_user(), memset_user(), and strlen_user() functions are now just straightforward wrappers around the corresponding standard library functions. Remove these redundant wrappers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove redundant userptr_add() and userptr_diff()Michael Brown2025-04-201-11/+0Star
| | | | | | | | | The userptr_add() and userptr_diff() functions are now just straightforward wrappers around addition and subtraction. Remove these redundant wrappers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Add explicit casts to and from userptr_t where neededMichael Brown2025-04-201-3/+3
| | | | | | | Allow for the possibility of userptr_t becoming a pointer type by adding explicit casts where necessary. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Rename userptr_sub() to userptr_diff()Michael Brown2025-04-201-3/+3
| | | | | | | | | Clarify the intended usage of userptr_sub() by renaming it to userptr_diff() (to avoid confusion with userptr_add()), and fix the existing call sites that erroneously use userptr_sub() to subtract an offset from a userptr_t value. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pic8259] Return previous state when enabling or disabling IRQsMichael Brown2025-03-141-3/+44
| | | | | | | Return the previous interrupt enabled state from enable_irq() and disable_irq(), to allow callers to more easily restore this state. 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-132-20/+9Star
| | | | | | | | | 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>
* [pci] Separate permission to probe buses from bus:dev.fn range discoveryMichael Brown2024-08-153-0/+30
| | | | | | | | | | | | | | | | | The UEFI device model requires us to not probe the PCI bus directly, but instead to wait to be offered the opportunity to drive devices via our driver service binding handle. We currently inhibit PCI bus probing by having pci_discover() return an empty range when using the EFI PCI I/O API. This has the unwanted side effect that scanning the bus manually using the "pciscan" command will also fail to discover any devices. Separate out the concept of being allowed to probe PCI buses from the mechanism for discovering PCI bus:dev.fn address ranges, so that this limitation may be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cpuid] Allow reading hypervisor CPUID leavesMichael Brown2024-08-011-0/+3
| | | | | | | | | | | | | | Hypervisors typically intercept CPUID leaves in the range 0x40000000 to 0x400000ff, with leaf 0x40000000 returning the maximum supported function within this range in register %eax. iPXE currently masks off bit 30 from the requested CPUID leaf when checking to see if a function is supported, which causes this check to read from leaf 0x00000000 instead of 0x40000000. Fix by including bit 30 within the mask. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ucode] Add support for updating x86 microcodeMichael Brown2024-03-152-0/+224
| | | | | | | | | | | | | | | | | | | 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-152-0/+34
| | | | | | | | 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>
* [librm] Add support for installing a startup IPI handlerMichael Brown2024-03-151-0/+20
| | | | | | | | | | | | | | | | | | | | | | | Application processors are started via INIT and SIPI interprocessor interrupts: the INIT places the processor into a "wait for SIPI" state, and the SIPI then starts the processor in real mode at a page-aligned address derived from the SIPI vector number. Add support for installing a real-mode SIPI handler that will switch the CPU into protected mode with flat physical addressing, load initial register contents, and then jump to the address of a protected-mode SIPI handler. No stack pointer is set up, to avoid the need to allocate stack space for each available processor. We use 32-bit physical addressing in order to minimise the changes required for a 64-bit build. The existing long mode transition code relies on the existence of the stack, so we cannot easily switch the application processor into long mode. We could use 32-bit virtual addressing, but this runtime environment does not currently exist outside of librm.S itself in a 64-bit build, and using it would complicate the implementation of the protected-mode SIPI handler. 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>
* [librm] Use explicit operand size when pushing a label addressMichael Brown2023-09-051-2/+4
| | | | | | | | | | | | | | | | | | We currently use "push $1f" within inline assembly to push the address of the real-mode code fragment, relying on the assembler to treat this as "pushl" for 32-bit code or "pushq" for 64-bit code. As of binutils commit 5cc0077 ("x86: further adjust extend-to-32bit- address conditions"), first included in binutils-2.41, this implicit operand size is no longer calculated as expected and 64-bit builds will fail with Error: operand size mismatch for `push' Fix by adding an explicit operand size to the "push" instruction. Originally-fixed-by: Justin Cano <jstncno@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Allow entropy source to be selected at runtimeMichael Brown2023-02-173-114/+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-154-0/+42
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-04 21:04:22 +0100