UEFI Boot from Web

I think I've been living under a rock in these last few months and not exactly following UEFI development. Nonetheless, I managed to spot this stuff over at https://firmware.intel.com/develop/server-development-kit. What's interesting is the SDK supports "Firmware Boot from Web" so to speak. This is the relevant excerpt:

The Intel® Server Board S1200RP UEFI Development Kit supports Pre-Execution Environment (PXE) boot for IPV4 and IPV6 networking using on-board and add-in networking devices. Because of added initialization time, network boot for the four onboard networking devices is disabled by default in firmware setup. Users can enable PXE boot for on-board networking by enabling the ’EFI Network’ setting in the firmware setup menu.

EDKII Menu -> Advanced -> Network Configuration

As of SDV.RP.B6, the Intel® Server Board S1200RP UEFI Development Kit supports UEFI HTTP and HTTPS boot. These features are described in whitepapers located on the Tianocore github wiki: https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20White%20papers.

Well, it could be double-edged sword from security standpoint. It depends on who you ask and what it's being used for.

Anyway, this is my take on this:

• My "educated" guess is: This stuff emerge from Intel collaboration with the so-called Hyperscalers--Hyperscalers is what some people call them (http://www.nextplatform.com/category/hyperscale/). The Hyperscalers (Google, Facebook, Amazon, Azure, Alibaba, Baidu, Tencent) are running lots of web servers. Therefore, it makes sense for them to make it possible for their machines to boot just off of the webservers instead of preparing another "PXE Boot server" due to the prevalent web server in their bit barns. I think that Intel wants to trickle-down the same stuff into the masses, but as the first step, the Enterprise sector is what Intel targets.
• Present day flash (is it still Flash??) memory used for firmware storage is spacious enough to cram a (compressed?) HTTP/HTTPS client into it. It would hardly possible to do that just several years ago due to the space constraint in the firmware chip on the motherboard. I didn't say this is impossible years ago because I have worked with extremely limited firmware space in non-PC platform that somehow managed to cram HTTP server into space less than 1MB, along with hardware configuration software stuff. 
• This made it possible to boot from the cloud if anyone wants to implement such a stuff. But, it would entails a huge security "nightmare" if you ask me.

System Address Map Initialization Part 2 Article

Finally, System Address Map Initialization Part 2 article is up. Check out :  http://resources.infosecinstitute.com/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/. It's a lengthy article. There could be minor error coz I didn't have enough time to review some parts of the detail close to the end of it.

System Address Map Initialization in x86/x64 Architecture Part 1 - Article

New article explaining details of PCI-based system address map initialization is up: http://resources.infosecinstitute.com/system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/. This is part one of two articles. I started with PCI because the basic knowledge on the bus protocol is essential before moving to part two which covers present day PCIe systems.

UEFI replacement for BIOS Int 15h AX=E820h Interface

Those who play with low level code are familiar with the BIOS Int 15h AX=E820h interface to query memory map of the system (x86/x64). In fact, it's probably the safest way to do that.

In EFI/UEFI, the interface is replaced by a new function call interface. The function name is GetMemoryMap() and it's part of EFI/UEFI boot services. The definition of this function as follows:

typedef
EFI_STATUS
GetMemoryMap (
    IN OUT UINTN *MemoryMapSize,
    IN OUT EFI_MEMORY_DESCRIPTOR *MemoryMap,
    OUT UINTN *MapKey,
    OUT UINTN *DescriptorSize,
    OUT UINT32 *DescriptorVersion
);

The meaning of the parameters as follows:

• MemoryMapSize; A pointer to the size, in bytes, of the MemoryMap buffer. On input, this is the size of the buffer allocated by the caller. On output, it is the size of the buffer returned by the firmware if the buffer was large enough, or the size of the buffer needed to contain the map if the buffer was too small.
• MemoryMap; A pointer to the buffer in which firmware places the current memory map. The map is an array of EFI_MEMORY_DESCRIPTORs.
• MapKey; A pointer to the location in which firmware returns the key for the current memory map.
• DescriptorSize; A pointer to the location in which firmware returns the size, in bytes, of an individual EFI_MEMORY_DESCRIPTOR.
• DescriptorVersion; A pointer to the location in which firmware returns the version number associated with the EFI_MEMORY_DESCRIPTOR. See “Related Definitions.”

The definition of the EFI_MEMORY_DESCRIPTOR structure as follows:

//*******************************************************
//EFI_MEMORY_DESCRIPTOR
//*******************************************************
typedef struct {
    UINT32 Type;
    EFI_PHYSICAL_ADDRESS PhysicalStart;
    EFI_VIRTUAL_ADDRESS VirtualStart;
    UINT64 NumberOfPages;
    UINT64 Attribute;
} EFI_MEMORY_DESCRIPTOR

The description above is based on UEFI Spec. v2.3.1 Errata C.