summaryrefslogtreecommitdiffstats
path: root/src/interface/efi/efi_snp.c
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-141-0/+1
| | | | | | | | | | | | 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>
* [efi] Allow for creating devices with no EFI parent deviceMichael Brown2025-11-251-14/+13Star
| | | | | | | | | | | | | | On some systems (observed on an AWS m8g.medium instance in eu-west-2), the UEFI firmware fails to enumerate some of the underlying hardware devices. On these systems, we cannot comply with the UEFI device model by adding our SNP device as a child of the hardware device and appending to the parent hardware device path, since no parent hardware device has been created. Work around these systems by allowing for the creation of SNP devices with no parent device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow compiler to perform type checks on EFI_EVENTMichael Brown2025-07-151-1/+1
| | | | | | | | | | | | As with EFI_HANDLE, the EFI headers define EFI_EVENT as a void pointer, rendering EFI_EVENT compatible with a pointer to itself and hence guaranteeing that pointer type bugs will be introduced. Redefine EFI_EVENT as a pointer to an anonymous structure (as we already do for EFI_HANDLE) to allow the compiler to perform type checking as expected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_open_by_driver() for all by-driver protocol opensMichael Brown2025-03-241-20/+10Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove spurious close of SNP device parent's device pathMichael Brown2025-03-231-4/+0Star
| | | | | | | | | | Commit e727f57 ("[efi] Include a copy of the device path within struct efi_device") neglected to delete the closure of the parent's device path from the success code path in efi_snp_probe(). Reduce confusion by removing this (harmless) additional close. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allocate private data for each network upper-layer driverMichael Brown2023-09-131-3/+6
| | | | | | | | | | | | | | | | | 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>
* [netdevice] Separate concept of scope ID from network device name indexMichael Brown2023-01-141-2/+2
| | | | | | | | | | | | | | | | | | | | | The network device index currently serves two purposes: acting as a sequential index for network device names ("net0", "net1", etc), and acting as an opaque unique integer identifier used in socket address scope IDs. There is no particular need for these usages to be linked, and it can lead to situations in which devices are named unexpectedly. For example: if a system has two network devices "net0" and "net1", a VLAN is created as "net1-42", and then a USB NIC is connected, then the USB NIC will be named "net3" rather than the expected "net2" since the VLAN device "net1-42" will have consumed an index. Separate the usages: rename the "index" field to "scope_id" (matching its one and only use case), and assign the name without reference to the scope ID by finding the first unused name. For consistency, assign the scope ID by similarly finding the first unused scope ID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide VLAN configuration protocolMichael Brown2022-12-141-2/+177
| | | | | | | | | | | | | | | | | | | | | | | UEFI implements VLAN support within the Managed Network Protocol (MNP) driver, which may create child VLAN devices automatically based on stored UEFI variables. These child devices do not themselves provide a raw-packet interface via EFI_SIMPLE_NETWORK_PROTOCOL, and may be consumed only via the EFI_MANAGED_NETWORK_PROTOCOL interface. The device paths constructed for these child devices may conflict with those for the EFI_SIMPLE_NETWORK_PROTOCOL instances that iPXE attempts to install for its own VLAN devices. The upshot is that creating an iPXE VLAN device (e.g. via the "vcreate" command) will fail if the UEFI Managed Network Protocol has already created a device for the same VLAN tag. Fix by providing our own EFI_VLAN_CONFIG_PROTOCOL instance on the same device handle as EFI_SIMPLE_NETWORK_PROTOCOL. This causes the MNP driver to treat iPXE's device as supporting hardware VLAN offload, and it will therefore not attempt to install its own instance of the protocol. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Skip interface uninstallation during shutdownMichael Brown2020-12-171-4/+5
| | | | | | | | | | | | | | | | | | | | | | iPXE seems to be almost alone in the UEFI world in attempting to shut down cleanly, free resources, and leave hardware in a well-defined reset state before handing over to the booted operating system. The UEFI driver model does allow for graceful shutdown via uninstallation of protocol interfaces. However, virtually no other UEFI drivers do this, and the external code paths that react to uninstallation are consequently poorly tested. This leads to a proliferation of bugs found in UEFI implementations in the wild, as described in commits such as 1295b4a ("[efi] Allow initialisation via SNP interface even while claimed") or b6e2ea0 ("[efi] Veto the HP XhciDxe Driver"). Try to avoid triggering such bugs by unconditionally skipping the protocol interface uninstallation during UEFI boot services shutdown, leaving the interfaces present but nullified and deliberately leaking the containing memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Nullify interfaces unconditionally on error and shutdown pathsMichael Brown2020-12-171-8/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow initialisation via SNP interface even while claimedMichael Brown2020-11-231-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iPXE will currently fail all SNP interface methods with EFI_NOT_READY while the network devices are claimed for use by iPXE's own network stack. As of commit c70b3e0 ("[efi] Always enable recursion when calling ConnectController()"), this exposes latent UEFI firmware bugs on some systems at the point of calling ExitBootServices(). With recursion enabled, the MnpDxe driver will immediately attempt to consume the SNP protocol instance provided by iPXE. Since the network devices are claimed by iPXE at this point, the calls by MnpDxe to Start() and Initialize() will both fail with EFI_NOT_READY. This unfortunately triggers a broken error-handling code path in the Ip6Dxe driver. Specifically: Ip6DriverBindingStart() will call Ip6CreateService(), which will call Ip6ServiceConfigMnp(), which will return an error. The subsequent error handling code path in Ip6CreateService() simply calls Ip6CleanService(). The code in Ip6CleanService() will attempt to leave the all-nodes multicast group, which will fail since the group was never joined. This will result in Ip6CleanService() returning an error and omitting most of the required clean-up operations. In particular, the MNP protocol instance will remain opened with BY_DRIVER attributes even though the Ip6Dxe driver start method has failed. When ExitBootServices() is eventually called, iPXE will attempt to uninstall the SNP protocol instance. This results in the UEFI core calling Ip6DriverBindingStop(), which will fail since there is no EFI_IP6_SERVICE_BINDING_PROTOCOL instance installed on the handle. A failure during a call to UninstallMultipleProtocolInterfaces() will result in the UEFI core attempting to reinstall any successfully uninstalled protocols. This is an intrinsically unsafe operation, and represents a fundamental design flaw in UEFI. Failure code paths cannot be required to themselves handle failures, since there is no well-defined correct outcome of such a situation. With a current build of OVMF, this results in some unexpected debug messages occurring at the time that the loaded operating system calls ExitBootServices(). With the UEFI firmware in Hyper-V, the result is an immediate reboot. Work around these UEFI design and implementation flaws by allowing the calls to our EFI_SIMPLE_NETWORK_PROTOCOL instance's Start() and Initialize() methods to return success even when the network devices are claimed for exclusive use by iPXE. This is sufficient to allow MnpDxe to believe that it has successfully initialised the device, and thereby avoids the problematic failure code paths in Ip6Dxe. Debugged-by: Aaron Heusser <aaron_heusser@hotmail.com> Debugged-by: Pico Mitchell <pico@randomapplications.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid dropping below TPL as at entry to iPXEMichael Brown2020-11-201-33/+25Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iPXE will currently drop to TPL_APPLICATION whenever the current system time is obtained via currticks(), since the system time mechanism relies on a timer that can fire only when the TPL is below TPL_CALLBACK. This can cause unexpected behaviour if the system time is obtained in the middle of an API call into iPXE by external code. For example, MnpDxe sets up a 10ms periodic timer running at TPL_CALLBACK to poll the underling EFI_SIMPLE_NETWORK_PROTOCOL device for received packets. If the resulting poll within iPXE happens to hit a code path that requires obtaining the current system time (e.g. due to reception of an STP packet, which affects iPXE's blocked link timer), then iPXE will end up temporarily dropping to TPL_APPLICATION. This can potentially result in retriggering the MnpDxe periodic timer, causing code to be unexpectedly re-entered. Fix by recording the external TPL at any entry point into iPXE and dropping only as far as this external TPL, rather than dropping unconditionally to TPL_APPLICATION. The side effect of this change is that iPXE's view of the current system time will be frozen for the duration of any API calls made into iPXE by external code at TPL_CALLBACK or above. Since any such external code is already responsible for allowing execution at TPL_APPLICATION to occur, then this should not cause a problem in practice. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Nullify interfaces and leak memory on uninstallation failureMichael Brown2020-10-261-12/+44
| | | | | | | | | | | | | | | The UEFI specification allows uninstallation of a protocol interface to fail. There is no sensible way for code to react to this, since uninstallation is likely to be taking place on a code path that cannot itself fail (e.g. a code path that is itself a failure path). Where the protocol structure exists within a dynamically allocated block of memory, this leads to possible use-after-free bugs. Work around this unfortunate design choice by nullifying the protocol (i.e. overwriting the method pointers with no-ops) and leaking the memory containing the protocol structure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split efi_netdev_path() out to a separate functionMichael Brown2020-10-191-37/+4Star
| | | | | | | Provide efi_netdev_path() as a standalone function, to allow for reuse when constructing child device paths. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split device path functions out to efi_path.cMichael Brown2020-10-161-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix error handling path in efi_snp_probeIgnat Korchagin2019-01-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Current (simplified): 1. InstallMultipleProtocolInterfaces if err goto err_install_protocol_interface; 2. OpenProtocol(efi_nii_protocol_guid) if err goto err_open_nii; 3. OpenProtocol(efi_nii31_protocol_guid) if err goto err_open_nii31; 4. efi_child_add if err goto err_efi_child_add; ... err_efi_child_add: CloseProtocol(efi_nii_protocol_guid) <= should be efi_nii31_protocol_guid err_open_nii: <= should be err_open_nii31 CloseProtocol(efi_nii31_protocol_guid) <= should be efi_nii_protocol_guid err_open_nii31: <= should be err_open_nii UninstallMultipleProtocolInterfaces Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Exclude link-layer header length from MaxPacketSizeRob Taglang2018-07-071-1/+1
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Raise TPL within EFI_SIMPLE_NETWORK_PROTOCOL entry pointsMichael Brown2018-02-201-12/+81
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Run at TPL_CALLBACK to protect against UEFI timersMichael Brown2018-02-201-0/+12
| | | | | | | | | | | | | | | | | | | As noted in the comments, UEFI manages to combines the all of the worst aspects of both a polling design (inefficiency and inability to sleep until something interesting happens) and of an interrupt-driven design (the complexity of code that could be preempted at any time, thanks to UEFI timers). This causes problems in particular for UEFI USB keyboards: the keyboard driver calls UsbAsyncInterruptTransfer() to set up a periodic timer which is used to poll the USB bus. This poll may interrupt a critical section within iPXE, typically resulting in list corruption and either a hang or reboot. Work around this problem by mirroring the BIOS design, in which we run with interrupts disabled almost all of the time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Match behaviour of SnpDxe for truncated received packetsMichael Brown2017-09-071-13/+9Star
| | | | | | | | | | | | | The UEFI specification does not state whether or not a return value of EFI_BUFFER_TOO_SMALL from the SNP Receive() method should follow the usual EFI API behaviour of allowing the caller to retry the request with an increased buffer size. Examination of the SnpDxe driver in EDK2 suggests that Receive() will just return the truncated packet (complete with any requested link-layer header fields), so match this behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Check buffer length for packets retrieved via our SNP protocolMichael Brown2017-09-071-3/+14
| | | | | | | | | | | | We do not currently check the length of the caller's buffer for received packets. This creates a potential buffer overrun when iPXE is being used via the SNP or UNDI protocols. Fix by checking the buffer length and correctly returning the required length and an EFI_BUFFER_TOO_SMALL error. Reported-by: Paul McMillan <paul.mcmillan@oracle.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not copy garbage bytes into SNP device path MAC addressMichael Brown2016-06-221-1/+1
| | | | | | | | | | | | | | | | | | | | The SNP device path includes the network device's MAC address within the MAC_ADDR_DEVICE_PATH.MacAddress field. We check that the link-layer address will fit within this field, and then perform the copy using the length of the destination buffer. At 32 bytes, the MacAddress field is actually larger than the current maximum iPXE link-layer address. The copy therefore overflows the source buffer, resulting in trailing garbage bytes being appended to the device path's MacAddress. This is invisible in debug messages, since the DevicePathToText protocol will render only the length implied by the interface type. Fix by copying only the actual length of the link-layer address (which we have already verified will not overflow the destination buffer). Debugged-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include VLAN in SNP device path if applicableMichael Brown2016-06-181-2/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for EFI_GRAPHICS_OUTPUT_PROTOCOL frame buffer consolesMichael Brown2015-10-161-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose an UNDI interface alongside the existing SNP interfaceMichael Brown2015-09-281-23/+676
| | | | | | | | | | | | | | | | | | | | | | UEFI UNDI is a hideously ugly lump of poorly specified garbage bolted on as an appendix of the UEFI specification. My personal favourite line from the UNDI 'specification' is section E.2.2, which states "Basically, the rule is: Do it right, or don't do it at all". The author appears to believe that such exhortations are a viable substitute for documenting what it is that the wretched reader is supposed to, in fact, do. (Second favourite is the section listing the pros and cons of various driver types. This fails to identify a single con for the mythical "Hardware UNDI", a design so insanely intrinsically slow that it appears to have been the inspiration for the EFI_USB_IO_PROTOCOL.) UNDI is functionally isomorphic to the substantially less preposterous EFI_SIMPLE_NETWORK_PROTOCOL. Provide an UNDI interface (as a thin wrapper around the existing SNP interface) to allow for use by third-party software that has made poor life choices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include a copy of the device path within struct efi_deviceMichael Brown2015-09-131-22/+2Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide efi_devpath_len()Michael Brown2015-09-131-2/+1Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not return EFI_NOT_READY from our ReceiveFilters() methodMichael Brown2015-09-011-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Our SNP ReceiveFilters() method is a no-op, since we always (if possible) use promiscuous mode for all network cards. The method currently returns EFI_NOT_READY if the SNP interfaces are claimed for use by iPXE, as with all other SNP methods. The WDS bootstrap wdsmgfw.efi attempts to use both the PXE Base Code protocol and the Simple Network Protocol simultaneously. This is fundamentally broken, since use of the PXE Base Code protocol requires us to disable the use of SNP (by claiming the interfaces for use by iPXE), otherwise MnpDxe swallows all of the received packets before our PXE Base Code's UdpRead() method is able to return them. The root cause of this problem is that, as with BIOS PXE, the network booting portions of the UEFI specification are less of a specification and more of an application note sketchily describing how the original hacked-together Intel implementation works. No sane design would ever have included the UdpWrite() and UdpRead() methods. Work around these fundamental conceptual flaws by unconditionally returning success from efi_snp_receive_filters(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix order of events on SNP removal pathMichael Brown2015-09-011-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow calls to efi_snp_claim() and efi_snp_release() to be nestedMichael Brown2015-09-011-4/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove raw EFI_HANDLE values from debug messagesMichael Brown2015-08-271-11/+10Star
| | | | | | | | | The raw EFI_HANDLE value is almost never useful to know, and simply adds noise to the already verbose debug messages. Improve the legibility of debug messages by using only the name generated by efi_handle_name(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Allow self-tests to report exit status when running under LinuxMichael Brown2015-08-211-7/+5Star
| | | | | | | | | Allow the return status from an embedded image to propagate out to the eventual return status from main(). When running under Linux, this allows the pass/fail result of unit tests to be observable without having to visually inspect the console output. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Hold off watchdog timer while runningMichael Brown2015-08-031-0/+7
| | | | | | | | | | | | | | | | UEFI platforms may provide a watchdog timer, which will reboot the machine if an operating system takes more than five minutes to load. This can cause long-lived iPXE downloads (or interactive shell sessions) to unexpectedly reboot. Fix by resetting the watchdog timer every ten seconds while the iPXE main processing loop continues to run. Reported-by: Bradley B Williams <bradleybwilliams@swbell.net> Reported-by: John Clark <john.r.clark.3@gmail.com> Reported-by: wdriever@gmail.com Reported-by: Charlie Beima <cbeima@indiana.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow user experience to be downgradedMichael Brown2015-07-221-0/+34
| | | | | | | | | | | | | | | | | | | | | | | iPXE does not currently provide EFI_PXE_BASE_CODE_PROTOCOL: this causes failures when chainloading bootloaders such as shim.efi which assume that this protocol will be present. Provide the ability to work around these problems via the build configuration option EFI_DOWNGRADE_UX. If this option is enabled, then we will not install our usual EFI_LOAD_FILE_PROTOCOL implementation, thereby allowing the platform firmware to install its own EFI_PXE_BASE_CODE_PROTOCOL implementation on top of our EFI_SIMPLE_NETWORK_PROTOCOL handle. A somewhat major side-effect of this workaround is that almost all iPXE features will be disabled. This configuration option will be removed in future when support for EFI_PXE_BASE_CODE_PROTOCOL is added. Requested-by: Laszlo Ersek <lersek@redhat.com> Requested-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix receive and transmit completion reportingMichael Brown2015-07-221-66/+66
| | | | | | | | | | | | | | | | Fix the TxBuf value filled in by GetStatus() to report the transmit buffer address as required by the (now clarified) specification. Simplify "interrupt" handling in GetStatus() to report only that one or more packets have been transmitted or received; there is no need to report one GetStatus() "interrupt" per packet. Simplify receive handling to dequeue received packets immediately from the network device into an internal list (thereby avoiding the hacks previously used to determine when to report new packet arrivals). Originally-fixed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise definitions of more protocol GUIDsMichael Brown2014-09-251-14/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Move abstract device path and handle functions to efi_utils.cMichael Brown2014-08-061-5/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Open device path protocol only at point of useMichael Brown2014-08-061-12/+43
| | | | | | | | | | | | Some EFI 1.10 systems (observed on an Apple iMac) do not allow us to open the device path protocol with an attribute of EFI_OPEN_PROTOCOL_BY_DRIVER and so we cannot maintain a safe, long-lived pointer to the device path. Work around this by instead opening the device path protocol with an attribute of EFI_OPEN_PROTOCOL_GET_PROTOCOL whenever we need to use it. Debugged-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide centralised definitions of commonly-used GUIDsMichael Brown2014-08-061-16/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_handle_name() instead of efi_devpath_text() where applicableMichael Brown2014-07-311-2/+2
| | | | | | | | | | Using efi_devpath_text() is marginally more efficient if we already have the device path protocol available, but the mild increase in efficiency is not worth compromising the clarity of the pattern: DBGC ( device, "THING %p %s ...", device, efi_handle_name ( device ) ); Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Ignore failures when attempting to install SNP HII protocolMichael Brown2014-07-301-4/+8
| | | | | | | | HII seems to fail on several systems. Since it is non-essential, treat HII problems as non-fatal. Debugged-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Default to releasing network devices for use via SNPMichael Brown2014-07-301-30/+27Star
| | | | | | | | | | | | | | | | | | | | | | | | We currently treat network devices as available for use via the SNP API only if RX queue processing has been frozen. (This is similar in spirit to the way that RX queue processing is frozen for the network device currently exposed via the PXE API.) The default state of a freshly created network device is for the RX queue to not be frozen, and thus to be unavailable for use via SNP. This causes problems when devices are added through code paths other than _efidrv_start() (which explicitly releases devices for use via SNP). We don't actually need to freeze RX queue processing, since calls via the SNP API will always use netdev_poll() rather than net_poll(), and so will never trigger the RX queue processing code path anyway. We can therefore simplify the code to use a single global flag to indicate whether network devices are claimed for use by iPXE or available for use via SNP. Using a global flag allows the default state for dynamically created network devices to behave sensibly. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow network devices to be created on top of arbitrary SNP devicesMichael Brown2014-07-031-25/+40
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide a meaningful EFI SNP device nameMichael Brown2014-06-251-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Expose build timestamp, build name, and product namesMichael Brown2014-06-241-4/+4
| | | | | | | | Expose the build timestamp (measured in seconds since the Epoch) and the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the product name and product short name in a single centralised location. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disable SNP devices when running iPXE as the applicationMichael Brown2014-03-141-7/+126
| | | | | | | | | | | | | Some UEFI builds will set up a timer to continuously poll any SNP devices. This can drain packets from the network device's receive queue before iPXE gets a chance to process them. Use netdev_rx_[un]freeze() to explicitly indicate when we expect our network devices to be driven via the external SNP API (as we do with the UNDI API on the standard BIOS build), and disable the SNP API except when receive queue processing is frozen. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Perform meaningful error code conversionsMichael Brown2013-04-191-24/+18Star
| | | | | | | | Exploit the redefinition of iPXE error codes to include a "platform error code" to allow for meaningful conversion of EFI_STATUS values to iPXE errors and vice versa. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add our own EFI_LOAD_FILE_PROTOCOL implementationMichael Brown2013-03-141-1/+56
| | | | | | | | | | | | | When iPXE is used as a UEFI driver, the UEFI PXE base code currently provides the TCP/IP stack, network protocols, and user interface. This represents a substantial downgrade from the standard BIOS iPXE user experience. Fix by installing our own EFI_LOAD_FILE_PROTOCOL implementation which initiates the standard iPXE boot procedure. This upgrades the UEFI iPXE user experience to match the standard BIOS iPXE user experience. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add last_opened_snpdev()Michael Brown2013-03-131-0/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include product short name in EFI SNP device namesMichael Brown2012-11-211-3/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-07-30 07:59:09 +0200