summaryrefslogtreecommitdiffstats
path: root/src/include/ipxe/errfile.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'master' into openslxopenslxSimon Rettberg2024-04-121-1/+4
|\
| * [efi] Add support for driving EFI_MANAGED_NETWORK_PROTOCOL devicesMichael Brown2024-03-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want exclusive access to the network device, both for performance reasons and because we perform operations such as EAPoL that affect the entire link. We currently drive the network card via either a native hardware driver or via the SNP or NII/UNDI interfaces, both of which grant us this exclusive access. Add an alternative driver that drives the network card non-exclusively via the EFI_MANAGED_NETWORK_PROTOCOL interface. This can function as a fallback for situations where neither SNP nor NII/UNDI interfaces are functional, and also opens up the possibility of non-destructively installing a temporary network device over which to download the autoexec.ipxe script. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [efi] Add helper functions for service binding protocolsMichael Brown2024-03-251-0/+1
| | | | | | | | | | | | | | | | The EFI service binding abstraction is used to add and remove child handles for multiple different protocols. Provide a common interface for doing so. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [efi] Provide a multiprocessor API for EFIMichael Brown2024-03-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Provide an implementation of the iPXE multiprocessor API for EFI, based on using EFI_MP_SERVICES to start up a wrapper function on all application processors. Note that the processor numbers used by EFI_MP_SERVICES are opaque integers that bear no relation to the underlying CPU identity (e.g. the APIC ID), and so we must rely on our own (architecture- specific) implementation to determine the relevant CPU identifiers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* | Merge branch 'ipxe:master' into aqc1xxanimeshbm2024-03-141-0/+6
|\|
| * [efi] Add efi_path_guid() utility functionMichael Brown2024-03-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | EFI provides no API for determining the partition GUID (if any) for a specified device handle. The partition GUID appears to be exposed only as part of the device path. Add efi_path_guid() to extract the partition GUID (if any) from a device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [uuid] Add uuid_aton() to parse a UUID from a stringMichael Brown2024-02-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Add uuid_aton() to parse a UUID value from a string (analogous to inet_aton(), inet6_aton(), sock_aton(), etc), treating it as a 32-digit hex string with optional hyphen separators. The placement of the separators is not checked: each byte within the hex string may be separated by a hyphen, or not separated at all. Add dedicated self-tests for UUID parsing and formatting (already partially covered by the ":uuid" and ":guid" settings self-tests). Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [eap] Add support for the MS-CHAPv2 authentication methodMichael Brown2024-02-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for EAP-MSCHAPv2 (note that this is not the same as PEAP-MSCHAPv2), controllable via the build configuration option EAP_METHOD_MSCHAPV2 in config/general.h. Our model for EAP does not encompass mutual authentication: we will starting sending plaintext packets (e.g. DHCP requests) over the link even before EAP completes, and our only use for an EAP success is to mark the link as unblocked. We therefore ignore the content of the EAP-MSCHAPv2 success request (containing the MS-CHAPv2 authenticator response) and just send back an EAP-MSCHAPv2 success response, so that the EAP authenticator will complete the process and send through the real EAP success packet (which will, in turn, cause us to unblock the link). Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [eap] Allow MD5-Challenge authentication method to be disabledMichael Brown2024-02-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | RFC 3748 states that implementations must support the MD5-Challenge method. However, some network environments may wish to disable it as a matter of policy. Allow support for MD5-Challenge to be controllable via the build configuration option EAP_METHOD_MD5 in config/general.h. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Add implementation of the DES cipherMichael Brown2024-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The DES block cipher dates back to the 1970s. It is no longer relevant for use in TLS cipher suites, but it is still used by the MS-CHAPv2 authentication protocol which remains unfortunately common for 802.1x port authentication. Add an implementation of the DES block cipher, complete with the extremely comprehensive test vectors published by NBS (the precursor to NIST) in the form of an utterly adorable typewritten and hand-drawn paper document. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Check for all-zeros result from X25519 key exchangeMichael Brown2024-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | RFC7748 states that it is entirely optional for X25519 Diffie-Hellman implementations to check whether or not the result is the all-zero value (indicating that an attacker sent a malicious public key with a small order). RFC8422 states that implementations in TLS must abort the handshake if the all-zero value is obtained. Return an error if the all-zero value is obtained, so that the TLS code will not require knowledge specific to the X25519 curve. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* | support for aqc113Animesh Bhatt2023-07-031-0/+4
|/
* [efi] Provide read-only access to EFI variables via settings mechanismMichael Brown2023-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | EFI variables do not map neatly to the iPXE settings mechanism, since the EFI variable identifier includes a namespace GUID that cannot cleanly be supplied as part of a setting name. Creating a new EFI variable requires the variable's attributes to be specified, which does not fit within iPXE's settings concept. However, EFI variable names are generally unique even without the namespace GUID, and EFI does provide a mechanism to iterate over all existent variables. We can therefore provide read-only access to EFI variables by comparing only the names and ignoring the namespace GUIDs. Provide an "efi" settings block that implements this mechanism using a syntax such as: echo Platform language is ${efi/PlatformLang:string} show efi/SecureBoot:int8 Settings are returned as raw binary values by default since an EFI variable may contain boolean flags, integer values, ASCII strings, UCS-2 strings, EFI device paths, X.509 certificates, or any other arbitrary blob of data. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for executing images via a shimMichael Brown2023-05-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Add support for using a shim as a helper to execute an EFI image. When a shim has been specified via shim(), the shim image will be passed to LoadImage() instead of the selected EFI image and the command line will be prepended with the name of the selected EFI image. The selected EFI image will be accessible to the shim via the virtual filesystem as a hidden file. Reduce the Secure Boot attack surface by removing, where possible, the spurious requirement for a third party second stage loader binary such as GRUB to be used solely in order to call the "shim lock protocol" entry point. Do not install the EFI PXE APIs when using a shim, since if shim finds EFI_PXE_BASE_CODE_PROTOCOL on the loaded image's device handle then it will attempt to download files afresh instead of using the files already downloaded by iPXE and exposed via the EFI_SIMPLE_FILE_SYSTEM protocol. (Experience shows that there is no point in trying to get a fix for this upstreamed into shim.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_asprintf() and efi_vasprintf()Michael Brown2023-05-221-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split out EFI_RNG_PROTOCOL as a separate entropy sourceMichael Brown2023-02-201-0/+1
| | | | | | | | | | | | | | | | | | Commit 7ca801d ("[efi] Use the EFI_RNG_PROTOCOL as an entropy source if available") added EFI_RNG_PROTOCOL as an alternative entropy source via an ad-hoc mechanism specific to efi_entropy.c. Split out EFI_RNG_PROTOCOL to a separate entropy source, and allow the entropy core to handle the selection of RDRAND, EFI_RNG_PROTOCOL, or timer ticks as the active source. The fault detection logic added in commit a87537d ("[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementations") may be removed completely, since the failure will already be detected by the generic ANS X9.82-mandated repetition count test and will now be handled gracefully by the entropy core. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lldp] Add support for the Link Layer Discovery ProtocolMichael Brown2023-02-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for recording LLDP packets and exposing TLV values via the settings mechanism. LLDP settings are encoded as ${netX.lldp/<prefix>.<type>.<index>.<offset>.<length>} where <type> is the TLV type <offset> is the starting offset within the TLV value <length> is the length (or zero to read the from <offset> to the end) <prefix>, if it has a non-zero value, is the subtype byte string of length <offset> to match at the start of the TLV value, up to a maximum matched length of 4 bytes <index> is the index of the entry matching <type> and <prefix> to be accessed, with zero indicating the first matching entry The <prefix> is designed to accommodate both matching of the OUI within an organization-specific TLV (e.g. 0x0080c2 for IEEE 802.1 TLVs) and of a subtype byte as found within many TLVs. This encoding allows most LLDP values to be extracted easily. For example System name: ${netX.lldp/5.0.0.0:string} System description: ${netX.lldp/6.0.0.0:string} Port description: ${netX.lldp/4.0.0.0:string} Port interface name: ${netX.lldp/5.2.0.1.0:string} Chassis MAC address: ${netX.lldp/4.1.0.1.0:hex} Management IPv4 address: ${netX.lldp/5.1.8.0.2.4:ipv4} Port VLAN ID: ${netX.lldp/0x0080c2.1.127.0.4.2:int16} Port VLAN name: ${netX.lldp/0x0080c2.3.127.0.7.0:string} Maximum frame size: ${netX.lldp/0x00120f.4.127.0.4.2:uint16} Originally-implemented-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Accept a command line passed to an iPXE image via LoadOptionsMichael Brown2023-01-291-0/+1
| | | | | | | | | Treat a command line passed to iPXE via UEFI LoadOptions as an image to be registered at startup, as is already done for the .lkrn, .pxe, and .exe BIOS images. Originally-implemented-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add Ephemeral Diffie-Hellman key exchange algorithmMichael Brown2022-10-111-0/+1
| | | | | | | | Add an implementation of the Ephemeral Diffie-Hellman key exchange algorithm as defined in RFC2631, with test vectors taken from the NIST Cryptographic Toolkit. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add minimal PCI bridge driverMichael Brown2022-09-191-0/+1
| | | | | | | Add a minimal driver for PCI bridges that can be used to locate the bridge to which a PCI device is attached. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for the Enhanced Configuration Access Mechanism (ECAM)Michael Brown2022-09-161-0/+1
| | | | | | | | | | | | | The ACPI MCFG table describes a direct mapping of PCI configuration space into MMIO space. This mapping allows access to extended configuration space (up to 4096 bytes) and also provides for the existence of multiple host bridges. Add support for the ECAM mechanism described by the ACPI MCFG table, as a selectable PCI I/O API alongside the existing PCI BIOS and Type 1 mechanisms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Check for wraparound in callers of pci_find_next()Michael Brown2022-09-151-0/+1
| | | | | | | | | | | | | | | | 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>
* [intelxl] Add driver for Intel 100 Gigabit Ethernet NICsMichael Brown2022-08-121-0/+1
| | | | | | | | | | | | | | | Add a driver for the E810 family of 100 Gigabit Ethernet NICs. The core datapath is identical to that of the 40 Gigabit XL710, and this part of the code is shared between both drivers. The admin queue mechanism is sufficiently similar to make it worth reusing substantial portions of the code, with separate implementations for several commands to handle the (unnecessarily) breaking changes in data structure layouts. The major differences are in the mechanisms for programming queue contexts (where the E810 abandons TX/RX symmetry) and for configuring the transmit scheduler and receive filters: these portions are sufficiently different to justify a separate driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support changing keyboard map at runtimeMichael Brown2022-02-161-0/+1
| | | | | | | | | | | | 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>
* [acpi] Allow for extraction of a MAC address from the DSDT/SSDTMichael Brown2021-09-091-0/+1
| | | | | | | | | | | | | | | | 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>
* [rdc] Add driver for RDC R6040 embedded NICMichael Brown2021-06-281-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gzip] Add support for gzip archive imagesMichael Brown2021-05-081-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [zlib] Add support for zlib archive imagesMichael Brown2021-05-081-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Add "imgextract" command for extracting archive imagesMichael Brown2021-05-081-0/+1
| | | | | | | | 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>
* [linux] Validate length of ACPI table read from sysfsMichael Brown2021-03-031-0/+1
| | | | | | | | | | | | | Consumers of acpi_find() will assume that returned structures include a valid table header and that the length in the table header is correct. These assumptions are necessary when dealing with raw ACPI tables, since there exists no independent source of length information. Ensure that these assumptions are also valid for ACPI tables read from sysfs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Add a generic function for reading files from sysfsMichael Brown2021-03-031-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [slirp] Add libslirp driver for LinuxMichael Brown2021-03-021-0/+1
| | | | | | | | | | | | | | | | | | | Add a driver using libslirp to provide a virtual network interface without requiring root permissions on the host. This simplifies the process of running iPXE as a Linux userspace application with network access. For example: make bin-x86_64-linux/slirp.linux ./bin-x86_64-linux/slirp.linux --net slirp libslirp will provide a built-in emulated DHCP server and NAT router. Settings such as the boot filename may be controlled via command-line options. For example: ./bin-x86_64-linux/slirp.linux \ --net slirp,filename=http://192.168.0.1/boot.ipxe Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Record cached DHCPACK from loaded image's device handle, if presentMichael Brown2021-02-171-0/+1
| | | | | | | | | | | Record the cached DHCPACK 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 the IPv4 address and DHCP options previously obtained by the built-in PXE stack, as is already done for a chainloaded BIOS iPXE. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split out autoexec script portions of efi_autoboot.cMichael Brown2021-02-171-0/+1
| | | | | | | | | | | The "autoboot device" and "autoexec script" functionalities in efi_autoboot.c are unrelated except in that they both need to be invoked by efiprefix.c before device drivers are loaded. Split out the autoexec script portions to a separate file to avoid potential confusion. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Split out platform-independent portions of cachedhcp.cMichael Brown2021-02-171-0/+1
| | | | | | | | | 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>
* [efi] Automatically load "/autoexec.ipxe" when booted from a filesystemMichael Brown2021-01-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When booting iPXE from a filesystem (e.g. a FAT-formatted USB key) it can be useful to have an iPXE script loaded automatically from the same filesystem. Compared to using an embedded script, this has the advantage that the script can be edited without recompiling the iPXE binary. For the BIOS version of iPXE, loading from a filesystem is handled using syslinux (or isolinux) which allows the script to be passed to the iPXE .lkrn image as an initrd. For the UEFI version of iPXE, the platform firmware loads the iPXE .efi image directly and there is currently no equivalent of the BIOS initrd mechanism. Add support for automatically loading a file "autoexec.ipxe" (if present) from the root of the filesystem containing the UEFI iPXE binary. A combined BIOS and UEFI image for a USB key can be created using e.g. ./util/genfsimg -o usbkey.img -s myscript.ipxe \ bin-x86_64-efi/ipxe.efi bin/ipxe.lkrn The file "myscript.ipxe" would appear as "autoexec.ipxe" on the USB key, and would be loaded automatically on both BIOS and UEFI systems. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eap] Treat an EAP Request-Identity as indicating a blocked linkMichael Brown2021-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A switch port using 802.1x authentication will send EAP Request-Identity packets once the physical link is up, and will not be forwarding packets until the port identity has been established. We do not currently support 802.1x authentication. However, a reasonably common configuration involves using a preset list of permitted MAC addresses, with the "authentication" taking place between the switch and a RADIUS server. In this configuration, the end device does not need to perform any authentication step, but does need to be prepared for the switch port to fail to forward packets for a substantial time after physical link-up. This exactly matches the "blocked link" semantics already used when detecting a non-forwarding switch port via LACP or STP. Treat a received EAP Request-Identity as indicating a blocked link. Unlike LACP or STP, there is no way to determine the expected time until the next EAP packet and so we must choose a fixed timeout. Erroneously assuming that the link is blocked is relatively harmless since we will still attempt to transmit and receive data even over a link that is marked as blocked, and so the net effect is merely to prolong DHCP attempts. In contrast, erroneously assuming that the link is unblocked will potentially cause DHCP to time out and give up, resulting in a failed boot. The default EAP Request-Identity interval in Cisco switches (where this is most likely to be encountered in practice) is 30 seconds, so choose 45 seconds as a timeout that is likely to avoid gaps during which we falsely assume that the link is unblocked. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iphone] Add iPhone tethering driverMichael Brown2020-12-161-0/+1
| | | | | | | | | USB tethering via an iPhone is unreasonably complicated due to the requirement to perform a pairing operation that involves establishing a TLS session over a completely unrelated USB function that speaks a protocol that is almost, but not quite, entirely unlike TCP. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Rename efi_blacklist to efi_vetoMichael Brown2020-11-081-1/+1
| | | | 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/+1
| | | | | | | | | | | | | | | | | | | 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>
* [usbblk] Add support for USB mass storage devicesMichael Brown2020-10-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Some UEFI BIOSes (observed with at least the Insyde UEFI BIOS on a Microsoft Surface Go) provide a very broken version of the UsbMassStorageDxe driver that is incapable of binding to the standard EFI_USB_IO_PROTOCOL instances and instead relies on an undocumented proprietary protocol (with GUID c965c76a-d71e-4e66-ab06-c6230d528425) installed by the platform's custom version of UsbCoreDxe. The upshot is that USB mass storage devices become inaccessible once iPXE's native USB host controller drivers are loaded. One possible workaround is to load a known working version of UsbMassStorageDxe (e.g. from the EDK2 tree): this driver will correctly bind to the standard EFI_USB_IO_PROTOCOL instances exposed by iPXE. This workaround is ugly in practice, since it involves embedding UsbMassStorageDxe.efi into the iPXE binary and including an embedded script to perform the required "chain UsbMassStorageDxe.efi". Provide a native USB mass storage driver for iPXE, allowing USB mass storage devices to be exposed as iPXE SAN devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Add ability to parse a MAC address from a flattened device treeMichael Brown2019-07-191-0/+1
| | | | | | | | | | | | | The Raspberry Pi NIC has no EEPROM to hold the MAC address. The platform firmware (e.g. UEFI or U-Boot) will typically obtain the MAC address from the VideoCore firmware and add it to the device tree, which is then made available to subsequent programs such as iPXE or the Linux kernel. Add the ability to parse a flattened device tree and to extract the MAC address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Add driver for Intel 40 Gigabit Ethernet NIC virtual functionsMichael Brown2019-04-271-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for PCI MSI-X interruptsMichael Brown2019-04-241-0/+1
| | | | | | | | | | | | | | | | | The Intel 40 Gigabit Ethernet virtual functions support only MSI-X interrupts, and will write back completed interrupt descriptors only when the device attempts to raise an interrupt (or when a complete cacheline of receive descriptors has been completed). We cannot actually use MSI-X interrupts within iPXE, since we never have ownership of the APIC. However, an MSI-X interrupt is fundamentally just a DMA write of a single dword to an arbitrary address. We can therefore configure the device to "raise" an interrupt by writing a meaningless value to an otherwise unused memory location: this is sufficient to trigger the receive descriptor writeback logic. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Blacklist the Dell Ip4ConfigDxe driverMichael Brown2019-02-191-0/+1
| | | | | | | | | | | | | | | | | | On a Dell OptiPlex 7010, calling DisconnectController() on the LOM device handle will lock up the system. Debugging shows that execution is trapped in an infinite loop that is somehow trying to reconnect drivers (without going via ConnectController()). The problem can be reproduced in the UEFI shell with no iPXE code present, by using the "disconnect" command. Experimentation shows that the only fix is to unload (rather than just disconnect) the "Ip4ConfigDxe" driver. Add the concept of a blacklist of UEFI drivers that will be automatically unloaded when iPXE runs as an application, and add the Dell Ip4ConfigDxe driver to this blacklist. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Add driver for Intel 40 Gigabit Ethernet NICsMichael Brown2018-07-171-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [icplus] Add driver for IC+ network cardSylvie Barlow2018-04-201-0/+1
| | | | | Signed-off-by: Sylvie Barlow <sylvie.c.barlow@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Add driver for Amazon ENA virtual function NICMichael Brown2018-01-131-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [http] Add support for NTLM authenticationMichael Brown2017-11-121-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ntlm] Add support for NTLM authentication mechanismMichael Brown2017-11-121-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>