aboutsummaryrefslogtreecommitdiffstats
path: root/src/arch/x86
Commit message (Collapse)AuthorAgeFilesLines
* [build] Centralise dummy architecture-specific headersriscv64Michael Brown2024-09-031-2/+2
| | | | | | | | Simplify the process of adding a new CPU architecture by providing common implementations of typically empty architecture-specific header files. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Separate permission to probe buses from bus:dev.fn range discoveryMichael Brown2024-08-156-0/+33
| | | | | | | | | | | | | | | | | 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 hypervisor CPUID leaves to be accessed as settingsMichael Brown2024-08-011-4/+14
| | | | | | | | | | | | Redefine bit 30 of an SMBIOS numerical setting to be part of the function number, in order to allow access to hypervisor CPUID leaves. This technically breaks backwards compatibility with scripts attempting to read more than 64 consecutive functions. Since there is no meaningful block of 64 consecutive related functions, it is vanishingly unlikely that this capability has ever been used. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cpuid] Allow reading hypervisor CPUID leavesMichael Brown2024-08-012-2/+5
| | | | | | | | | | | | | | 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>
* [build] Fix building on older versions of gccMichael Brown2024-03-171-0/+1
| | | | | | | | | | | | Older versions of gcc (observed with gcc 4.8.5 on CentOS 7) complain about having the label "err_ioremap" at the end of a compound statement in bios_mp_start_all(). The label is correctly placed, since it immediately follows the iounmap() that would be required to undo a successful ioremap() in the non-error case. Fix by adding an explicit "return" immediately after the label. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ucode] Add support for updating x86 microcodeMichael Brown2024-03-154-0/+1279
| | | | | | | | | | | | | | | | | | | 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-153-0/+206
| | | | | | | | 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-153-0/+113
| | | | | | | | | | | | | | | | | | | | | | | 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-152-0/+209
| | | | | | | | | | | | | 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>
* [block] Allow for additional SAN boot parameters alongside filenameMichael Brown2024-03-061-2/+3
| | | | | | | | | | | | | | | The drive specification alone does not necessarily contain enough information to perform a SAN boot (or local disk boot) under UEFI. If the next-stage bootloader is installed in the EFI system partition under a non-standard name (e.g. "\EFI\debian\grubx64.efi") then this explicit boot filename must also be specified. Generalise this concept to use a "SAN boot configuration parameters" structure (currently containing only the optional explicit boot filename), to allow for easy expansion to provide other parameters such as the partition UUID or volume label. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Use drive number as debug message stream IDMichael Brown2024-03-041-101/+109
| | | | | | | | | | | | We currently use the SAN device pointer as the debug message stream identifier. This pointer is not always available: for example, when booting from a local disk there is no underlying SAN device. Switch to using the drive number as the debug message colour stream identifier, so that all block device debug messages may be colourised consistently. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix hang during ExitBootServices()Ross Lagerwall2024-01-311-1/+5
| | | | | | | | | | | | | | | When ExitBootServices() invokes efi_shutdown_hook(), there may be nothing to generate an interrupt since the timer is disabled in the first step of ExitBootServices(). Additionally, for VMs OVMF masks everything from the PIC (except the timer) by default. This means that calling cpu_nap() may hang indefinitely. This was seen in practice in netfront_reset() when running in a VM on XenServer. Fix this by skipping the halt if an EFI shutdown is in progress. Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow multiplicand and multiplier to differ in sizeMichael Brown2024-01-162-12/+18
| | | | | | | | | | | 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>
* [build] Fix building with newer binutilsMichael Brown2024-01-1422-18/+20
| | | | | | | | | | | | | | | | | Newer versions of the GNU assembler (observed with binutils 2.41) will complain about the ".arch i386" in files assembled with "as --64", with the message "Error: 64bit mode not supported on 'i386'". In files such as stack.S that contain no instructions to be assembled, the ".arch i386" is redundant and may be removed entirely. In the remaining files, fix by moving ".arch i386" below the relevant ".code16" or ".code32" directive, so that the assembler is no longer expecting 64-bit instructions to be used by the time that the ".arch i386" directive is encountered. Reported-by: Ali Mustakim <alim@forwardcomputers.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove unnecessary ".text" directivesMichael Brown2024-01-1419-19/+0
| | | | | | | | | The .text directive is entirely redundant when followed by a .section directive giving an explicit section name and attributes. Remove these unnecessary directives to simplify the code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Support scanning for the 64-bit SMBIOS3 entry pointMichael Brown2023-12-291-2/+53
| | | | | | | | | | Support scanning for the 64-bit SMBIOS3 entry point in addition to the 32-bit SMBIOS2 entry point. Prefer use of the 32-bit entry point if present, since this is guaranteed to be within accessible memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Require discovery of a PCI device when determining usable PCI APIsMichael Brown2023-11-021-11/+14
| | | | | | | | | | | | | The PCI cloud API (PCIAPI_CLOUD) currently selects the first PCI API that successfully discovers a PCI device address range. The ECAM API may discover an address range but subsequently be unable to map the configuration space region, which would result in the selected PCI API being unusable. Fix by instead selecting the first PCI API that can be successfully used to discover a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vmware] Use driver-private data to hold GuestInfo settings blockMichael Brown2023-09-141-41/+7
| | | | | | | | | | | | | Simplify the per-netdevice GuestInfo settings code by using driver-private data to hold the settings block, instead of using a separate allocation. The settings block (if existent) will be automatically unregistered when the parent network device settings block is unregistered, and no longer needs to be separately freed. The guestinfo_net_remove() function may therefore be omitted completely. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allocate private data for each network upper-layer driverMichael Brown2023-09-132-3/+8
| | | | | | | | | | | | | | | | | Allow network upper-layer drivers (such as LLDP, which attaches to each network device in order to provide a corresponding LLDP settings block) to specify a size for private data, which will be allocated as part of the network device structure (as with the existing private data allocated for the underlying device driver). This will allow network upper-layer drivers to be simplified by omitting memory allocation and freeing code. If the upper-layer driver requires a reference counter (e.g. for interface initialisation), then it may use the network device's existing reference counter, since this is now the reference counter for the containing block of memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Use explicit operand size when pushing a label addressopsizeMichael 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>
* [console] Avoid overlap between special keys and Unicode charactersMichael Brown2023-07-041-24/+35
| | | | | | | | | | | | | | The special key range (from KEY_MIN upwards) currently overlaps with the valid range for Unicode characters, and therefore prohibits the use of Unicode key values outside the ASCII range. Create space for Unicode key values by moving the special keys to the range immediately above the maximum valid Unicode character. This allows the existing encoding of special keys as an efficiently packed representation of the equivalent ANSI escape sequence to be maintained almost as-is. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use separate code segment if supported by linkersepcodeMichael Brown2023-07-031-0/+7
| | | | | | | | | | | | | | | Some versions of ld will complain that the automatically created (and unused by our build process) ELF program headers include a "LOAD segment with RWX permissions". Silence this warning by adding "-z separate-code" to the linker options, where supported. For BIOS builds, where the prefix will generally require writable access to its own (tiny) code segment, simply inhibit the warning completely via "--no-warn-rwx-segments". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Inhibit linker warnings about an implied executable stackGeert Stappers2023-06-3026-0/+27
| | | | | | Signed-off-by: Geert Stappers <stappers@stappers.it> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid using multiple target patterns in pattern rulesMichael Brown2023-06-301-2/+8
| | | | | | | | | | | | | Multiple target patterns in pattern rules are treated as grouped targets regardless of the separator character. Newer verions of make will generate "warning: pattern recipe did not update peer target" to warn that the rule was expected to update all of the (implicitly) grouped targets. Fix by splitting all multiple target pattern rules into single target pattern rules. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Allow for images to be hidden from lists of all imagesMichael Brown2023-05-052-0/+8
| | | | | | | | | | | | | | | 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>
* [image] Always unregister currently executing imageinterpreterMichael Brown2023-03-072-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [rng] Allow entropy source to be selected at runtimeMichael Brown2023-02-175-136/+48
| | | | | | | | | | | | | | | | | | | | | | | | 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-155-0/+141
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Check delimiters when parsing command-line key-value argumentsMichael Brown2023-02-141-21/+16
| | | | | | | | | | | | | | | | 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>
* [ioapi] Move PAGE_SHIFT to bits/io.hMichael Brown2023-02-062-3/+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>
* [pxe] Discard queued PXE UDP packets when under memory pressureMichael Brown2023-01-251-0/+26
| | | | | | | | | | | The PXE UDP receive queue may grow without limit if the PXE NBP does not call PXENV_UDP_READ sufficiently frequently. Fix by implementing a cache discarder for received PXE UDP packets (similar to the TCP cache discarder). Reported-by: Tal Shorer <shorer@amazon.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Simplify platform-specific client architecture definitionsMichael Brown2023-01-223-45/+20
| | | | | | | | | | | | | | | | Move the platform-specific DHCP client architecture definitions to header files of the form <ipxe/$(PLATFORM)/dhcparch.h>. This simplifies the directory structure and allows the otherwise unused arch/$(ARCH)/include/$(PLATFORM) to be removed from the include directory search path, which avoids the confusing situation in which a header file may potentially be accessed through more than one path. For Linux userspace binaries on any architecture, use the EFI values for that architecture by delegating to the EFI header file. This avoids the need to explicitly select values for Linux userspace binaries for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Move -Ulinux to common MakefileMichael Brown2023-01-221-3/+0
| | | | | | | The requirement to undo the implicit "-Dlinux" is not specific to the x86 architecture. Move this out of the x86-specific Makefile. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Include VLAN tag in filter for applying cached DHCPACKMichael Brown2022-12-221-1/+1
| | | | | | | | | | | | | | | When chainloading iPXE from a VLAN device, the MAC address within the cached DHCPACK will match the MAC address of the trunk device created by iPXE, and the cached DHCPACK will then end up being erroneously applied to the trunk device. This tends to break outbound IPv4 routing, since both the trunk and VLAN devices will have the same assigned IPv4 address. Fix by recording the VLAN tag along with the cached DHCPACK, and treating the VLAN tag as part of the filter used to match the cached DHCPACK against candidate network devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bzimage] Fix parsing of "vga=..." when not at end of command linevgafixMichael Brown2022-10-271-4/+10
| | | | | | | | | | | | bzimage_parse_cmdline() uses strcmp() to identify the named "vga=..." kernel command line option values, which will give a false negative if the option is not last on the command line. Fix by temporarily changing the relevant command line separator (if any) to a NUL terminator. Debugged-by: Simon Rettberg <simon.rettberg@rz.uni-freiburg.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Select PCI I/O API at runtime for cloud imagesMichael Brown2022-09-187-0/+218
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [bios] Allow pcibios_discover() to return an empty rangeMichael Brown2022-09-181-3/+5
| | | | | | | Allow pcibios_discover() to return an empty range if the INT 1A,B101 PCI BIOS installation check call fails. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise pci_num_bus() to pci_discover()Michael Brown2022-09-153-11/+19
| | | | | | | | | | Allow pci_find_next() to discover devices beyond the first PCI segment, by generalising pci_num_bus() (which implicitly assumes that there is only a single PCI segment) with pci_discover() (which has the ability to return an arbitrary contiguous chunk of PCI bus:dev.fn address space). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for the possibility of overriding ACPI tables at link timeMichael Brown2022-03-242-2/+2
| | | | | | | Allow for linked-in code to override the mechanism used to locate an ACPI table, thereby opening up the possibility of ACPI self-tests. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fbcon] Support Unicode character outputMichael Brown2022-03-151-2/+23
| | | | | | | Accumulate UTF-8 characters in fbcon_putchar(), and require the frame buffer console's .glyph() method to accept Unicode character values. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support AltGr to access ASCII characters via remappingMichael Brown2022-02-152-0/+16
| | | | | | | | | | | | | Several keyboard layouts define ASCII characters as accessible only via the AltGr modifier. Add support for this modifier to ensure that all ASCII characters are accessible. Experiments suggest that the BIOS console is likely to fail to generate ASCII characters when the AltGr key is pressed. Work around this limitation by accepting LShift+RShift (which will definitely produce an ASCII character) as a synonym for AltGr. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Centralise handling of key modifiersMichael Brown2022-02-152-5/+21
| | | | | | | Handle Ctrl and CapsLock key modifiers within key_remap(), to provide consistent behaviour across different console types. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Handle remapping of scancode 86Michael Brown2022-02-101-0/+9
| | | | | | | | | | | | | | | | | The key with scancode 86 appears in the position between left shift and Z on a US keyboard, where it typically fails to exist entirely. Most US keyboard maps define this nonexistent key as generating "\|", with the notable exception of "loadkeys" which instead reports it as generating "<>". Both of these mapping choices duplicate keys that exist elsewhere in the map, which causes problems for our ASCII-based remapping mechanism. Work around these quirks by treating the key as generating "\|" with the high bit set, and making it subject to remapping. Where the BIOS generates "\|" as expected, this allows us to remap to the correct ASCII value. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Avoid attempting to remap numeric keypad on BIOS consoleMichael Brown2022-02-101-3/+18
| | | | | | | | | | | | | | | | | To minimise code size, our keyboard mapping works on the basis of allowing the BIOS to convert the keyboard scancode into an ASCII character and then remapping the ASCII character. This causes problems with keyboard layouts such as "fr" that swap the shifted and unshifted digit keys, since the ASCII-based remapping will spuriously remap the numeric keypad (which produces the same ASCII values as the digit keys). Fix by checking that the keyboard scancode is within the range of keys that vary between keyboard mappings before attempting to remap the ASCII character. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Generalise bios_keymap() as key_remap()Michael Brown2022-02-101-17/+1
| | | | | | | Allow the keyboard remapping functionality to be exposed to consoles other than the BIOS console. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Fix use of writable code segment on 486 and earlier CPUsfix486Michael Brown2022-02-021-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In real mode, code segments are always writable. In protected mode, code segments can never be writable. The precise implementation of this attribute differs between CPU generations, with subtly different behaviour arising on the transitions from protected mode to real mode. At the point of transition (when the PE bit is cleared in CR0) the hidden portion of the %cs descriptor will retain whatever attributes were in place for the protected-mode code segment, including the fact that the segment is not writable. The immediately following code will perform a far control flow transfer (such as ljmp or lret) in order to load a real-mode value into %cs. On the Pentium and later CPUs, the retained protected-mode attributes will be ignored for any accesses via %cs while the CPU is in real mode. A write via %cs will therefore be allowed even though the hidden portion of the %cs descriptor still describes a non-writable segment. On the 486 and earlier CPUs, the retained protected-mode attributes will not be ignored for accesses via %cs. A write via %cs will therefore cause a CPU fault. To obtain normal real-mode behaviour (i.e. a writable %cs descriptor), special logic is added to the ljmp instruction that populates the hidden portion of the %cs descriptor with real-mode attributes when a far jump is executed in real mode. The result is that writes via %cs will cause a CPU fault until the first ljmp instruction is executed, after which writes via %cs will be allowed as expected in real mode. The transition code in libprefix.S currently uses lret to load a real-mode value into %cs after clearing the PE bit. Experimentation shows that only the ljmp instruction will work to load real-mode attributes into the hidden portion of the %cs descriptor: other far control flow transfers (such as lret, lcall, or int) do not do so. When running on a 486 or earlier CPU, this results in code within libprefix.S running with a non-writable code segment after a mode transition, which in turn results in a CPU fault when real-mode code in liba20.S attempts to write to %cs:enable_a20_method. Fix by constructing and executing an ljmp instruction, to trigger the relevant descriptor population logic on 486 and earlier CPUs. This ljmp instruction is constructed on the stack, since the .prefix section may be executing directly from ROM (or from memory that the BIOS has write-protected in order to emulate an ISA ROM region) and so cannot be modified. Reported-by: Nikolai Zhubr <n-a-zhubr@yandex.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include Secure Boot Advanced Targeting (SBAT) metadatasbatMichael Brown2022-01-132-0/+4
| | | | | | | | | | | | | | | | | SBAT defines an encoding for security generation numbers stored as a CSV file within a special ".sbat" section in the signed binary. If a Secure Boot exploit is discovered then the generation number will be incremented alongside the corresponding fix. Platforms may then record the minimum generation number required for any given product. This allows for an efficient revocation mechanism that consumes minimal flash storage space (in contrast to the DBX mechanism, which allows for only a single-digit number of revocation events to ever take place across all possible signed binaries). Add SBAT metadata to iPXE EFI binaries to support this mechanism. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [doc] Update user-visible ipxe.org URIs to use HTTPSMichael Brown2022-01-132-3/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Generalise DSDT/SSDT data extraction logicMichael Brown2021-09-081-4/+66
| | | | | | | Allow for the DSDT/SSDT signature-scanning and value extraction code to be reused for extracting a pass-through MAC address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 14:13:06 +0000