summaryrefslogtreecommitdiffstats
path: root/src/hci
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'master' into openslxopenslxSimon Rettberg2026-01-2888-859/+1681
|\
| * [build] Mark more reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-143-0/+3
| | | | | | | | | | | | | | | | | | Mark dynamic keyboard map support and the "pciscan", "usbscan", and "time" commands as permitted for UEFI Secure Boot, on the basis that these features have previously been present in binaries signed by Microsoft. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-1413-0/+13
| | | | | | | | | | | | | | | | | | 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-1432-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * [console] Mark generated keymaps as permitted for Secure BootMichael Brown2026-01-1330-0/+30
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [cmdline] Show commands in alphabetical orderMichael Brown2025-08-0639-360/+83Star
| | | | | | | | | | | | | | | | | | | | | | | | | | Commands were originally ordered by functional group (e.g. keeping the image management commands together), with arrays used to impose a functionally meaningful order within the group. As the number of commands and functional groups has expanded over the years, this has become essentially useless as an organising principle. Switch to sorting commands alphabetically (using the linker table mechanism). Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [digest] Treat inability to acquire an image as a fatal errorMichael Brown2025-08-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | The "md5sum" and "sha1sum" commands were originally intended solely as debugging utilities, and would return success (with a warning message) even if the specified images did not exist. To minimise surprise and to be consistent with other commands, treat the inability to acquire an image as a fatal error. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [digest] Add "--set" option to store digest value in a settingMichael Brown2025-08-061-13/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the result of a digest calculation to be stored in a named setting. This allows for digest verification in scripts using e.g.: set expected:hexraw cb05def203386f2b33685d177d9f04e3e3d70dd4 sha1sum --set actual 1mb iseq ${expected} ${actual} || goto checksum_bad Note that digest verification alone cannot be used to set the trusted execution status of an image. The only way to mark an image as trusted is to use the "imgverify" command. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [digest] Add commands for all enabled digest algorithmsMichael Brown2025-08-061-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Add "sha256sum", "sha512sum", and similar commands. Include these new commands only when DIGEST_CMD is enabled in config/general.h and the corresponding algorithm is enabled in config/crypto.h. Leave "mdsum" and "sha1sum" included whenever only DIGEST_CMD is enabled, to avoid potentially breaking backwards compatibility with builds that disabled MD5 or SHA-1 as a TLS or X.509 digest algorithm, but would still have expected those commands to be present. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [uaccess] Reduce scope of included uaccess.h headerMichael Brown2025-04-301-0/+1
| | | | | | | | | | | | | | | | | | The uaccess.h header is no longer required for any code that touches external ("user") memory, since such memory accesses are now performed through pointer dereferences. Reduce the number of files including this header. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [uaccess] Remove redundant copy_from_user() and copy_to_user()Michael Brown2025-04-306-0/+6
| | | | | | | | | | | | | | Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [efi] Add ability to reboot to firmware setup menuMichael Brown2025-04-281-0/+6
| | | | | | | | | | | | | | Add the ability to reboot to the firmware setup menu (if supported) by setting the relevant value in the OsIndications variable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [reboot] Generalise warm reboot indicator to a flags bitmaskMichael Brown2025-04-281-1/+4
| | | | | | | | | | | | | | Allow for the possibility of additional reboot types by extending the reboot() function to use a flags bitmask rather than a single flag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [cmdline] Remove userptr_t from "digest" commandMichael Brown2025-04-251-16/+2Star
| | | | | | | | | | | | | | Simplify the implementation of the "digest" command by assuming that the entire image data can be passed directly to digest_update(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [uaccess] Remove user_to_phys() and phys_to_user()Michael Brown2025-04-211-1/+1
| | | | | | | | | | | | | | | | 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>
| * [fdt] Add the "fdt" commandMichael Brown2025-03-271-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | Allow a Flattened Device Tree blob (DTB) to be provided to a booted operating system using a script such as: #!ipxe kernel /images/vmlinuz console=ttyAMA0 initrd /images/initrd.img fdt /images/rk3566-radxa-zero-3e.dtb boot Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [menu] Allow a post-activity timeout to be definedMichael Brown2025-02-192-8/+18
| | | | | | | | | | | | | | | | | | Allow the "--retimeout" option to be used to specify a timeout value that will be (re)applied after each keypress activity. This allows script authors to ensure that a single (potentially accidental) keypress will not pause the boot process indefinitely. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [usb] Add "usbscan" command for iterating over USB devicesMichael Brown2024-10-171-0/+122
| | | | | | | | | | | | | | | | Implement a "usbscan" command as a direct analogy of the existing "pciscan" command, allowing scripts to iterate over all detected USB devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [image] Add the "imgdecrypt" commandMichael Brown2024-08-291-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the "imgdecrypt" command that can be used to decrypt a detached encrypted data image using a cipher key obtained from a separate CMS envelope image. For example: # Create non-detached encrypted CMS messages # openssl cms -encrypt -binary -aes-256-gcm -recip client.crt \ -in vmlinuz -outform DER -out vmlinuz.cms openssl cms -encrypt -binary -aes-256-gcm -recip client.crt \ -in initrd.img -outform DER -out initrd.img.cms # Detach data from envelopes (using iPXE's contrib/crypto/cmsdetach) # cmsdetach vmlinuz.cms -d vmlinuz.dat -e vmlinuz.env cmsdetach initrd.img.cms -d initrd.img.dat -e initrd.img.env and then within iPXE: #!ipxe imgfetch http://192.168.0.1/vmlinuz.dat imgfetch http://192.168.0.1/initrd.img.dat imgdecrypt vmlinuz.dat http://192.168.0.1/vmlinuz.env imgdecrypt initrd.img.dat http://192.168.0.1/initrd.img.env boot vmlinuz Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Remove the generalised widget user interface abstractionMichael Brown2024-06-213-220/+0Star
| | | | | | | | | | | | | | | | Remove the now-unused generalised text widget user interface, along with the associated concept of a widget set and the implementation of a read-only label widget. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [form] Reimplement the "login" user interfaceMichael Brown2024-06-211-61/+31Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite the code implementing the "login" user interface to use a predefined interactive form. The command "login" then becomes roughly equivalent to: #!ipxe form item username Username item --secret password Password present with the result that login form customisations (e.g. to add a Windows domain name) may be implemented within the scripting language. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [form] Add support for dynamically created interactive formsMichael Brown2024-06-212-0/+610
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for presenting a dynamic user interface as an interactive form, alongside the existing support for presenting a dynamic user interface as a menu. An interactive form may be used to allow a user to input (or edit) values for multiple settings on a single screen, as a user-friendly alternative to prompting for setting values via the "read" command. In the present implementation, all input fields must fit on a single screen (with no scrolling), and the only supported widget type is an editable text box. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [dynui] Add concept of a secret user interface itemMichael Brown2024-06-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For interactive forms, the concept of a secret value becomes meaningful (e.g. for password fields). Add a flag to indicate that an item represents a secret value, and allow this flag to be set via the "--secret" option of the "item" command. This flag has no meaning for menu items, but is silently accepted anyway to keep the code size minimal. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [dynui] Allow for multiple flags on a user interface itemMichael Brown2024-06-212-3/+6
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [dynui] Generalise mechanisms for looking up user interface itemsMichael Brown2024-06-201-32/+6Star
| | | | | | | | | | | | | | | | Generalise the ability to look up a dynamic user interface item by index or by shortcut key, to allow for reuse of this code for interactive forms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [dynui] Generalise the concept of a menu to a dynamic user interfaceMichael Brown2024-06-202-75/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently have an abstract model of a dynamic menu as a list of items, each of which has a name, a description, and assorted metadata such as a shortcut key. The "menu" and "item" commands construct representations in this abstract model, and the "choose" command then presents the items as a single-choice menu, with the selected item's name used as the output value. This same abstraction may be used to model a dynamic form as a list of editable items, each of which has a corresponding setting name, an optional description label, and assorted metadata such as a shortcut key. By defining a "form" command as an alias for the "menu" command, we could construct and present forms using commands such as: #!ipxe form Login to ${url} item username Username or email address item --secret password Password present or #!ipxe form Configure IPv4 networking for ${netX/ifname} item netX/ip IPv4 address item netX/netmask Subnet mask item netX/gateway Gateway address item netX/dns DNS server address present Reusing the same abstract model for both menus and forms allows us to minimise the increase in code size, since the implementation of the "form" and "item" commands is essentially zero-cost. Rename everything within the abstract data model from "menu" to "dynamic user interface" to reflect this generalisation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Allow tab key to be used to cycle through UI elementsMichael Brown2024-06-203-31/+52
| | | | | | | | | | | | | | | | | | | | | | Add support for wraparound scrolling and allow the tab key to be used to move forward through a list of elements, wrapping back around to the beginning of the list on overflow. This is mildly useful for a menu, and likely to be a strong user expectation for an interactive form. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Rename "item" command's first parameter from "label" to "name"Michael Brown2024-06-192-19/+19
| | | | | | | | | | | | | | | | | | | | | | Switch terminology for the "item" command from "item <label> <text>" to "item <name> <text>", in preparation for repurposing the "item" command to cover interactive forms as well as menus. Since this renaming affects only a positional parameter, it does not break compatibility with any existing scripts. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Split out msg() and alert() from settings UI codeMichael Brown2024-06-192-72/+115
| | | | | | | | | | | | | | | | | | | | | | The msg() and alert() functions currently defined in settings_ui.c provide a general-purpose facility for printing messages centred on the screen. Split this out to a separate file to allow for reuse by the form presentation code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Draw all widgets on the standard screenMichael Brown2024-06-185-20/+14Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The curses concept of a window has been supported but never actively used in iPXE since the mucurses library was first implemented in 2006. Simplify the code by removing the ability to place a widget set in a specified window, and instead use the standard screen for all drawing operations. This simplification allows the widget set parameter to be omitted for the draw_widget() and edit_widget() operations, since the only reason for its inclusion was to provide access to the specified window. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Provide a general concept of a text widget setMichael Brown2024-05-155-109/+296
| | | | | | | | | | | | | | | | | | Create a generic abstraction of a text widget, refactor the existing editable text box widget to use this abstraction, add an implementation of a non-editable text label widget, and generalise the login user interface to use this generic widget abstraction. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Fix semantics of replace_string() to match code commentsMichael Brown2024-04-171-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comments for replace_string() state that a successful return status guarantees that the dynamically allocated string pointer is no longer NULL (even if it was initially NULL and the replacement string is NULL or empty). This is relied upon by readline() to guarantee that it will always return a non-NULL string if successful. The code behaviour does not currently match this comment: an empty replacement string may result in a successful return status even if the (single-byte) allocation fails. Fix up the code behaviour to match the comments, and to additionally ensure that the edit history is filled in even in the event of an allocation failure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [hci] Use dynamically allocated buffers for editable stringsMichael Brown2024-04-155-129/+176
| | | | | | | | | | | | | | | | | | | | | | Editable strings currently require a fixed-size buffer, which is inelegant and limits the potential for creating interactive forms with a variable number of edit box widgets. Remove this limitation by switching to using a dynamically allocated buffer for editable strings and edit box widgets. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* | Merge branch 'aqc1xx' into openslxSimon Rettberg2024-04-121-5/+23
|\|
| * [block] Allow SAN boot device to be identified by filesystem labelMichael Brown2024-03-071-1/+6
| | | | | | | | | | | | | | Add a "--label" option that can be used to specify a filesystem label, to be matched against the FAT volume label. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [block] Allow SAN boot device to be identified by an extra filenameMichael Brown2024-03-071-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | Add an "--extra" option that can be used to specify an extra (non-boot) filename that must exist within the booted filesystem. Note that only files within the FAT-formatted bootable partition will be visible to this filter. Files within the operating system's root disk (e.g. "/etc/redhat-release") are not generally accessible to the firmware and so cannot be used as the existence check filter filename. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [block] Allow SAN boot device to be identified by UUIDMichael Brown2024-03-061-3/+7
| | | | | | | | | | | | | | Add a "--uuid" option which may be used to specify a boot device UUID, to be matched against the GPT partition GUID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [block] Allow for additional SAN boot parameters alongside filenameMichael Brown2024-03-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'master' into openslxSimon Rettberg2023-10-062-1/+132
|\|
| * [efi] Implement "shim" as a dummy command on non-EFI platformsMichael Brown2023-05-241-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "shim" command will skip downloading the shim binary (and is therefore a conditional no-op) if there is already a selected EFI image that can be executed directly via LoadImage()/StartImage(). This allows the same iPXE script to be used with Secure Boot either enabled or disabled. Generalise this further to provide a dummy "shim" command that is an unconditional no-op on non-EFI platforms. This then allows the same iPXE script to be used for BIOS, EFI with Secure Boot disabled, or EFI with Secure Boot enabled. The same effect could be achieved by using "iseq ${platform} efi" within the script, but this would complicate end-user documentation. To minimise the code size impact, the dummy "shim" command is a pure no-op that does not call parse_options() and so will ignore even standardised arguments such as "--help". Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [efi] Support versions of shim that perform SBAT verificationMichael Brown2023-05-231-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The UEFI shim implements a fairly nicely designed revocation mechanism designed around the concept of security generations. Unfortunately nobody in the shim community has thus far added the relevant metadata to the Linux kernel, with the result that current versions of shim are incapable of booting current versions of the Linux kernel. Experience shows that there is unfortunately no point in trying to get a fix for this upstreamed into shim. We therefore default to working around this undesirable behaviour by patching data read from the "SbatLevel" variable used to hold SBAT configuration. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [efi] Add "shim" commandMichael Brown2023-05-221-0/+112
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * [image] Generalise concept of selected imageMichael Brown2023-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'master' into openslxSimon Rettberg2023-04-041-3/+11
|\|
| * [params] Allow for arbitrary HTTP request headers to be specifiedMichael Brown2023-03-011-1/+9
| | | | | | | | | | | | | | | | | | | | | | 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-011-2/+2
| | | | | | | | | | | | | | | | 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>
* | Merge branch 'master' into openslxSimon Rettberg2022-10-211-7/+11
|\|
| * [pci] Check for wraparound in callers of pci_find_next()Michael Brown2022-09-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The semantics of the bus:dev.fn parameter passed to pci_find_next() are "find the first existent PCI device at this address or higher", with the caller expected to increment the address between finding devices. This does not allow the parameter to distinguish between the two cases "start from address zero" and "wrapped after incrementing maximal possible address", which could therefore lead to an infinite loop in the degenerate case that a device with address ffff:ff:1f.7 really exists. Fix by checking for wraparound in the caller (which is already responsible for performing the increment). Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [pci] Allow pci_find_next() to return non-zero PCI segmentsMichael Brown2022-09-151-7/+5Star
| | | | | | | | | | | | | | | | Separate the return status code from the returned PCI bus:dev.fn address, in order to allow pci_find_next() to be used to find devices with a non-zero PCI segment number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* | Merge branch 'master' into openslxSimon Rettberg2022-05-1135-327/+964
|\|