Earlier blogs have described the UEFI stack and network booting. This entry will talk about configuration of the boot environment.
Specifically, how do you configure a server to provide a netboot6-based image? SUSE has written a helpful document on configuring a Linux server to support this usage at http://www.novell.com/docrep/2012/12/sles_11_sp2_for_uefi_client_best_practices_white_paper.pdf.
Recall that Netboot6 is a combination of the wire protocol defined in both RFC 5970 http://tools.ietf.org/html/rfc5970 and chapter 21.3.1 of the Unified Extensible Firmware Interface 2.4 specification http://www.uefi.org. The UEFI client machine uses DHCP as a control channel to expose its machine type and other parameters as it attempts to initiate a network boot. This is referred to as 'client initiated' network boot, as opposed to 'server initiated.' Examples of the latter include Intel(R) Active Management Technology (AMT) Integrated Disk Electronics Redirection (IDE-R), or exposing the local hardware network disk interface to the management console for purposes of the management control provisioning a disk image http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fsetsoliderandotherbootoptions.htm. An implementation of Netboot6 can be found at https://svn.code.sf.net/p/edk2/code/trunk/edk2/NetworkPkg/UefiPxeBcDxe/ in order to demonstrate a client-initiated download.
For client-initiated network bootstrap art like Netboot6, what are the details of the parameters? The most important parameter entails the architecture type of the .efi image that the boot server needs to provide. The client machine that has initiated the network boot needs to expose its execution mode to the boot server so that the appropriate boot image can be returned. Recall that UEFI supports EBC, Itanium, ARM 32, ARM 64, Intel 32-bit, and Intel 64-bit. This list may grow over time with corresponding updates to the UEFI Specification of machine bindings. Beyond a UEFI-style boot, some of my co-authors on 5970 worked for IBM and wanted to network boot a system software image over 1) HTTP and 2) not based upon UEFI technology. As such, the parameters at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml cover both UEFI and non-UEFI, with the latter class including PC/AT BIOS and both PowerPC Open Firmware and Power PC ePAPR, respectively.
So RFC 5970 can be used in scenarios beyond Netboot6's TFTP-based download. This is enabled by the architecture type field extensibility, and also by the fact that the boot image is described by a URI, not a simple name with an implied download wire application protocol of TFTP as found in PXE2.1 IPV4 usages.
A way to explain this further can be done by examining our Linux configuration use case. In Linux, the DHCP server actions are performed by the dhcpd, or "Domain Host Controller Protocol Daemon." The daemon is parameterized by the file dhcpd.conf.
Within dhcpd.conf we enable Netboot6 by way of the following lines:
option dhcp6.client-arch-type code 61 = array of unsigned integer 16;
if option dhcp6.client-arch-type = 00:07 {
option dhcp6.bootfile-url "tftp://[fc00:ba49:1625:fb0f::137]/bootx64.efi";
} else {
option dhcp6.bootfile-url "tftp://[fc00:ba49:1625:fb0f::137]/bootia32.efi";
}
The notable aspects are 'arch type' field and then the 'tftp' term. The bootx64.efi or bootia32.efi program, also known as the Network Boot Program (NBP), when executed on the local client (hopefully with UEFI Secure Boot logic applied prior to passing control into the image) can use any of the UEFI networking API's in the protocols defined in the UEFI Spec to download further .efi images, data files, or the operating system kernel. The device path protocol on the loaded image protocol of the NBP can be used by the NBP code's implementation to find the network address of the boot server from which the NBP was loaded, too.
As mentioned earlier, this technology isn't limited to a UEFI style boot, though. A Linux PowerPC Open Firmware boot could be done with the same dhcp.conf by adding
if option dhcp6.client-arch-type = 00:0c {
option dhcp6.bootfile-url "http://[fc00:ba49:1625:fb0f::137]/linux-powerpc-kernel.bin";
to enable booting a PowerPC based native binary of Linux from a web server.
If you want to take advantage of the exciting world of network boot and have a new architecture type, let me know since I'm the expert reviewer who provides the IETF with additional types, too.
Specifically, how do you configure a server to provide a netboot6-based image? SUSE has written a helpful document on configuring a Linux server to support this usage at http://www.novell.com/docrep/2012/12/sles_11_sp2_for_uefi_client_best_practices_white_paper.pdf.
Recall that Netboot6 is a combination of the wire protocol defined in both RFC 5970 http://tools.ietf.org/html/rfc5970 and chapter 21.3.1 of the Unified Extensible Firmware Interface 2.4 specification http://www.uefi.org. The UEFI client machine uses DHCP as a control channel to expose its machine type and other parameters as it attempts to initiate a network boot. This is referred to as 'client initiated' network boot, as opposed to 'server initiated.' Examples of the latter include Intel(R) Active Management Technology (AMT) Integrated Disk Electronics Redirection (IDE-R), or exposing the local hardware network disk interface to the management console for purposes of the management control provisioning a disk image http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fsetsoliderandotherbootoptions.htm. An implementation of Netboot6 can be found at https://svn.code.sf.net/p/edk2/code/trunk/edk2/NetworkPkg/UefiPxeBcDxe/ in order to demonstrate a client-initiated download.
For client-initiated network bootstrap art like Netboot6, what are the details of the parameters? The most important parameter entails the architecture type of the .efi image that the boot server needs to provide. The client machine that has initiated the network boot needs to expose its execution mode to the boot server so that the appropriate boot image can be returned. Recall that UEFI supports EBC, Itanium, ARM 32, ARM 64, Intel 32-bit, and Intel 64-bit. This list may grow over time with corresponding updates to the UEFI Specification of machine bindings. Beyond a UEFI-style boot, some of my co-authors on 5970 worked for IBM and wanted to network boot a system software image over 1) HTTP and 2) not based upon UEFI technology. As such, the parameters at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml cover both UEFI and non-UEFI, with the latter class including PC/AT BIOS and both PowerPC Open Firmware and Power PC ePAPR, respectively.
So RFC 5970 can be used in scenarios beyond Netboot6's TFTP-based download. This is enabled by the architecture type field extensibility, and also by the fact that the boot image is described by a URI, not a simple name with an implied download wire application protocol of TFTP as found in PXE2.1 IPV4 usages.
A way to explain this further can be done by examining our Linux configuration use case. In Linux, the DHCP server actions are performed by the dhcpd, or "Domain Host Controller Protocol Daemon." The daemon is parameterized by the file dhcpd.conf.
Within dhcpd.conf we enable Netboot6 by way of the following lines:
option dhcp6.client-arch-type code 61 = array of unsigned integer 16;
if option dhcp6.client-arch-type = 00:07 {
option dhcp6.bootfile-url "tftp://[fc00:ba49:1625:fb0f::137]/bootx64.efi";
} else {
option dhcp6.bootfile-url "tftp://[fc00:ba49:1625:fb0f::137]/bootia32.efi";
}
As mentioned earlier, this technology isn't limited to a UEFI style boot, though. A Linux PowerPC Open Firmware boot could be done with the same dhcp.conf by adding
if option dhcp6.client-arch-type = 00:0c {
option dhcp6.bootfile-url "http://[fc00:ba49:1625:fb0f::137]/linux-powerpc-kernel.bin";
}
to enable booting a PowerPC based native binary of Linux from a web server.
If you want to take advantage of the exciting world of network boot and have a new architecture type, let me know since I'm the expert reviewer who provides the IETF with additional types, too.
Processor Architecture Types
- Registration Procedure(s)
Expert Review
- Expert(s)
Vincent Zimmer
- Reference
- [RFC5970]
