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.

Where do I 'sign' up?

This post spends a little time discussing how to get pre-OS independent software vendor (ISV) content ‘signed’/’enrolled’ onto a UEFI Secure Boot protected platform.

As a quick background:

Intel (R) Boot Guard binds the OEM low level boot firmware (PI code as exemplified by SEC/PEI/DXE) with the hardware, so the Boot guard trust anchors would not directly interface with the trust anchors for 3^rd party UEFI content.  Details on Intel Boot Guard can be found on page 4 of http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/4th-gen-core-family-mobile-brief.pdf.  

People often ask about the relationship of something like Intel (R) Boot Guard and its "Verified Boot" versus UEFI Secure Boot, as defined in chapter 26 of the UEFI 2.4 specification. We talked a little about this earlier, too, at http://uefidk.intel.com/sites/default/files/resources/Platform_Security_Review_Intel_Cisco_White_Paper.pdf, page 16.  The “Reset Time Verified Launch” in Figure 5 logically maps to something like Intel(R) Boot Guard. The verification happens 'before' UEFI PI code and vets the provenance of that code, typically if the code was created and updated under the authority of the system board manufacturer. UEFI, on the other hand, is on the right hand side of that flow.

In other words, the underlying PI-code update key, say for validating a capsule update (install time verification) or the embedded signature of the PI code (load time verification) should not be the PK but some other system board vendor-managed key store.  Recall that on certain x86 systems the end user could even edit the PK via a physically-present setup page.  In that latter case, having the end user control the PI update key (and associated system firmware updates) is often not desired.  In the PI specification there are definitions of signed firmware files and volumes, but there is no defined policy store and trust anchors for 'Secure Boot' of PEI and DXE elements. 

In the end, users want end-to-end integrity, though, so both protection of the underlying firmware and the run time are important.  This was discussed a bit in the Intel Developer Forum presentation earlier in the month with the system architecture picture updated to the revised below.

Note in this picture above that Intel (R) Device Protection Technology with Boot Guard surfaces from the system hardware and precedes execution of the PI SEC/PEI/DXE codes.

UEFI Secure Boot, on the other hand, is intended for 3^rd party UEFI content, such as UEFI drivers or applications on the UEFI system partition.  Intel(R) Boot Guard and PI code verification keys should have their own manifest and storage structure.  For the 3rd party trust anchors, the place where this enrollment would happen is with the UEFI Secure Boot key hierarchy.  The hierarchy for UEFI Secure boot includes the PK, KEK, DB, DBX.  The factory-default configuration typically entails a PK that is owned by the OEM, and the PK authorizes updates to the KEK.  The KEK is OS Vendor1 + OEM + other OS vendors, and the KEK entries authorize updates to the DB/DBX.  DB is the ‘allowed’ list of code that can execute, and for a Microsoft (R) Windows8 machine contains a Microsoft OS certificate, the Microsoft UEFI CA cert, and possibly other OSV/ISV entries. 

Now for going from theory-to-practice-

Given a population of UEFI Secure Boot capable machines in the field, how is a pre-OS Independent Software Vendor (ISV) able to deploy content (i.e., the action item from above)?   The short answer is that the ISV has 2 options:

-          1. Sign up w/ Winqual and get the UEFI driver/application signed by the UEFI CA

and/or

-          2. Create own verification certificate and

o   Have end user enroll manually

and/or

o   Have OEM preinstall (or update in field via firmware update)

An ISV can do 1+2 above since UEFI Authenticode-based executables support ‘multisigning’ so that they can be signed by BOTH the UEFI CA and the ISV’s own key (see more on the final links below w/ SUSE example).

For the first option 1. above, the ISV can sign up w/ Microsoft Winqual and submit their content to be signed by the Microsoft UEFI CA.  Most ISV's, IHV's, and non-MSFT OSV's already has a Winqual account if they deliver signed Windows drivers today since Microsoft has been doing kernel mode driver signing since Vista SP1.  In addition, most IA machines that support UEFI2.3.1 Secure Boot carry a Microsoft UEFI CA DB certificate, so getting signed by the MSFT UEFI CA will mean that the ISV's .efi UEFI driver or application will simply work on a large class of PCs.  More info on the process can be found at:

http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_2013_-_New_Orleans_-_Microsoft_UEFI_CA.PDF

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463054.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/hh801894.aspx

For the second option 2. above, if the ISV wishes to generate its own roots and manually enroll in a PC (e.g., using PC setup screens) or distribute its keys for the OEM’s to pre-enroll, some details on the process can be found at http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=SecurityPkg

Beyond this information, some of the practices of a Security ISV like McAfee for their pre-OS UEFI content can be found at

http://intelstudios.edgesuite.net/idf/2012/sf/aep/EFIS003/EFIS003.html 

If you have a machine at home, you can use some of the flows described in the white paper above on running dmpstore and other commands at the UEFI shell to discover the configuration of UEFI Secure boot.  A more user friendly way is to run the Secure Boot Checkup Utility http://apps.insyde.com/sbutil.html from Insyde on your Microsoft (R) Windows 8 machine.  Thanks to Jeff Bobzin at Insyde for pointing this tool out to me.

This is the report from my Asus Windows 8 Intel (R) i3 touch laptop.  Well, my former laptop prior to my fourteen year old daughter commandeering it.  The output from the report proceeds below-

Secure Boot Status on this system:

System Status: MS Required KEK: MS Required OS Cert: 3rd Party (MS CA):

Secure Boot Enabled Present Present Present

UEFI Variables:

SetupMode: 
SecureBoot: 
OsIndicationsSupported: 

BootOrder Item List: 
BootCurrent: Boot00000 1 0000000000000001 0000 0000 Windows Boot Manager

Secure Boot Database Contents:

PK Variable Certificate (Platform Master Key):

X.509 Certificate:

CN=ASUSTeK Notebook PK Certificate

KEK Variable Certificates (Database Management):

X.509 Certificate: X.509 Certificate: X.509 Certificate:

CN=ASUSTeK Notebook KEK Certificate 
CN=Microsoft Corporation KEK CA 2011 
CN=Canonical Ltd. Master Certificate Authority

db Variable Certificates and Hashes (Allowed Signers):

X.509 Certificate: X.509 Certificate: X.509 Certificate: X.509 Certificate: X.509 Certificate:

CN=ASUSTeK Notebook SW Key Certificate 
CN=ASUSTeK MotherBoard SW Key Certificate 
CN=Microsoft Corporation UEFI CA 2011 
CN=Microsoft Windows Production PCA 2011 
CN=Canonical Ltd. Master Certificate Authority

dbx Variable Certificates and Hashes (Forbidden Signers):

X.509 Certificate:

CN=DO NOT TRUST - Lost Certificate

The interesting thing about this machine is that there is both a ASUSTeK KEK and Canonical KEK, along with the Microsoft KEK.  So this set of KEK entries includes one for the OEM and two alternative operating system vendors, namely Microsoft for Windows and Canonical for Ubuntu http://www.ubuntu.com/.

Below is a friendlier view of the tool in action.

Finally, back to closing thoughts on the Intel Developer Forum. 

Within that deck, one of the slides I enjoyed the most was the quote on slide 21 from SUSE that read:

"UEFI Secure Boot no longer an issue to the Linux* World"

Regarding IDF, it was great having the opportunity to meet with people from all across the industry.  I found the perspective of what I do from the different companies refreshing and helpful in informing customer and business-focused activities with my colleagues going forward.  Translation: I learned about a lot of things I need to get done quickly. 

This IDF talk marked ten years since my first IDF presentation in San Francisco.  I shuffled a bit less than the first talk, but I have to admit that I haven't evolved to the aplomb and sophistication of a Ted Talk http://www.ted.com.  The irony is that one of those talks I delivered in 2003 read on porting the Intel Framework (PEI/DXE) for different platforms, factoring silicon initialization code, etc. Since 2003 Framework 0.9x specifications became PI1.3, the EFI Developer Kit (EDK) became EDK2, and the preceding UEFI track talk at IDF 2013 discussed factoring all of the silicon initialization PEI modules as this new Firmware Support Package (FSP) http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html.  Oh yeah, Windows 8 shipped with UEFI as the default boot loader option recently, too.  Quite the decade indeed.

Speaking of getting things done, I had better end today's entry and get back to work.

Cheers

2/15/2015 update -
My friend's book http://www.apress.com/9781430265719 has a good description of Boot Guard in chapter 6.  Take a look.

End of summer '13

The unusually warm summer proved a bit confusing to the psyche.  The return of the Pacific Northwest rain of late brings me back to normalcy.

I haven't blogged in a while, but I must recommend and continue to be impressed by he writing of Tim Lewis at http://uefi.blogspot.com/.  Really good stuff.  I have appreciated the opportunity to work with Tim over the last decade or so and I am in continual awe of his intelligence and prolific output.

Let's begin with something of a meta-blog as an introduction today.  I sometimes censor my content for fear of being read as an advocate of a specific technology, or detractor of another. Sometimes 'is' versus 'ought' gets confused in such writings, namely the difference between describing a technology and evangelizing the same.  I felt alone in this tension until listening to Violet Blue and her description of today's confusion around 'information' versus 'advocacy' with the tech culture. The talk 'Hackers As A High-Risk Population [29c3]' https://www.youtube.com/watch?v=zq-bloM4Cmo elaborates on this point, among others.  

Of course, I surely have subconscious confirmation bias based upon areas with which I'm more familiar, but information comprises the intent of the following.   

Enough of the caveats, let's talk about architecture versus implementation.   

In the world of central processing units and hardware, we often refer to the distinction as 'architecture' versus 'micro-architecture.' The former describes the public description of the instruction set architecture (ISA), memory model, protection modes, and other modalities of the hardware that provide the consistency against which compiler writers, application developers and system software engineers can base their software development.  For Intel, these details are codified in the Software Developer Manual (SDM) http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html.  The micro-architecture, on the other hand, provides details on 'how' the architecture is implemented given adherence to the architecture as an outward constraint, but compounded with additional constraints of design inventiveness, power envelopes, transistor budgets, design invention, and schedule constraints, among others. It is in the world of micro-architecture where techniques like in-order versus out-of-order, additional functional units, bus width, number of ports to the memory and register file, micro-coded versus hardwired, and other techniques come into play. 

That's for the world of CPU's and hardware.  Correspondingly, the world of software defines the demarcation as 'interface' versus 'implementation.'  The former include the POSX API's, Win32, the UEFI Boot Services, and to even stretch the metaphor a bit, network wire protocols.  For the latter, implements include the Linux kernel, Microsoft Windows, the edk2 development project, and the venerable BSD TCP/IP network stack.  The line is not always clear initially, and some implementations become a de facto implementation, such as the Microsoft DOS binary executable.  The same holds true for the original PC/AT, where the public description http://bitsavers.trailing-edge.com/pdf/ibm/pc/at/1502494_PC_AT_Technical_Reference_Mar84.pdf of the hardware and software 'implementation' became the 'architecture' foundation, now referred to nostalgically or disparagingly as 'legacy', of the PC ecosystem.

Let's get into some details on where the architecture and implementation come together with respect to host firmware.  From a most generic taxonomy, there are two phases of execution.  The first is a 'platform initialization' and the second is a 'boot loader' phase.  The former phase entails initialization of the system board hardware and passing control to the boot loader phase.

All of these processes of booting entail passing control from one domain of execution into another.  These can include system boards that need boot firmware to launch a shrink wrap OS or a vertically integrated embedded system wherein the firmware producer and the OS producer are the same entity.  There are often different instances in the market depending upon the requirements of the business entities.

For the first phase, here is a quick chart mapping two well-known boot firmware technologies found on Intel Architecture.

Platform Initilization     coreboot          UEFI PI

Reset vector               Boot block           SEC

Memory init                ROM stage          PEI

I/O init                        RAM stage          DXE

Boot loader phase       Payload               BDS

Of the boot loader phases using coreboot payloads, these can include U-Boot as an implementation with SeaBIOS and a direct kernel load as alternate 'hand-offs' of control. Those hand-offs of control can include the Advanced Configuration and Power Interface (ACPI) http://www.acpi.info or the flattened device tree (FDT) evolved from open firmware IEEE 1275 http://www.openfirmware.org/1275/.  For the boot loader phase of the UEFI PI, the most well known embodiment is the Unified Extensible Firmware Interface (UEFI) presently at revision 2.4 http://www.uefi.org.  

For an architecture to implementation mapping, SEC, PEI, DXE, and BDS can be found in the 5 volumes of the UEFI Platform Initialization (PI) specification, presently at revision 1.3, at http://www.uefi.org.  The architecture is represented by .h files in the https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/ and implementations of the platform portable elements in https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/.  For coreboot, an overview can be found at http://www.coreboot.org/Welcome_to_coreboot and representative implementation practice at http://review.coreboot.org/#/q/status:open,n,z.  

The story is not so straightforward, though.  Coreboot can have edk2-style firmware as a payload, such as found in the 'PIANO' project, or 'Payload using Tiano.'  Recall that "Tiano" was Intel's original code-name for what became the Intel (R) Framework and EFI, then UEFI PI and UEFI reference implementation.   You can still find reference to 'Tiano' on the edk2 project http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2, too.  Correspondingly, the Boot Device Selection (BDS) driver in a edk2-based PI implementation can do a direct Linux kernel load and publish a FDT, as found in ARM Ltd's (R) adaptation of edk2 in https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmbeddedPkg/.  

The point of FDT/ACPI is to expose non-discoverable resources to the operating system.   And the point of U-Boot/UEFI is to assist in loading the operating system kernel via the local NV store, disk, or network and passing control to the same.  We discuss some of the uses of UEFI/PI for embedded at http://linuxgizmos.com/using-uefi-in-embedded-and-mobile-devices/, too.

Recall my mention of Intel Architecture above.  In general, UEFI has processor bindings to 32-bit or IA32 and 64-bit Intel Architecture, or 'x64' as known in the UEFI spec.  The latter has been alternately called x86-64, AMD64, EM64T, and Intel64.  UEFI also supports Intel(R) Itanium and both 32-bit and 64-bit ARM ISA.  The latter 2 are Aarch32 and Aarch64, resp.  Beyond that, there have been ports to other architectures not covered by the UEFI specification, such as 32-bit MIPS http://sourceforge.net/projects/efi-mips/.

Correspondingly, the coreboot tip has IA32 support and recently has added 32-bit ARM.  In the past, PowerPC support was also found in this project.

U-Boot has an even broader CPU support set since for certain CPU and platform architecture, the hand-off to the "Boot Loader Phase" can be done by opaque firmware and hardware in the platform.  In other words, the "reset vector", "memory init," and "I/O init" happen in the 'hardware' and do not require UEFI PI or coreboot style processing.

So in the spirit of 'information' versus 'advocacy,' you can see that the different facets of the solutions above can map to alternate deployment needs.  For a shrink-wrap OS that wants a guarantee of system board behavior into the "boot loader phase," the industry standard ACPI+UEFI couplet has some merit. For defacto standards like the kernel load protocol of Linux, FDT+U-Boot or FDT+UEFI may suffice.  

And the distinction between architecture and implementation rears its head again with respect to security.  As noted as recently as Blackhat this year by Yuriy Bulygin, et al. http://www.blackhat.com/us-13/speakers/Yuriy-Bulygin.html in their presentation http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-Bazhniuk_BHUSA2013.pdf, any flaws in implementation of the architecture can allow for bypassing of the controls for which the architecture was intended to enforce. In this case, the policy objects and implementation of UEFI Secure Boot represented the implementation artifacts that failed to successfully refine the architecture to the code in the system board storage. This is an example of the classic assurance consideration and reads into the firmware design space.  Security is not alone.  Performance, manageability ease-of-use, size, and other metrics can be impacted by the refinement process of a high level architecture to code.

As a final thought, I will be at the Intel Developer Forum next week talking about "UEFI Secure Boot and Linux" https://intel.activeevents.com/sf13/connect/sessionDetail.ww?SESSION_ID=1064.  This talk reads on many of the themes treated in this blog around building an implementation of an architectural feature, specifically the administration of policy objects for features like UEFI Secure Boot. For this talk, the architecture of UEFI Secure Boot can be found in Chapter 26 of the UEFI 2.4 specification.  This has our familiar friends the Platform Key (PK), Key Exchange Key (KEK) and the allow/disallowed list of the db/dbx.  These authenticated variables and how they inform the policy-based load of 3rd party UEFI images is well defined in that document.  What is absent from the document is how a security administrator (e.g., security_admin_r) or end user manages the UEFI Secure Boot behavior.  This gap stems from the absence of manageability interfaces to a given platform in the UEFI Specification, among other things.

So in order to appreciate UEFI Secure Boot as an end user, the description and implementation of the feature in chapter 26 is necessary but not sufficient.  Even for assessing the overall integrity goals of the feature, you need to assess the end-to-end solution, such as shown below in one embodiment.

End-to-end platform integrity

As you can see from above, the underlying UEFI PI implementation must guarantee its provenance, such as through NIST 800-147 http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf specified updates.  Another means by which to effect the same would be a load-time verification of the UEFI PI code from the 'hardware' block that I will discuss at IDF.  Finally, SUSE will discuss some options to support the "OS Secure Boot."  Note that the UEFI specification only reads on the center of the diagram, and even for this portion, it does not describe how to manage the PK, KEK, and DB/DBX other than through cryptographically signed updates of the same by the private key owner.

For the latter key management, a end user who is a kernel hacker may manage the key store directly via physically present interaction with the firmware setup screens and load his/her own keys. A consumer, on the other hand, just wants it 'to work' with live CD's and other shrink-wrap binary images from different OS vendors without any administrative changes. In the former two cases, the 'owner' and 'user' are typically one in the same. A corporate IT, on the other hand, only wants the IT staff to manage and change these options since the 'user' or knowledge worker of a client machine is distinct from the 'owner', who is typically the knowledge worker's employer.  And the IT staff simple acts as an agent of the owner and the owner's elevated privileges.

On the subject of assurance, many people use UEFI variables for storing PI-specific content. The problem with that scheme is that after the signalling of EFI_END_OF_DXE_EVENT_GUID from volume 2 of the UEFI PI spec at www.uefi.org (aka "Exit PM_AUTH" from http://www.intel.com/content/dam/doc/white-paper/uefi-pi-tcg-firmware-white-paper.pdf or "Exit Mfgr Auth" from http://www.uefi.org/sites/default/files/resources/Intel-UEFI-ThreatModel.pdf) and/or when BDS does a connect on the driver load list and the UEFI boot variables, 3rd party UEFI content will run. Even in the case of UEFI Secure Boot, you know the provenance of code but not if the UEFI loader or OS runtime will attack the platform. Given that case, the PI-only variables should be prohibited from change by the 3rd party UEFI drivers, applications and operating system runtime.  One way to do this protection is to use the edk2 variable lock protocol (EDKII_VARIABLE_LOCK_PROTOCOL) http://permalink.gmane.org/gmane.comp.bios.tianocore.scm/842.  Note that this API is in the edk2 project but not prefixed with "PI" or "EFI" since it does not exist in the industry standard specification. This API allows for downgrading a variable to read-only (RO) from read-write (RW) prior to running third party code. It also covers a gap in the UEFI  and PI specifications wherein the SetVariable API in chapter 7 of the UEFI specification does not read on creation of RO variables; the main UEFI specification only describes the need for a set of RO variables to exist.  How the underlying PI-based code creates these RO UEFI variables was left as an exercise for implementations.  The EDKII_VARIABLE_LOCK_PROTOCOL provides one 'answer' to that exercise.

So what have we seen in this blog?

1) Explanation of technology without marketing for same

2) Many examples of architecture versus implementation

3) For boot firmware, there are many different architecture and implementation

4) Take due care in traversing from architecture to implementation

5) Take a systems view of a solution beyond a given technology's architecture and implementation

A Technical Career Path

I was recently asked to provide a short video on technical leadership and the technical career path.  When I asked the opinion of some friends on the subject matter, one response was "tell them it's 'better to be lucky than good.'"  I was a bit too tired in that AM to reply with something witty like Einsteins' quote "God does not play dice." or some such, but I do believe that there are some guidelines that can help in a technical career.   To that end, I have broken those guidelines out into a few key points.

To begin, for any hope of success in a technical career path, you must have....

1. Passion

The modern work routine doesn't fit nicely into an 8-5, M-F schedule.  Whether it's meetings with colleagues in other countries or thinking about a particular problem while in the shower, the tasks will remain with you.  So if you are not passionate, excited, and engaged on the domain of application for which you are employed, this constancy of the job will become a torture and a prison.   Instead, you should be excited about the subject and eager to continue exploration in the space.

Of course, passion is laudable but it will not necessarily earn you a paycheck.   Upon the foundation of passion you need to build a layer of....

2. Technical IQ

By technical IQ I mean cultivating domain expertise in an area that includes both the theory of and ability to implement the domain.  In fact, in the software world, you can alternately get paid for having some deep equity in domain expertise, with executable results including writing specifications, engaging customers on requirements, etc, or the implementation skills within the confines of a given software language, such as C, C++, Haskell, Python, etc.   The domain expert can talk a lot but often not deliver the product, such as the classic 'architect.'  The software engineer can reduce the architect's specification into a programming language embodiment.  You can get paid for either, but you can get paid a lot more for being able to do both.

In addition to domain expertise, I often argue for the 'broad and deep' approach.  One way to guide oneself in the breadth is to look at adjacency's.  For example, doing boot firmware like UEFI, I need to understand the layer above and below.  Above includes the operating system UEFI boots and interact with at run time.  The Below includes the hardware that the UEFI PI layer initializes on restarts and helps manage at run time.  The depth is in UEFI, PI, ACPI, C, assembly, networking protocols, cryptography, CPU and platform macro-architecture.   The breadth includes Windows, Linux, RTOS's (above) and micro-architecture, PCI, USB, I2C, GPIO, SD, TPM, SRAM, DRAM, DDR, digital and analog circuit design below.

Since I want to narrow my efforts to the most appropriate for my employer, the breadth also includes the business environment, strategy, and market goals within which I exercise by domain expertise and implementation skills.

Technical IQ is great, but the days of the lone programmer and inventor are long past.  The passion and technical IQ need to be done exercising....

3.  Emotional IQ

By Emotional IQ I mean the ability to work with, for, and through people.  Any corporation or technical endeavor invariably entails interaction with people.  In fact, I would argue that business entails concerns of people ahead of the technology details.  And to that end, the sophistication of this engagement can be scoped better.  As I remind myself, there doesn't exist a "Moore's Law" for human psychology.  Follow the golden rules, respect others, find value and richness in interacting with others, and pursue those opportunities beneficial to all.   As you advance in your career, you begin to rely on others as much as others will rely on you.  Just as you should always seek out mentors in your career, progressively move into the role of mentor for others.

So now that you have the passion, or Aristotle's Prime Mover that starts you on the journey.  This passion is coupled with both formal/informal education and on the job experience for Technical IQ.  And the Technical IQ is exercised in the context of others using your Emotional IQ or "EQ."   So where do you go next.   With these three elements in hand, .....

4.  Do something wonderful

You have the passion for, skills to, and colleagues with whom you can be a technical leader, so lead.  Take a risk.  Do something wonderful.  All technology was someone's idea at some point.   In fact, as Alan Kay says, the 'best way to predict the future is to invent it.'   I would argue that the landscape for invention, innovation, and creation has never been more fertile.   The lines between the hardware, firmware, operating system, application, and middle-ware are constantly moving and blurring.  Be that agent of change.

So now that I have 1-4, is there more?   Yes, exercise 1-4 with the following in mind....

Philosophical Postscript

With all of that being said, the ideals and reality often don't meet for some.  In fact, I'm often asked 'why can't I get promoted' or other such concerns.   My reply is pretty simple:  "It's the journey, not the destination."   Notice that nowhere in stages 1-4 above did I have a 'become chief super scientist' or other such exalted title.   The title doesn't matter.   What matters are the stages above.   And in fact, I'd even mention something like Zen and the art of archery - the more you try to hit a certain target (e.g., 'promotion'), the harder it will become.   Treat work as play.  Enjoy the trip.  Feed your passion (1) for a subject by learning more about it (2) and engaging with others on the subject (3), culminating in creation that helps the business (4).   Being diligent on these levels will yield the appropriate fruits.

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

What is 'Compatibility'?

So why another blog just a week after the last one?   Given the aperiodic nature of my earlier blogs, this frequency seems a bit out of character.  Well, I finished reading Fowler's Passionate Programmer and he exhorts the reader to practice, practice, practice.  Not just code, but writing.  And one venue for writing is a web log.  No referees, reviewers, publisher, etc between my typing and publication.  So here you go, for better or worse.

Now back to the topic of this blog.

There is often talk of 'compatibility' in the computer industry.  From the perspective of the platform firmware, we define compatibility as 'the software you choose to run.' In this taxonomy, compatibility is not some absolute term or Platonic truth living outside the world but instead very much a contextual term.

So this is all well and good, but how does this relate to the platform firmware specifically?  In the case of the boot firmware, we think of compatibility in terms of the PC/AT BIOS and its interfaces.  These interfaces include the 16-bit int-callable interfaces published by the system board BIOS and BIOS extensions for use by booted software.  The 'booted software' can include the MBR first stage loader and subsequent system software. The BIOS industry referred to these int-callable interfaces, such as int10h for video, int13h for disk, int16h for keyboard, along with data structures like the BIOS Data Area (BDA) and Extended BIOS Data Area (EBDA) as the "BIOS Runtime."  This BIOS Runtime is distinct from the code that executes after a platform restart and the germination of the BIOS runtime interfaces.  This phase of execution has been historically lumped under the term Power-On Self Test (POST).

Back in the early 1999 when the Extensible Firmware Interface (EFI) was first being deployed, this phase of execution, or the Boot Services (BS) and subsequent Run Time (RT), were really akin to the BIOS Runtime.   This parallel is borne of the fact that the EFI specification, nor its successor the UEFI specification, dictates 'how' these environments appear.  The pre-EFI/UEFI phase is opaque to and distinct from the UEFI BS and RT, just as POST is distinct from the BIOS Runtime and its int-calls.

In the case of EFI, the Intel Platform Innovation Framework (aka "Framework") and its successor, the UEFI Platform Initialization (PI) specifications, defined a stylized POST phase.  This includes the SEC, PEI, and DXE phases of execution.  But just as EFI is distinct from its preceding phase, the PI phase does not necessarily have to create a full UEFI environment.   And it is this PI versus UEFI where compatibility comes into play.   You see, as EFI and UEFI worked to gain acceptance, the bulk of platforms in the market since 1982 supported PC/AT BIOS and 16-bit BIOS option ROMs and OS loaders.

To leverage that large class of 'legacy' BIOS infrastructure, the Compatibility Support Module (CSM) was borne.  The CSM was developed by a project that preceded the "Tiano" program but was codified into a Framework Specification http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-compatibility-support-module-specification-v097.html.  This earlier program referred to the compatibility code as the 'fur ball' with the hope that one day a native mode firmware stack would prevail and 'cough up' the compatibility codes.

The CSM provides a way to encapsulate a BIOS runtime inside a Framework or PI-style firmware.  The CSM specification abstracts the information collected during a PI-style POST, namely SEC, PEI, and DXE, and passes that information into the CSM wrapped version of a BIOS 16-bit runtime.  We often refer to this binary in our edk2-based trees as a CSM16 binary.

Recall that UEFI provides services for blocks such as the EFI Block I/O protocol, and the BIOS supports similar capabilities via the int13h API.  To leverage an underlying 3rd party storage option ROM's 16-bit disk services, a UEFI driver can be generically written to thunk or call down into the 16-bit code.  The thunk is provided as a general utility via a API member of the CSM protocol.  There is also a reverse thunk, but it is rarely if ever used.  You see, a CSM16 cannot practically call back into native UEFI 32-bit or 64-bit code because when control is passed to a 16-bit MBR loader, the int15h E820h memory map that the legacy OS receives has the UEFI boot service pages mapped as available.  And since there is no equivalent of ExitBootServices() for a legacy OS boot, UEFI services in the form of boot services drivers cannot reliably be invoked via a reverse thunk after the int19h IPL.

EFI/UEFI calling down into PC/AT BIOS CSM16, on the other hand, can be done throughout the boot services phase since the CSM16 services are available until ExitBootServices, so a BiosBlockIo or BiosVideo driver can reliably thunk to the int13h and int10h CSM16, respectively.   The only way to have 32-bit or 64-bit native codes that are shareable between CSM16 and a DXE-based UEFI BS is to put the codes into something like a DXE SMM driver.   The downside of the latter is that 3rd party UEFI drivers cannot be loaded into SMRAM.  This only works for system board hardware, such as USB ports in the chipset.

And now even within EFI/UEFI there are compatibility concerns.  EFI1.02 to EFI1.10 introduced OpenProtocol, and implementations of the EFI1.02 HandleProtocol had to use the later reference-counted API to implement the earlier non-reference counted API.  Then UEFI2.0 in 2006 deprecated UGA and DeviceIo.  From UEFI2.0 to 2.1, then 2.2, 2.3, 2.3.1 have introduced new services.  Framework HII to UEFI HII.  A style of programming to maintain compatibility often includes reading the specification version in the system table in order to take the appropriate code path.  The same holds true for PI.  PI became with the donated Intel Framework specifications, and from Framework 0.9x to PI 1.0, 1.1, 1.2, 1.2.1, 1.2.1a, etc there have been similar concerns with SEC, PEI, DXE, SMM.

So that's my blog for today on compatibility.

32 versus 64 bit and measuring UEFI Secure Boot

This blog begins with a discussion of the execution mode of the pre-operating system (OS) and the operating system run time (RT).   This is a question that comes up often, so I wanted to given some overview and history.

32v64 - The OS view of the world
We'll being with the OS-visible portion of the pre-OS, or the UEFI boot services (BS) environment.  For today's 64-bit (aka x64) operating systems, you need a 64-bit kernel to be booted from 64-bit UEFI firmware.  Or BS and RT execution modes need to match the kernel execution mode.  Similarly, a 32-bit OS kernel needs a 32-bit RT and 32-bit BS.  For example, x64 (aka x86-64, EM64T, AMD64, Intel64....) Ubuntu or Windows8 need to have x64 UEFI.

On this point UEFI differs from 16-bit PC/AT BIOS where you can boot 16, 32 or 64-bit kernels.  In 1982, BIOS was 16-bit, as was Microsoft DOS.  The I/O subsystem of DOS was the BIOS, so the DOS run time calling into the 16-bit BIOS int-calls worked out well.   DOS was single-threaded, BIOS calls are blocking, and everyone was happy.  This worked through Windows3.1 where DOS was still effectively the kernel.  The tension in this model appeared with 32-bit OS's where the kernel would 'thunk' or make down-calls into BIOS when necessary, alongside the 32-bit native driver model with VxD's.   With NT and beyond, though, the kernel would have native drivers such that the BIOS was only used for booting.  Same story for Linux with its pure native drivers.

And on the point of booting, the first stage OS loader would typically stay in 16-bit mode in order to read the kernel from disk or network using 16-bit BIOS calls.  Then the kernel would trampoline into 32-bit mode in order to run the native OS kernel.  When x64 came on the scene in the mid-2000's, this trampoline process was extended to go from 16-to-32-to-64 bit mode.   

The notable point on PC/AT BIOS and OS run times today is that modern OS kernels do not invoke 16-bit services after the initial loader.   This is distinct from EFI/UEFI with its 'runtime' (RT) services which are by-design intended for OS kernel invocation.

Specifically, UEFI, on the other hand, took a different path.  The original EFI 1.02 specification in 1999 had an IA32 (aka x86) binding that was 32-bit only.  EFI antedated the relase of x64.  EFI1.02 continued having only the IA32 binding.  When x64 became public, it was still prior to 2006 and the standardization of EFI as UEFI.  Intel owned the EFI specification at the time and pondered how to address support of x64.  One side of the EFI house advocated today's behavior where the firmware Instruction Set Architecture (ISA) mode == kernel ISA mode, whereas a smaller group was in the camp of a modal solution.  

Enter the '2-headed firmware.'   The idea of the firmware having two modes or 'heads' was to forever keep EFI as 32-bit and having the ability for a 32-bit or 64-bit set of run time services to be published from the firmware for the kernel (32 or 64) to call.'  

The requirement for the kernel to match the firmware begins with the ISA mode of the EFI RT.  To support run time services, the kernel maps the EFI run time and directly calls into it from ring 0.  Since the EFI run time is defined to be the same as the EFI boot services in the EFI system table, RT and BS must be the same.  This leads to the model where if you want to boot a 64-bit OS, you need 64-bit firmware.   Modern OS eschew 'thunking' or down-calling into 32-bit mode from a 64-bit kernel, unlike the practice of doing this from user mode (e.g., WOW64 in Windows and capability binary support in Linux).

So back to the 2-headed BIOS versus the pure 64-bit firmware.  Both solutions were built, but it was quite tricky to implement the 64-bit RT.  We ended up with building a shim that invoked an SMI so that the bulk of code shared between 64-bit and 32-bit RT was handled by the Framework SMM DXE code (i.e., SMM driver model prior to the UEFI PI).  The 64-bit EFI was cleaner since the mode of EFI is also the mode of DXE, our EFI core.  And with the UEFI 2.0 specification in 2006, the 64-bit work was contributed and became one of the central features of the industry-owned specification.

For a refresher on UEFI versus PI, check out Beyond BIOS http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/ or chapter 3 of Hardware Dependent Software http://www.amazon.com/Hardware-dependent-Software-Principles-Wolfgang-Ecker/dp/9048181283/.

After all of the that, you can see why ACPI and its static tables and interpreted AML byte-codes are the preferred run time interface to the platform for PC/AT BIOS and UEFI systems today.  The co-location of the UEFI RT with the kernel in ring 0 and some of the vagaries listed above in implementation argue for not growing the corpus of UEFI RT capabilities.

32v64 - The platform construction view of the world
You will note above some discussion of DXE along with the EFI ISA mode work.  Just as the UEFI RT dictates the UEFI BS mode of operation, the UEFI BS mode dictates the Driver Execution Environment (DXE) mode of operation since the Framework and UEFI Platform Initialization (PI) DXE forms the core of the EFI and UEFI interface sets, respectively.   The same holds true for Framework and PI SMM in the DXE is the SMM loader, so the ISA mode of DXE boot service-time became the mode of the SMM DXE.   Once the die was cast for 64-bits, almost everything in the pre-OS became 64-bit.

"Almost everything" was the case because there are a couple of modes of operation prior to DXE, namely the SEC and PEI phases.  These two phases commence after a processor reset.  Even with the advent of x64, Intel Architecture CPU's still commence operation in 16-bit mode.  As such, the SEC phase mode switches to the PEI mode of operation.  PEI can execute in 32-bit or 64-bit mode.  Some of the complexities of 64-bit long mode entail larger binaries and having to run with paging enabled.  These can be covered by budgeting for the flash space for larger code images and setting up ROM'd page tables with the AD bits pre-set so that page fault walkers don't panic trying to update read-only PTE's.  The advantages of having the ISA mode of PEI and DXE match also include having codes from PEI that can be passed into DXE and re-used, such as the PE/COFF loader and the report status code logic.  The latter is especially important in that prior to loading the DXE architectural protocols, a HOB proxied report status code pointer can be used to update the boot progress during the grey period between PEI hand-off and DXE start up.  32-bit mode, on the other hand, can run in physical mode without paging.  Since such PEI execute in place (XIP) codes rarely need greater than 32-bit addressing and need to be penurious on code size and data usage because of cache-as-RAM size limitations, today PEI implementations are typically 32-bit and the final PEI, or the DXE IPL PEIM, will mode switch to 64-bit as part of invoking DXE Main.

So in summary, the ISA mode of the firmware and the OS kernel is not so simple of a story, and the story is again distinct from the ISA mode of the early PI phases of execution.

So enough on 32-bit and 64-bit.   

Note (3/4/14):  Matt Fleming has an experimental patch treating booting a 64-bit Linux kernel on a 32-bit UEFI platform https://lkml.org/lkml/2014/3/4/242 

UEFI Secure Boot - Measuring Policy
The other thing I wanted to mention was a recent publication on MSDN, namely the Trusted Execution Environment (TrEE)  EFI Protocol and measurement updates, which can be found at http://msdn.microsoft.com/en-us/library/windows/hardware/jj923068.aspx.  This publication is important because the language toward the end around PCR[7] logging of the UEFI 2.3.1c PK, KEK, and DB/DBX addresses one of the architectural gaps of scenarios that employ both measured and secure boot.  Recall that the paper "UEFI Networking and Pre-OS Security" at https://noggin.intel.com/content/uefi-networking-and-pre-os-security-0  describes the relationship of measured and secure boot.  Specifically, on page 94 of the same, "...Measured Boot must include the Allowed, Forbidden, KEK, and PK variables (databases) in its measurements of a Secure Boot-configured platform."  As a result, the measurement language in the TrEE protocol provides a solution for recording the state of the UEFI Secure Boot enforcement policy.