Conferences, Forums, and Writings

It has been some time since I touched this blog. Thanks to Lee F. for his recent email bump "the blogosphere misses you" for reminding me of gap. I'll try to play a bit of catch up with today's posting.

I also need to refresh my postings to https://firmware.intel.com/blog but I have to admit that I prefer the Blogger interface - it auto-saves the content, it doesn't ask me to update my password every time I log in, it's easy to important graphics,....

And I'm really glad to see Tim Lewis blogging again http://uefi.blogspot.com/. He's one of the most talented guys I know in this industry and I enjoy reading his postings almost as much as I enjoy talking with him in person.

Regarding Tim's blog, he described the recent UEFI Forum publication of the PI 1.5 specification http://uefi.blogspot.com/2016/10/pi-15-released.html. The most notable update is the generalization of the System Management Mode (SMM) software model in volume 4 to the "Management Mode" or "MM" model that can accommodate both ARM TrustZone (R) (TZ) and IA32/x64 SMM. Historically we didn't unify the Itanium PMI software model with SMM since the former didn't offer the curtained execution model of both SMM and TZ. There are many commonalities of the latter two, though, such as the "SMI" activation mechanism, with "System Management Interrupt" for SMM and "Secure Management Interrupt" for TZ, etc. The ability to load earlier was informed by some ARM implementations establishing memory early and provisioning TZ, and also a potential SMM implementation of an early load https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf. One potential usage of the PI1.5 would be to cross-compile error logging code https://firmware.intel.com/sites/default/files/resources/A_Tour_beyond_BIOS_Implementing_APEI_with_UEFI_White_Paper.pdf between a x64 Server to an Aarch64 based server, for example.

Beyond the UEFI Forum, there has been more industry discussion of the Intel(R) Firmware Support Package (FSP).  Specifically, this technology figures prominently in Tim's BlinkBoot (R) white paper http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-secure-iot-solutions-insyde-software-blink-boot-fsp-white-paper.pdf mentioned in http://uefi.blogspot.com/2016/10/intel-and-insyde-embedded-white-paper.html. That paper is co-authored by another FSP fellow traveler, Ravi R, who helped create the series of Intel FSP producer/consumer papers, including https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf.  Along with the latter white paper co-author Giri Mudurusu I delivered the talk “Intel Firmware Support Package 2.0 Overview” at the coreboot conference, San Francisco, CA, June 14, 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016. The presentation is posted to

https://github.com/vincentjzimmer/Documents/blob/master/Intel_FSP_2.0_Overview.pdf and the video can be found at https://www.youtube.com/watch?v=uzfiTiP9dEM&feature=youtu.be.

At the same conference, my colleague Lee Leahy and I delivered “EDKII and CorebootPayloadPkg." The presentation is at https://github.com/vincentjzimmer/Documents/blob/master/EDK-II_and_CorebootPayloadPkg.pdf and the video at https://www.youtube.com/watch?v=I08NHJLu6Us.

On the coreboot payload package, in retrospect this code could have been generalized to the 'UEFI Payload Package.' Although the coreboot package has cbmem as its input data structures, which are then converted to HOB's, DXE and a UEFI implementation are easily launched from any environment with a HOB list. In fact, in the early days of Framework development we have a PEI shell command that would launch the DXE from the EFI Shell by just forging a HOB list. So this payload package could subsume today's DuetPkg https://github.com/tianocore/edk2/tree/master/DuetPkg, or EDKII on a PC/AT BIOS. Or the payload could be appended to U-Boot http://www.denx.de/wiki/view/U-Boot as an alternative to U-Boot native EFI implementation http://lists.denx.de/pipermail/u-boot/2016-February/244378.html, perhaps?

The coreboot conference was at a Google office near the waterfront in San Francisco, with the following view from the Google cafe.

Nice view and food. Over breakfast one morning Ron Minnich and I discussed the RISC-V Supervisor Binary Interface (SBI) https://github.com/riscv/riscv-pk/blob/1e62fdfce7b0095a57e4672c6c5fa4d3efb33d2a/machine/sbi.S and how it was a similar model to the DEC Alpha PALcode https://en.wikipedia.org/wiki/PALcode. We each agreed that having a hardware interface is often preferable to yet more run time firmware interfaces like sbi.

And the after-hours activity for the conference included a visit to http://longnow.org/ with a mock-up of the 10,000 year clock

After this conference I revisited San Francisco again to deliver a poster chat at the Intel Developer Forum.  Below is the abstract of the talk:

SOFTC01 — New Firmware Security Requirements for the Modern Data Center

Details
Data center security relies on a core root of trust, which is provided by platform firmware. The latest Trusted Platform Module (TPM) standard, TPM 2.0*, and updated Unified Extensible Firmware Interface (UEFI) requirements for enterprise operating systems are critical for companies deploying modern, secure data centers. In this session, you will learn security practices for UEFI firmware in enterprise and data center environments, based on new OS requirements and capabilities

Topics include:
• Update on latest UEFI standards for networking and security.
• Latest updates for TPM2.0.
• Guidance on building trusted enterprise class platform firmware.

About the Speaker

Vincent Zimmer Senior Principal Engineer, Intel Corporation

Vincent Zimmer is a Senior Principal Engineer in the Intel Software and Services Group. Vincent has been working on the EFI team since 1999 and presently chairs the UEFI Security and Network Subteams in the UEFI Forum www.uefi.org. He has authored several books and articles on firmware.

http://myeventagenda.com/sessions/0B9F4191-1C29-408A-8B61-65D7520025A8/14/5#sessionID=1372

With the following poster.

The poster chat provided a lot of discussion with members of the industry around data center host firmware and deployment, including interest in HTTP-S style deployments in lieu of today's TFTP-based PXE.

It was great to see Kushagra https://azure.microsoft.com/en-us/blog/author/kvaid/ on stage during the data center keynote, too.

When Kushagra was at Intel as a CPU architect he helped the firmware team pioneer the cache-as-RAM usages http://google.com/patents/us7254676 and later as a data center technologist some interesting platform solutions http://google.com/patents/us8984265 and http://google.com/patents/us7747846.

And during the event I was able to catch up with some colleagues on the show room floor, including Jeff Bobzin and Tim Lewis from Insyde, Dick Wilkins (thanks Bob H. for catching my typo in original posting) and Jonathan from Phoenix, and Stefano and Zach from AMI. Good folks all around.

After these sojourns to California, I gave a talk at the UEFI Plugfest http://uefi.org/2016FallUEFIPlugfest here in the Seattle area. You can find the talk material at http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf and the video at https://www.youtube.com/watch?v=_N1v_bWN4zk. Many of my slides on the specification's features listed the corresponding Github repository. I omitted a link to the capsule work since at the time of the talk the EDKII feature was under community review. If I were to reprise the presentation today I'd affix https://github.com/mdkinney/edk2/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery to the top of slide 7.

During the Plug Fest Microsoft's Scott Anderson also provided an overview of http://www.pcworld.com/article/3106726/windows/golden-keys-that-unlock-windows-secure-boot-protection-uncovered.html in slides 4 and 5 http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Security_Microsoft_Fall_2016.pdf.

In my UEFI Plugfest talk I also gave an update of the standards and some of the developments on EDKII, including mentioning some DMTF alignment topics I had also discussed at OCP https://www.youtube.com/watch?v=3yGbwUwwjxc. I also enjoined the community to complement the industry standards with more informative information. To that end, beyond the above presentations and new industry standards, I co-authored a few new white papers since my last blog posting, including:

“A Tour Beyond BIOS - Security Enhancement to Mitigate Buffer Overflow in UEFI,” October 2016,

https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Securiy_Enhancement_to_Mitigate_Buffer_Overflow_in_UEFI.pdf

"A Tour Beyond BIOS - Security Design Guide in EDKII," September 2016

https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Security_Design_Guide_in_EDK_II.pdf 

“A Tour Beyond BIOS Implementing Profiling in with EDK II,” July 2016 https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Implementing_Profiling_in_EDK_II.pdf

And under the guise of the UEFI Forum, "Establishing the Root of Trust," UEFI White Paper, August 2016, http://www.uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf was published.

The intent of such material is to provide rationale and some guidance on how one might successfully refine the standards into a working artifact, including ones based upon EDKII style technology.

Well, so much for a catch-up blog. I wish everyone a happy Thanksgiving tomorrow from the always raining-in-November Seattle area.

Trends and openness

The balmy days of summer have made me reflect upon the past. And colleagues leaving of late make me more thoughtful. This is sort of a twist on the earlier career development talk, but with advice on how to pivot and react to the world. Of course the discourse includes a long-winded blog format that also treats on various aspects of life in tech and the human condition.

To begin, I work at a remote site (aka 'Siberia' of West Coast), so a long period of time can pass between seeing most colleagues. Even in the age of video conferencing, few parties use that class of tool, and I keep my camera covered with a yellow sticky note for other reasons.... In fact, I can work with some colleagues for years and only communicate on the phone or e-mail. When I finally do meet one of those long-distance collaborators in person, I often want to blurt out "you sounded much taller/shorter/fatter/older.... on the phone." But there really isn't an appropriate response. At one point I had mistakenly thought a collaborator was the Office Space stapler guy while remotely collaborating, and when we did finally meet, I sat stunned for the first ten minutes when I realized that I had mistaken this gentleman for an erstwhile cryptographer. The stapler guy image and the tan, fit person sitting across from me in the conference room didn't quite align.

On the other side of the coin, I do see certain people aperiodically over the course of the years, say at internal conferences or face-to-face mission meetings. In the early days of my tenure we would beat our chests and opine about all-night coding sessions, weight lifting, and other antics of youth, all with shiny, fresh cherubic faces.

Fast forward 10-15 years, and I note the weariness on faces w/ lines reflecting hours of ennui in meetings, bodies thicker around the middle from those days of eating lunch while on con-calls + fast-food while working late + more meetings + poor eyesight from poring over code and docs....  There is an occasional spark in an eye recounting the past, but mostly there are discussions that entail children and who is promoted or working at company XYZ.

But the advantage of wisdom includes having a network of collaborators and a more senior role to effect change. And that position is important, because the one thing that is constant over this span of time is change, especially in the technology industry. And when it comes to disruptive trends and change in our industry, I like to think of these trends as the four horseman of the apocalypse. When a disruptive trend is afoot, you can be in one of the three places: in front of the trend (and get trampled), behind the horses (and do clean-up duty), or riding one of the horses. Given my simplified view of things, you can imagine my predilection, namely riding one of the horses and being that agent of change.

As part of riding that course and driving change, one of the trends I observe has been the movement to open ecosystems, open source, including the move from PC/AT style BIOS to firmware environments like UEFI and its edk2 based development on tianocore.org. The salient portion of system software work, whether operating systems like Linux or edk2, includes openness and ecosystems. That's where open source can help.  Marc Andreesen rightly noted that software is eating the world http://online.wsj.com/news/articles/SB10001424053111903480904576512250915629460, and now open source software is eating software http://readwrite.com/2013/12/12/open-source-innovation#awesm=~oIwdZdqu0YdTo8.

This tend of open source source helps inform innovation paths, too.  Whether the discussion includes the minimal features to exemplify a capability, such as a micro-hypervisor using hardware virtualization https://github.com/udosteinberg/NOVA, or showing how a full UEFI edk2 implementation on Quark (1MByte image) can scale down to a 64-kbyte solution with "TinyQuark" http://firmware.intel.com/sites/default/files/Intel_Galileo_TinyQuark_64K.zip for https://firmware.intel.com/projects/get-started-intel-galileo-development-board. Why zips for the latter and not checked into an upstream open source IA firmware ecosystem? That's a discussion for another day. These small examples prove an innovation direction ahead of broad product execution that may embrace some of the design precepts demonstrated therein.

Another example of openness and innovation is network boot. Recall my description of IPV6 network booting at http://vzimmer.blogspot.com/2013/10/configuring-ipv6-network-boot.html. I'm a big fan of pre-OS networking https://www.researchgate.net/publication/258834396_A_Quick_History_of_UEFI_Networking and I chair that subteam, along with security, in the UEFI forum.

Since that discussion the options at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml have been expanded by my friend at HP Samer El-Haj-Mahmoud http://www.uefi.org/sites/default/files/resources/UEFI_Summit_July_2013_UEFI2.4_Networking.pdf. The essence of these new options is to allow the UEFI machine to express that it has the ability to boot using a TCP-based, or connection-oriented protocol like HTTP, versus today's TFTP-based PXE wire protocol. This allows for more robust and scalable deployments without the need for retries and timeouts that afflict the UDP-based TFTP deployments.

Processor Architecture Types

Registration Procedure(s)

Expert Review

Expert(s)

Vincent Zimmer

Reference

[RFC5970]

Available Formats

CSV

Type	Architecture Name	Reference
0x00 0x00	x86 BIOS	[RFC5970][RFC4578]
0x00 0x01	NEC/PC98 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x02	Itanium	[RFC5970][RFC4578]
0x00 0x03	DEC Alpha (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x04	Arc x86 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x05	Intel Lean Client (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x06	x86 UEFI	[RFC5970][RFC4578]
0x00 0x07	x64 UEFI	[RFC5970][RFC4578]
0x00 0x08	EFI Xscale (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x09	EBC	[RFC5970][RFC4578]
0x00 0x0a	ARM 32-bit UEFI	[RFC5970]
0x00 0x0b	ARM 64-bit UEFI	[RFC5970]
0x00 0x0c	PowerPC Open Firmware	[Thomas_Huth]
0x00 0x0d	PowerPC ePAPR	[Thomas_Huth]
0x00 0x0e	POWER OPAL v3	[Jeremy_Kerr]
0x00 0x0f	x86 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x10	x64 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x11	ebc boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x12	arm 32 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x13	arm 64 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x14	pc/at bios boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x15-0xff 0xff	Unassigned

These tags as part of the wire protocol for DHCP, along with the URI device path node from the UEFI 2.4 specification, errata B, allow for negotiating this download and informing the network boot program from where it was loaded, respectively. Good stuff. And I look forward to booting UEFI on the Skynet.

Openness and ecosystems also allow for bringing people along in the journey. I was shocked and pleased when one of my overseas colleagues mentioned how to escape from the 'Cathedral', namely a reference to Eric Raymond's book http://www.catb.org/esr/writings/cathedral-bazaar/ on the same. The meme infects technologists regardless of experience or culture, as exemplified by our Friedman'esque Flat World http://www.amazon.com/The-World-Is-Flat-Twenty-first/dp/0374292884.

And you have to innovate. I cannot recall the number of conversations I've had over the years which evolve roughly as follows (I'm the 'technologist' here):

[technologist] 'You can do this feature with open technology.'

[incumbent] 'Don't do that, you'll compete w/ my value proposition.'

Which is sometimes met by 

[incumbent's marketing] 'It's easy to pass someone by when they are standing still.'

Exactly.

Regarding this exchange, the technologist doesn't want to break the cathedral's feature since both parties often work for the same company. But the technologist does observe these business facts to his colleagues, namely that the bazaar has the potential to power this disruption. Given that potential, why not disrupt yourself? I use the analogy of driving down I-5 to Portland. I can mind the fuel gauge and re-fuel when necessary. This entails diligence in observing the physical reality of an automobile. Or I can ignore reality and run out of gas in the middle of the interstate. The fuel constraint is like the competitive technology, you should only ignore at your own peril and 'control' the phenomena as best you can.

In the thick disruption and openness, being open also helps solve the outside-in problem. Sometimes a technologist in the cathedral wants to drive something that the other priests in the cathedral are loathe to support. So the 'outside-in' strategy can include getting customers (i.e,. the 'outside') excited and pulling the internal team (i.e., the 'inside') to respond. This is the less-kind version of  http://knowledge.wharton.upenn.edu/article/outside-in-strategy-for-the-c-suite-put-your-customers-ahead-of-your-capabilities/ since recalcitrant priests may be caught flat-footed to respond to the customer request once the outside-in push accelerates. But by enjoining the outside with open source ecosystems, there is a ready substrate to help the cathedral meet the incoming business request. Essentially the bazaar is the join point and shared infrastructure to evolve technology between partners, such as common open source code into which the cathedral can accrete its features.

The other fact I have realized over time is that everyone has their own cognitive frame and history. This is where the humanities http://blogs.scientificamerican.com/cross-check/2013/06/20/why-study-humanities-what-i-tell-engineering-freshmen/ still have a place in engineering. The arts teach 'how' to think and embrace change. Whether its the questioning of all premises in the spirit of Socrates, realizing the arbitrary language games of many conversations via Wittgenstein, or treating the world with skepticism that is resolved via Popper-like proofs and refutations. Take these words with a grain of salt, of course, as my bachelors degree is in electrical engineering and my masters in computer science. Thus you're reading the advocacy of an autodidact in the humanities, not a lettered representative therein.

And sometimes you just need time to be alone with your thoughts.

And you have to leave your ego at the door. The best advice I received on this point came from Andrew Fish, who once confided in me his secret, namely when you are in the thick of a debate and you realize that you are in the wrong, do the 'flip', or embrace the interlocutor's position. There is no shame in evolving your position in light of additional data. The flip should be done with due care and consideration lest you become a relativist or perceived as wishy-washy, but you must observe the truth when you see it. Part of leaving your ego at the door also includes taking criticism and feedback. You will often be incorrect, or not everyone will love you or your ideas, especially if you are on the wave front of a disruption. And the more you disrupt, the more ire you might draw from your peers and the incumbents.  And following Rumsfeld, "Learn to say `I don't know.' If used when appropriate, it will be used often."

And you must also always tell the truth. My best advice in this vein comes from Mike Richmond: "Never lie, but don't always tell everything." Telling the truth and being genuine eases the burden of having different stories for different parties and having to compartmentalize yourself. You will ultimately succeed on being transparent and delivering value, not on dissimulation and currying favor.

Another piece of advice includes finding the true root cause of an issue. It's quite easy to 'blame' other people, or the ad hominem attack, since the targets are nearly inexhaustible, with the last number I heard pinning the figure at a world population of over seven billion people in 2013. This class of attack sows enmity and reduces your credibility since a barbed tongue replaces truth.  But the technique goes pretty far, especially within companies. Only when existential realities like external market forces or internal resources enter the fray does this technique lose its potency.

Also, I observe that technologists who were most successful in the last disruption have difficulties in adapting to the next trend. I analogize this to the armies in the wake of World War I (WWI). In that conflict, trench warfare prevailed and the best defense devised for future conflicts by the French was the Maginot Line, or an armored variant of a trench covering their border. When World War II occurred, airplanes flew over the line. The quote that is often related to this historical event includes: "generals always fight the last war, especially if they have won it."

In the technology industry, you can imagine the parallels to the Maginot Line. Specifically, the technologist who drove the last disruption may be loathe or unable to address the next one. To me, you should always acts as the challenger, or a recent colleague graduate, with something to prove. The technology industry doesn't respect tenure. It instead demands results. And as Heraclitus said (now we're going pre-Socratic), "you can never step in the same place of a river twice." In the river of technology, that has never been more true than today.

But spotting trends is tough. I recall the exuberance of Gilder's Telecosm.  This hasn't aged as well as Grove's or Christensen's books, I fear. It turns out that the fiber of the Telecosm became the conduit for the web and data traffic that drove the new businesses, such as Google.

And having a network doesn't just include your co-workers. Your network should span other industries and companies - see advice on same at http://www.forbes.com/sites/ricksmith/2014/07/02/5-career-mistakes-you-will-regret-in-10-years/. I still remember my first trek to the Intel Developer Forum where I presented in 2003. The then-CTO of Sun Greg Papadopoulos said in his keynote "All of the smartest people don't necessarily work for your company." Your company does have the smartest people who are both dialed into the road map, strategy and capabilities of that enterprise, though, so I believe the advantage still goes to the company - necessary for success, but typically not sufficient (i.e., the 'if' but no the 'iff'). To close the sufficiency argument (and get to 'iff'), alternate views and help of others, especially in open ecosystems I've described in this posting, are key. As evidence of same, just throughout these recent blog entries you'll find reference to colleagues both within and outside of my company from whom I have had the honor to learn and collaborate over the years.

So you might not always guess right, but by enjoining the community with openness, listening, and reacting to the customer and acclimate market needs, you'll do fine. The tactics might include a pivot, flip, or re-plan, and through all of those actions remain genuine, honest, and work hard.

Speaking of working hard, time to get back into the melee and cease by blog graffiti on the wall of the internet.

Configuring an IPV6 network boot

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.

Processor Architecture Types

Registration Procedure(s)

Expert Review

Expert(s)

Vincent Zimmer

Reference

[RFC5970]

That's all for today. My Saturday blogging time budget is up. Back to work.

Anniversary Day.Next, Arch P*'s, and some stack history

Today makes 16 years at Intel.  Sunday is usually my catch-up day for work tasks or extra credit work (e.g., patent drafting), but given that I posted an entry on this day last year, I'll steal a few minutes to post something today.  If I keep my wits about me maybe this can become a tradition?  Induction will argue that it might be so if I hit the 'publish' button before the end of the day.  0, 1, ... infinity, right?  OK.  Enough of that.   Popper and Hume might rise from their graves and smite me for induction invective if I go on that path.

The first topic I wanted to touch upon today includes the intent behind the architectural p*'s in the UEFI Platform Initialization (PI) Specifications.  Namely the architectural PEIM-to-PEIM interfaces (PPI's) and Architectural Protocols (AP's) in Volumes 1 and 2, respectively.  I have been meaning to cover this topic for a while, but today's posting is motivated by James B's foils @ http://blog.hansenpartnership.com/wp-uploads/2013/02/UEFI-Secure-Boot-2013.pdf, namely slide 15.  In this presentation deck, not 'paper' as some people are wont to describe foils these days, James discusses overloading the security protocol from the PI specification from his UEFI application.   As James' loader is a pure UEFI application, any dependency upon an underlying PI interface breaks portability.  There is no reason that UEFI interfaces need be built upon a PI-based underlying implementation, for example.

We mention this in many places, including page 12 of UEFI_Networking_and_Pre-OS_Security or http://noggin.intel.com/technology-journal/2011/151/uefi-today-bootstrapping-continuum, viz., "PI, on the other hand, should be largely opaque to the pre-OS boot devices, operating systems, and their loaders since it covers many software aspects of platform construction that are irrelevant to those consumers."

The history of the PPI's and AP's in Intel Framework, and subsequently the UEFI PI specifications, was to abstract a portable PEI and DXE core from the respective platform.   The sources for the cores are intended to be kept platform neutral such that they can be seamlessly compiled to any target architecture, which today includes IA32, x64, Itanium, and 32-bit ARM for the edk2 at http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2.  As such, the arch PPI's and AP's provide a hardware or platform abstraction lay (H/PAL) to the cores.  Back to James' foils above, he took advantage of a design choice where the protocol's were left in the UEFI protocol database after the DXE core had bound itself to those call-points.  A conformant PI implementation of UEFI could have uninstalled that protocols prior to entering BDS and invoking 3rd party UEFI drivers and applications, for example.

Omission of the AP's from the database and precluding usage by 3rd parties is not just hygiene.  Abuse of the timer AP, for example, by an errant or malevolent UEFI application could change the timer tick in a way that was not consistent with the DXE core's original programming of the time base via the timer AP.

So the lesson from above includes (1) if you want to be a portable UEFI driver and application, don't invoke UEFI PI AP's, and (2) as a platform creator, be wary of the protocols you leave installed in the database prior to invoking 3rd party UEFI content.

Next on the list today includes a short history of the UEFI networking stack.  The original EFI networking stack was part of the EFI1.02 specification back in 1999.  We modeled the network stack on the PC/AT networking support, including the PXE base code (BC) and UNDI interfaces.  The latter 2 API's were defined in the PXE2.1 specification.  The PXE (pre-boot execution environment) specification contains both a wire protocol for network boot and a set of API's that a network boot program (NBP) uses so that when it is downloaded onto a PC/AT BIOS client machine it can continue usage of the client machine's network stack.   For EFI1.02, we adapted the PXE BC and UNDI API's into EFI equivalents, while preserving the network wire protocol aspects, such as the DHCP control channel, TFTP-based file download, etc.  EFI added an additional software API on top of UNDI called the Simple Network Protocol (SNP), too.  So from BIOS to EFI we preserved PXE BC, UNDI, and added a SNP between the former two.

After EFI1.10 and its inclusion of EBC and the EFI Driver Model, we thought of what a "EFI1.2" specification might entail.  One aspect of the pre-OS we explored included more efficient networks.  The problem we discovered was that SNP could only be opened by one agent, namely the PXE BC.  When other network drivers were added, such as the circa-1999 BSD TCP/IP port to EFI, we had to unload the PXE BC in order to have the TCP/IP stack active.   Against this background of a single SNP consumer, we designed the Managed Network Protocol (MNP).   MNP provides for multiple listeners and also provides a non-blocking interface, unlike the single consumer, blocking nature of SNP and UNDI.  We took the concept of multiple consumers and non-blocking for the higher layer protocols, including UDP, TFTP, DHCP, and TCP/IP.   In doing so, we were able to rewrite the PXE BC application to be a small consumer of the below-listed services versus the monolithic stack embedded in the original PXE BC.

Since EFI1.2 never came to light, MNP and the rest of the modular stack definition were contributed into the UEFI2.0 specification as part of the UEFI Forum's effort.  This was timely in that ISCSI was added to the UEFI2.0 corpus, and implementing ISCSI and PXE on the same modular stack proved to be feasible.   The next question posed to the pre-OS networking stack was what to do with PXE.  Recall that the EFI, and now UEFI, interfaces to PXE included the PXE 2.1 wire protocol.  We were faced with evolving PXE to an alternate wire protocol or augmenting PXE and the rest of the networking stack to meet the emergent needs in the industry, such as internet protocol version 6 (IPV6).   Given the extant infrastructure of PXE servers and associated scenarios, included blended scenarios such as 'PXE boot the NBP OS installer, mount an ISCSI share, install into the ISCSI block device', etc, we opted to draft PXE into IPV6 with parallel capabilities.   We coined the effort to have network boot on IPV6 'netboot6' and codified the elements of this capability in RFC 5970 http://tools.ietf.org/pdf/rfc5970.pdf and chapter 21 of the UEFI 2.3.1c specification.  5970 was evolved as part of the DHC WG in the IETF and describes a broad class of network boot transports described by a URL, which includes HTTP, TFTP, ISCSI, NFS, etc.  Netboot6 opted for the TFTP-based transport to have a parallel flow to the PXE 2.1 wire protocol, but there is no reason going forward that alternate boot transports can be used.

Seeing is believing, though, so you can find the networking infrastructure mentioned above at http://edk2.svn.sourceforge.net/viewvc/edk2/trunk/edk2/NetworkPkg/.

I regret that this blog and many of the white papers referenced in the past have not treated the UEFI networking stack with much detail.  I'm working to get some more collateral out in the open, especially given how to compose pre-OS networking and fast-boot.  One piece of wisdom that I want to mention is that the UEFI system should not attempt to start any of the networking stack elements unless there is a boot target that includes PXE or other networking-facing service.  This is in the spirit of the UEFI driver model where you should not connect a driver unless needed to boot.  This sparse connect is how UEFI achieves its fast boot times relative to PC/AT BIOS's that had to spin up all of their spindles and network interfaces in absence of having a stylized boot object like the UEFI boot targets with their device paths.  Given that IEEE 802.3 Ethernet devices can take 7 to 20 seconds to effect cable detect actions, any touch to the network will kill chances of achieving the 2-3 second boot times expected by modern operating systems.

Other advice I will include on network boot includes policy decisions of orchestrating IPV4 versus IPV6 on network accesses, etc.  So beyond having a more detailed overview of the stack, fast boot and network selection policy, let me know if there are additional topics on the network stack that you would like to see treated.

Well, that's it for anniversary year 16 blog.  Let's hope that the inductive argument holds true and I am creating the year 17 variant of this blog.

Cheers