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.

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.