opengnsys_ipxe

Clone of ipxe replica repo

Go to file

Michael Brown 1295b4acff [efi] Allow initialisation via SNP interface even while claimed 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>		2020-11-23 22:30:04 +00:00
contrib	[coverity] Override assumptions about wcrtomb() and hmac_init()	2019-08-17 17:18:54 +01:00
src	[efi] Allow initialisation via SNP interface even while claimed	2020-11-23 22:30:04 +00:00
.travis.yml	[travis] Ensure that most recent tag is always available	2020-01-03 00:14:03 +01:00
COPYING	[legal] Update GPLv2 licence text	2015-02-26 17:59:53 +00:00
COPYING.GPLv2	[legal] Update GPLv2 licence text	2015-02-26 17:59:53 +00:00
COPYING.UBDL	[legal] Add support for the Unmodified Binary Distribution Licence	2015-03-02 12:07:14 +00:00
README	[doc] Re-add README file	2010-05-28 00:03:47 +01:00

README

iPXE README File

Quick start guide:

   cd src
   make

For any more detailed instructions, see http://ipxe.org