IPv6 Network Boot with UEFI

Vincent Zimmer has just put up a nice little post how configuring IPv6 network boot with UEFI over on his blog here. As usual, we need him to write more since so much of the UEFI network stack was overseen by the UEFI Network Sub Team (UNST), of which he is the chair.

UEFI 2.4 Review, Part 9: Adapter Information Protocol

This is the ninth part in a series of articles looking in detail at the changes in the UEFI 2.4 specification. This time we will look at the Adapter Information Protocol, which provides access to operating state information for an adapter. Not a setting, but a state.

So, at first glance, the EFI_ADAPTER_INFORMATION_PROTOCOL (section 10.11) looks just like another Get/Set/Query API we've seen a thousand times before. Ah, but this is a Get/Set/Query API with a GUID. So what, you say? That means we can hang dozens of interesting pieces of data off of one adapter handle. A similar approach was also used EFI_FILE_PROTOCOL's GetInfo() function (see section 12.5) to provide additional information about a single file handle. But now we're going to do it for a device handle.

Now, per the spec, this isn't for every type of information. It is meant to be dynamic and return quickly, not blocking while waiting for some piece of data to return. In other words, not a performance pig.

What is it used for? Well, the UEFI 2.4 specification lists out three "standard" uses: the network device's media state (i.e. the network cable is plugged in, section 10.12.1), the native network boot capability of an iSCSI or FibreChannel-over-Ethernet (FCoE) target (section 10.12.2), and the 802.3 or FCoE SAN MAC address (10.12.3). But with a GUID, hey, who is stopping you from adding your own piece of adapter trivia for the consumption of adoring pre-OS applications?

No, really: this sort of information could have been published using separate protocols installed on the same driver handle. But all of those protocols would look very similar, and they would all have the same basic functionality, and they would all be produced by the same driver. So why make life difficult? Make it a single protocol.

So UEFI makes life easier for driver and those who want to manipulate them.

UEFI 2.4 Review, Part 4: Require network drivers to return EFI_NO_MEDIA

This is the fourth in a series of articles reviewing the individual changes in the UEFI 2.4 specification. This time, we're looking at the requirement that the EFI_NO_MEDIA error be returned from a wide variety of network related protocols. Typically, EFI_NO_MEDIA indicates that there is no storage media (for disk-related functions) or no cable (for network related functions).

This update requires the low-level networking drivers to produce this error on their implementations of the Transmit() and Receive() functions in the Managed Network Protocol (MNP) and then each of the networking standard drivers that consume this protocol will propagate this error upwards to their callers. So, for example, the IP4/IP6, UDP4/UDP6, TCP4/TCP6 protocols have Transmit() and Receive(), the DHCP4/DHCP6 protocols have Start() and Stop() functions and the MTFTP4/MTFTP6 protocols have ReadFile() and WriteFile(). All of them now can report EFI_NO_MEDIA.

Why? So that calling applications can quickly determine if the cable is removed and decide to take appropriate action. Previously, there was no status code which clearly described this scenario, leaving the caller to try and decide if some sort of timeout had occurred due to a routing issue, or due to the cable not being present. Now the callers can make an intelligent choice.

Strangely, the SIMPLE_NETWORK protocol was not updated, although it is called out in the notes. My feeling is that this was either (a) a mistake or (b) a determination that some existing drivers couldn't handle the updated language.

UEFI is becoming a more capable networking platform all the time. Don't be surprised if higher level networking standards make their appearance soon. Then we'll wonder why we ever booted ;-)