iPXE UEFI vision

A large part of the success of iPXE has come from going beyond the constraints of the standard PXE model. Users choose iPXE because of its ability to perform tasks beyond the scope of a legacy PXE ROM: tasks such as booting via HTTP, booting via iSCSI, controlling the boot process with a script, creating dynamic menus, etc. Conformance to the PXE specification is a necessity, and is required in order for iPXE to be provided as an OEM PXE stack, but it is the more advanced features which make iPXE a success.

The push towards UEFI firmware currently represents a downgrade in the user experience of network booting. UEFI has adopted a model that is essentially identical to the legacy PXE specification. iPXE currently provides only a vanilla SNP interface within the UEFI environment, and the user experience is therefore limited to a standard UEFI network boot; the advanced features of iPXE (such as HTTP, DNS, scripting, etc) are not yet available.

From the end-user perspective, both an iPXE UEFI driver and an EDK2-based driver currently offer the same functionality.

Since this vision statement was written, the iPXE UEFI vision has mostly been implemented and the limitations described above are no longer applicable. An iPXE UEFI driver now provides a user experience which is almost as full-featured as the user experience provided by an iPXE BIOS driver.

iPXE will provide the same advanced features within the UEFI environment as are currently provided within the BIOS environment.

A UEFI iPXE option ROM will provide two entry points:

• An SNP driver. This is equivalent to the UNDI driver within the BIOS environment. It provides conformance with the UEFI specification in the same way that the UNDI driver provides conformance with the PXE specification.

• A “boot using iPXE” option within the system boot menu. This will provide access to the full iPXE feature set, and will appear almost identical to an iPXE boot within the BIOS environment. Features such as HTTP and scripting will be available, and users will be able to exploit their existing knowledge and investment in iPXE.

The guiding principle is that iPXE should go beyond the constraints of the standard UEFI model, in order to replicate the success that it has achieved by going beyond the constraints of the standard PXE model.

An iPXE UEFI option ROM will have the following advantages over a legacy EDK2 option ROM:

• An iPXE UEFI option ROM will provide all of the advanced features of iPXE, such as HTTP boot, scripting, DNS, and FCoE. A legacy EDK2 option ROM will provide only an SNP interface.

• An iPXE UEFI option ROM will work with users' existing iPXE scripts and boot infrastructure (web servers, script generators, certificate authorities, etc). A legacy EDK2 option ROM will require users to abandon their existing investment and create a new boot infrastructure.

• An iPXE UEFI option ROM will provide the advanced error reporting capabilities of iPXE. A legacy EDK2 option ROM will be limited to the standard UEFI error reporting capabilities. For example, an iPXE error message might read “Could not configure net0: Timed out (http://ipxe.org/4c106035)”, giving a URL containing problem-specific troubleshooting tips and contact details, while a standard UEFI error message might simply read “Timed out”.

• An iPXE UEFI option ROM will provide the advanced features of iPXE regardless of the limitations of the underlying firmware. A legacy EDK2 option ROM will be limited to supporting only those features implemented by the platform OEM. For example, if the platform OEM chooses not to support iSCSI then a legacy EDK2 option ROM will not be able to perform an iSCSI boot. Since iPXE includes its own iSCSI initiator, it will not suffer from this limitation.

• An iPXE UEFI option ROM will include its own TCP/IP stack, HTTP client, iSCSI initiator, etc, and so will not be affected by bugs in the underlying firmware implementations (if any) of these features. A legacy EDK2 option ROM will have to suffer from any bugs in the platform firmware, giving a poor user experience and increasing the support burden.

• An iPXE UEFI option ROM can have advanced features added (and bugs fixed) by reflashing only the option ROM, using existing vendor tools. With a legacy EDK2 option ROM, the only way to add or fix an advanced feature (such as iSCSI boot) is to reflash the whole platform firmware. Since the platform firmware is generally not open-source, the user will often be simply unable to perform such a fix.

• An iPXE UEFI option ROM uses the existing, well-proven iPXE codebase, and the driver code is shared between UEFI and BIOS builds. A legacy EDK2 option ROM requires an entirely separate codebase to be developed from scratch.

• An iPXE UEFI option ROM has a programming environment that conforms to relevant ANSI, ISO and POSIX standards, using standard C library functions such as malloc() and printf(). A legacy EDK2 option ROM has a non-standard proprietary programming environment using functions such as gBootServices->AllocatePool() and simpleTextOutputProtocol->OutputString().

• An iPXE UEFI option ROM driver will typically contain 50%-80% fewer lines of code than the equivalent (but less capable) legacy EDK2 option ROM driver.