aboutsummaryrefslogtreecommitdiffstats
path: root/src/core
Commit message (Collapse)AuthorAgeFilesLines
* [cachedhcp] Retain cached DHCPACK after startup if not already consumedefivlanMichael Brown2022-12-221-4/+22
| | | | | | | | | | | | | | We currently free an unclaimed cached DHCPACK immediately after startup, in order to free up memory. This prevents the cached DHCPACK from being applied to a device that is created after startup, such as a VLAN device created via the "vcreate" command. Retain any unclaimed DHCPACK after startup to allow it to be matched against (and applied to) any device that gets created at runtime. Free the DHCPACK during shutdown if it still remains unclaimed, in order to exit with memory cleanly freed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Include VLAN tag in filter for applying cached DHCPACKMichael Brown2022-12-221-6/+22
| | | | | | | | | | | | | | | 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>
* [acpi] Expose system MAC address via ${sysmac} settingsysmacMichael Brown2022-06-101-0/+37
| | | | | | | | | | | | | | Expose the system MAC address (if any) via the ${sysmac} setting. This allows scripts to access the system MAC address even when iPXE has decided not to apply it to a network device (e.g. because the cached DHCPACK MAC address was selected in order to match the behaviour of a previous boot stage). The setting is named ${sysmac} rather than ${acpimac} in order to allow for forward compatibility with non-ACPI mechanisms that may exist in future for specifying a system MAC address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Allow cached DHCPACK to override a temporary MAC addresshwmacMichael Brown2022-05-231-9/+42
| | | | | | | | | | | | | | | | | | When running on a system with an ACPI-provided system-specific MAC address, iPXE will apply this address to an ECM or NCM USB NIC. If iPXE has been chainloaded from a previous stage that does not understand the ACPI MAC mechanism then this can result in iPXE using a different MAC address than the previous stage, which is surprising to users. Attempt to minimise surprise by allowing the MAC address found in a cached DHCPACK packet to override a temporary MAC address, if the DHCPACK MAC address matches the network device's permanent MAC address. When a previous stage has chosen to use the network device's permanent MAC address (e.g. because it does not understand the ACPI MAC mechanism), this will cause iPXE to make the same choice. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Support the "_RTXMAC_" format for ACPI-based MAC addressesMichael Brown2022-03-251-28/+125
| | | | | | | | | | | | | Some newer HP products expose the host-based MAC (HBMAC) address using an ACPI method named "RTMA" returning a part-binary string of the form "_RTXMAC_#<mac>#", where "<mac>" comprises the raw MAC address bytes. Extend the existing support to handle this format alongside the older "_AUXMAC_" format (which uses a base16-encoded MAC address). Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for the possibility of overriding ACPI tables at link timeMichael Brown2022-03-242-3/+21
| | | | | | | 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-0/+5
| | | | | | | 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>
* [utf8] Add ability to accumulate Unicode characters from UTF-8 bytesMichael Brown2022-03-011-0/+137
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support changing keyboard map at runtimeMichael Brown2022-02-162-2/+171
| | | | | | | | | | | | Provide the special keyboard map named "dynamic" which allows the active keyboard map to be selected at runtime via the ${keymap} setting, e.g.: #define KEYBOARD_MAP dynamic iPXE> set keymap uk Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Always process all settings applicatorsMichael Brown2022-02-161-7/+3
| | | | | | | | Settings applicators are entirely independent, and there is no reason why a failure in one applicator should prevent other applicators from being processed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Do not clear current working URI when executing embedded imageMichael Brown2022-02-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Embedded images do not have an associated URI. This currently causes the current working URI (cwuri) to be cleared when starting an embedded image. If the current working URI has been set via a ${next-server} setting from a cached DHCP packet then this will result in unexpected behaviour. An attempt by the embedded script to use a relative URI to download files from the TFTP server will fail with the error: Could not start download: Operation not supported (ipxe.org/3c092083) Rerunning the "dhcp" command will not fix this error, since the TFTP settings applicator will not see any change to the ${next-server} setting and so will not reset the current working URI. Fix by setting the current working URI to the image's URI only if the image actually has an associated URI. Debugged-by: Ignat Korchagin <ignat@cloudflare.com> Originally-fixed-by: Ignat Korchagin <ignat@cloudflare.com> Tested-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support AltGr to access ASCII characters via remappingMichael Brown2022-02-151-1/+4
| | | | | | | | | | | | | 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-151-6/+35
| | | | | | | 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] Allow for named keyboard mappingsMichael Brown2022-02-151-4/+10
| | | | | | | | Separate the concept of a keyboard mapping from a list of remapped keys, to allow for the possibility of supporting multiple keyboard mappings at runtime. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Handle remapping of scancode 86Michael Brown2022-02-101-0/+3
| | | | | | | | | | | | | | | | | 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] Generalise bios_keymap() as key_remap()Michael Brown2022-02-101-0/+52
| | | | | | | Allow the keyboard remapping functionality to be exposed to consoles other than the BIOS console. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Allow for relative URIs that include colons within the pathMichael Brown2022-01-131-5/+10
| | | | | | | | | | | | | | | | RFC3986 allows for colons to appear within the path component of a relative URI, but iPXE will currently parse such URIs incorrectly by interpreting the text before the colon as the URI scheme. Fix by checking for valid characters when identifying the URI scheme. Deliberately deviate from the RFC3986 definition of valid characters by accepting "_" (which was incorrectly used in the iPXE-specific "ib_srp" URI scheme and so must be accepted for compatibility with existing deployments), and by omitting the code to check for characters that are not used in any URI scheme supported by iPXE. Reported-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include Secure Boot Advanced Targeting (SBAT) metadatasbatMichael Brown2022-01-131-0/+30
| | | | | | | | | | | | | | | | | 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>
* [settings] Support formatting UUIDs as little-endian GUIDsMichael Brown2022-01-041-5/+18
| | | | | | | | | | | | | | | | | | The RFC4122 specification defines UUIDs as being in network byte order, but an unfortunately significant amount of (mostly Microsoft) software treats them as having the first three fields in little-endian byte order. In an ideal world, any server-side software that compares UUIDs for equality would perform an endian-insensitive comparison (analogous to comparing strings for equality using a case-insensitive comparison), and would therefore not care about byte order differences. Define a setting type name ":guid" to allow a UUID setting to be formatted in little-endian order, to simplify interoperability with server-side software that expects such a formatting. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Retain original encodings for path, query, and fragment fieldsMichael Brown2021-11-121-51/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iPXE decodes any percent-encoded characters during the URI parsing stage, thereby allowing protocol implementations to consume the raw field values directly without further decoding. When reconstructing a URI string for use in an HTTP request line, the percent-encoding is currently reapplied in a reversible way: we guarantee that our reconstructed URI string could be decoded to give the same raw field values. This technically violates RFC3986, which states that "URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent". Experiments show that several HTTP server applications will attach meaning to the choice of whether or not a particular character was percent-encoded, even when the percent-encoding is unnecessary from the perspective of parsing the URI into its component fields. Fix by storing the originally encoded substrings for the path, query, and fragment fields and using these original encoded versions when reconstructing a URI string. The path field is also stored as a decoded string, for use by protocols such as TFTP that communicate using raw strings rather than URI-encoded strings. All other fields (such as the username and password) continue to be stored only in their decoded versions since nothing ever needs to know the originally encoded versions of these fields. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for extraction of a MAC address from the DSDT/SSDTMichael Brown2021-09-091-0/+154
| | | | | | | | | | | | | | | | Some vendors provide a "system MAC address" within the DSDT/SSDT, to be used to override the MAC address for a USB docking station. A full implementation would require an ACPI bytecode interpreter, since at least one OEM allows the MAC address to be constructed by executable ACPI bytecode (rather than a fixed data structure). We instead attempt to extract a plausible-looking "_AUXMAC_#.....#" string that appears shortly after an "AMAC" or "MACA" signature. This should work for most implementations encountered in practice. Debugged-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Generalise DSDT/SSDT data extraction logicMichael Brown2021-09-081-64/+30
| | | | | | | 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>
* [efi] Record cached ProxyDHCPOFFER and PXEBSACK, if presentMichael Brown2021-07-271-45/+130
| | | | | | | | | | | | | | | | | | | Commit cd3de55 ("[efi] Record cached DHCPACK from loaded image's device handle, if present") added the ability for a chainloaded UEFI iPXE to reuse an IPv4 address and DHCP options previously obtained by a built-in PXE stack, without needing to perform a second DHCP request. Extend this to also record the cached ProxyDHCPOFFER and PXEBSACK obtained from the EFI_PXE_BASE_CODE_PROTOCOL instance installed on the loaded image's device handle, if present. This allows a chainloaded UEFI iPXE to reuse a boot filename or other options that were provided via a ProxyDHCP or PXE boot server mechanism, rather than by standard DHCP. Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Make URI schemes case-insensitiveMichael Brown2021-07-011-1/+2
| | | | | | | | | | | RFC 3986 section 3.1 defines URI schemes as case-insensitive (though the canonical form is always lowercase). Use strcasecmp() rather than strcmp() to allow for case insensitivity in URI schemes. Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Match standard prototype for putchar()Michael Brown2021-06-071-1/+4
| | | | | Reported-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [base64] Include terminating NUL within base64 character arrayMichael Brown2021-06-071-1/+1
| | | | | Reported-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cpio] Split out bzImage initrd CPIO header constructionMichael Brown2021-05-211-0/+85
| | | | | | | | | | | | iPXE will construct CPIO headers for images that have a non-empty command line, thereby allowing raw images (without CPIO headers) to be injected into a dynamically constructed initrd. This feature is currently implemented within the BIOS-only bzImage format support. Split out the CPIO header construction logic to allow for reuse in other contexts such as in a UEFI build. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Add strncasecmp()Michael Brown2021-05-181-1/+16
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Propagate trust flag to extracted archive imagesMichael Brown2021-05-121-0/+4
| | | | | | | | An extracted image is wholly derived from the original archive image. If the original archive image has been verified and marked as trusted, then this trust logically extends to any image extracted from it. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Allow single-member archive images to be executed transparentlyMichael Brown2021-05-121-0/+30
| | | | | | | | Provide image_extract_exec() as a helper method to allow single-member archive images (such as gzip compressed images) to be executed without an explicit "imgextract" step. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Add "imgextract" command for extracting archive imagesMichael Brown2021-05-081-0/+104
| | | | | | | | Add the concept of extracting an image from an archive (which could be a single-file archive such as a gzip-compressed file), along with an "imgextract" command to expose this functionality to scripts. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Provide image_set_len() utility functionMichael Brown2021-05-081-4/+21
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for platforms that provide ACPI tables individuallyMichael Brown2021-03-012-3/+3
| | | | | | | | | | | | | | | | The ACPI API currently expects platforms to provide access to a single contiguous ACPI table. Some platforms (e.g. Linux userspace) do not provide a convenient way to obtain the entire ACPI table, but do provide access to individual tables. All iPXE consumers of the ACPI API require access only to individual tables. Redefine the internal API to make acpi_find() an API method, with all existing implementations delegating to the current RSDT-based implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Eliminate redundant acpi_find_rsdt() in acpi_sx()Michael Brown2021-02-281-10/+2
| | | | | | | | The result from acpi_find_rsdt() is used only for the debug message. Simplify the debug message and remove the otherwise redundant call to acpi_find_rsdt(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Use a fixed colour for debug messagesMichael Brown2021-02-281-9/+12
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Split out platform-independent portions of cachedhcp.cMichael Brown2021-02-171-0/+158
| | | | | | | | | Split out the portions of cachedhcp.c that can be shared between BIOS and UEFI (both of which can provide a buffer containing a previously obtained DHCP packet, and neither of which provide a means to determine the length of this DHCP packet). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Provide image_memory()Michael Brown2021-01-251-0/+44
| | | | | | | Consolidate the remaining logic common to initrd_init() and imgmem() into a shared image_memory() function. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Provide image_set_data()Michael Brown2021-01-221-0/+24
| | | | | | | Extract part of the logic in initrd_init() to a standalone function image_set_data(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Provide intf_insert() to insert a filter interfaceMichael Brown2020-12-072-3/+18
| | | | | | | | Generalise the filter interface insertion logic from block_translate() and expose as intf_insert(), allowing a filter interface to be inserted on any existing interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Ignore any attempts to plug in the null interfaceMichael Brown2020-12-071-0/+5
| | | | | | | Allow intf_plug() and intf_plug_plug() to be called safely on interfaces that may be the null interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Provide dma_umalloc() for allocating large DMA-coherent buffersMichael Brown2020-11-291-0/+39
| | | | | | | | | | | | | | Some devices (e.g. xHCI USB host controllers) may require the use of large areas of host memory for private use by the device. These allocations cannot be satisfied from iPXE's limited heap space, and so are currently allocated using umalloc() which will allocate external system memory (and alter the system memory map as needed). Provide dma_umalloc() to provide such allocations as part of the DMA API, since there is otherwise no way to guarantee that the allocated regions are usable for coherent DMA. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Move I/O buffer DMA operations to iobuf.hMichael Brown2020-11-282-41/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Include a potential DMA mapping within the definition of an I/O buffer, and move all I/O buffer DMA mapping functions from dma.h to iobuf.h. This avoids the need for drivers to maintain a separate list of DMA mappings for each I/O buffer that they may handle. Network device drivers typically do not keep track of transmit I/O buffers, since the network device core already maintains a transmit queue. Drivers will typically call netdev_tx_complete_next() to complete a transmission without first obtaining the relevant I/O buffer pointer (and will rely on the network device core automatically cancelling any pending transmissions when the device is closed). To allow this driver design approach to be retained, update the netdev_tx_complete() family of functions to automatically perform the DMA unmapping operation if required. For symmetry, also update the netdev_rx() family of functions to behave the same way. As a further convenience for drivers, allow the network device core to automatically perform DMA mapping on the transmit datapath before calling the driver's transmit() method. This avoids the need to introduce a mapping error handling code path into the typically error-free transmit methods. With these changes, the modifications required to update a typical network device driver to use the new DMA API are fairly minimal: - Allocate and free descriptor rings and similar coherent structures using dma_alloc()/dma_free() rather than malloc_phys()/free_phys() - Allocate and free receive buffers using alloc_rx_iob()/free_rx_iob() rather than alloc_iob()/free_iob() - Calculate DMA addresses using dma() or iob_dma() rather than virt_to_bus() - Set a 64-bit DMA mask if needed using dma_set_mask_64bit() and thereafter eliminate checks on DMA address ranges - Either record the DMA device in netdev->dma, or call iob_map_tx() as part of the transmit() method - Ensure that debug messages use virt_to_phys() when displaying "hardware" addresses Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Record DMA device as part of DMA mapping if neededMichael Brown2020-11-281-26/+26
| | | | | | | Allow for dma_unmap() to be called by code other than the DMA device driver itself. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Modify DMA API to simplify calculation of medial addressesMichael Brown2020-11-251-0/+2
| | | | | | | | | | | | | | | | | Redefine the value stored within a DMA mapping to be the offset between physical addresses and DMA addresses within the mapped region. Provide a dma() wrapper function to calculate the DMA address for any pointer within a mapped region, thereby simplifying the use cases when a device needs to be given addresses other than the region start address. On a platform using the "flat" DMA implementation the DMA offset for any mapped region is always zero, with the result that dma_map() can be optimised away completely and dma() reduces to a straightforward call to virt_to_phys(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Define a DMA API to allow for non-flat device address spacesMichael Brown2020-11-051-0/+179
| | | | | | | | | | | | | | | | | | | iPXE currently assumes that DMA-capable devices can directly address physical memory using host addresses. This assumption fails when using an IOMMU. Define an internal DMA API with two implementations: a "flat" implementation for use in legacy BIOS or other environments in which flat physical addressing is guaranteed to be used and all allocated physical addresses are guaranteed to be within a 32-bit address space, and an "operations-based" implementation for use in UEFI or other environments in which DMA mapping may require bus-specific handling. The purpose of the fully inlined "flat" implementation is to allow the trivial identity DMA mappings to be optimised out at build time, thereby avoiding an increase in code size for legacy BIOS builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [malloc] Rename malloc_dma() to malloc_phys()Michael Brown2020-11-052-8/+8
| | | | | | | | | | | | The malloc_dma() function allocates memory with specified physical alignment, and is typically (though not exclusively) used to allocate memory for DMA. Rename to malloc_phys() to more closely match the functionality, and to create name space for functions that specifically allocate and map DMA-capable buffers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Fix memcmp() to return proper valuesMichael J. Bazzinotti2020-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Fix memcmp() to return proper standard positive/negative values for unequal comparisons. Current implementation is backwards (i.e. the functions are returning negative when should be positive and vice-versa). Currently most consumers of these functions only check the return value for ==0 or !=0 and so we can safely change the implementation without breaking things. However, there is one call that checks the polarity of this function, and that is prf_sha1() for wireless WPA 4-way handshake. Due to the incorrect memcmp() polarity, the WPA handshake creates an incorrect PTK, and the handshake would fail after step 2. Undoubtedly, the AP noticed the supplicant failed the mic check. This commit fixes that issue. Similar to commit 3946aa9 ("[libc] Fix strcmp()/strncmp() to return proper values"). Signed-off-by: Michael Bazzinotti <bazz@bazz1.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xfer] Remove address family from definition of a socket openerMichael Brown2020-07-151-3/+1
| | | | | | | | All implemented socket openers provide definitions for both IPv4 and IPv6 using exactly the same opener method. Simplify the logic by omitting the address family from the definition. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Provide an unoptimised generic_memcpy_reverse()Michael Brown2020-07-071-5/+20
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [parseopt] Treat empty integer strings in user input as invalidMichael Brown2020-06-191-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-24 18:38:47 +0000