A legend passes

Sad to see the news about Ross Anderson https://en.wikipedia.org/wiki/Ross_J._Anderson passing

https://alecmuffett.com/article/109513

https://news.ycombinator.com/item?id=39864210

https://twitter.com/duncan_2qq/status/1773752269395099774 

Like many I was inspired and informed by his various editions of the "Security Engineering" book https://www.cl.cam.ac.uk/~rja14/book.html. I also explored the domain via papers like https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf that I referenced in https://www.researchgate.net/publication/221199899_Platform_Trust_Beyond_BIOS_Using_the_Unified_Extensible_Firmware_Interface/references. I also cull wisdom from papers like https://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf since having worked on the boundary of software and hardware for so long, sometimes errant hardware or firmware is truly an embodiment of 'Satan's Computer.'

My small interaction with Prof Anderson was during the writing of https://link.springer.com/book/10.1007/978-1-4842-6106-4

 

 My co-author and I reached out to see if Anderson would write a forward, with the below response

Luckily we did get a very insightful write-up

from Leendert Van Doorn https://blog.paramecium.org/about/.

This was an ironic pairing in retrospect seeing Anderson's critiques of Trusted Computing and Leendert's contemporary contributions to that domain, respectively. Having these titans both critique https://www.cl.cam.ac.uk/~rja14/tcpa-faq-1.0.html and build a domain https://www.amazon.com/Practical-Guide-Trusted-Computing/dp/0132398427, like TCPA (now TCG https://en.wikipedia.org/wiki/Trusted_Computing_Group) Trusted Platforms Modules, represent a healthy aspect of technology evolution in my view. Differing views make any technology stronger, versus groupthink & homogeneity of thought.

 Sad times for the security community, though, with the loss of a legend.

Blue Hat 2023 and UEFI Secure Boot

“Victory has 100 fathers and defeat is an orphan.” This quote is attributed to John F. Kennedy in the wake of the Bay of Pigs but I believe a variant of this has been passed down over time. I was thinking of this quote in the context of UEFI Secure Boot this week at Blue Hat https://www.microsoft.com/bluehat/ at Microsoft building 92. Visiting the Microsoft campus reminded of me the many hours engaged with Microsoft during the build up to this feature in the mid-2000’s (including hours in the 40's buildings that were razed recently for the new MS campus).

The above talk from Eclypsium (now posted https://github.com/n0x08/ConferenceTalks/blob/master/0-Day_FirmWarez_BlueHat2023.pdf)  this last week also reminded me of how UEFI secure boot and firmware security is now part of the tech lexicon.

But back to the history discussion from the early 2000's. At that time, the industry was recovering from the lack of adoption of NGSCB https://en.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base. Intel LaGrande Technology (LT), 

which is now Trusted Execution Technology, along w/ AMD Pacifica/Presidio, were features to add ‘late launch,’ or ‘dynamic root of trust for measurement’ (DRTM). The DRTM facility provided an RTM in the CPU, and the roots of trust for storage (RTS) and recording (RTR) were delegated to a ‘then’ off-chip element called the Trusted Platform Module (TPM) https://trustedcomputinggroup.org/work-groups/trusted-platform-module/.

Since NGSCB, with its “Trusted Applet” (TA) architecture ,was a mile too far both for privacy and application compatibility, LT and Pacifica didn’t get embraced by Windows. NGSCB entailed the need to refactor applications to put security sensitive codes into a memory-only execution regime. Although in 2023 folks may say ‘so what, SGX did it,’ recall this is 2002. So folks like Peter Bidell managed to build a full-disk encryption (FDE) feature around the TPM and a BIOS-based root-of-trust for measurement (RTM), called the Static RTM (SRTM).

This is where I entered the scene. I worked with folks like Mark Williams to author and enable the EFI TPM and platform specifications. The former entailed the API exposed to UEFI drivers and OS loaders/applications, and the latter defined what type of code and data objects to record or ‘measure’ in the TPM’s Platform Configuration Registers (PCRs). More information on the various RT*’s and the TPM can be found in https://www.intel.com/content/www/us/en/content-details/671466/trusted-platforms-uefi-pi-and-tcg-based-firmware.html.

 

While doing this work with Microsoft, I learned that recording the hash of the Portable Executable/COFF (PE/COFF) image was not so simple. It entailed hashing various portions of the binary and omitting others. It turns out this hash or ‘digest’ is a critical element for code integrity (i.e., what became documented as the Authenticode hashing algorithm). At the same time Microsoft was reeling from no DRTM, it moved to static verification with the invention in Vista of Code Integrity, or (CI). CI entailed having the OS loader cryptographically verify the digital signature of the early boot and kernel components in Windows, thus having something of a static root of trust for verification (RTV), with the ‘root’ being the OS loader.

I learned about how all of this CI worked after reading Matthew Conover’s paper https://github.com/tpn/pdfs/blob/master/Assessment%20of%20Windows%20Vista%20Kernel-Mode%20Security%20-%20Matthew%20Conover%20(Symantec).pdf. 

This feature is also described in https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1327.pdf. Learning about how CI worked and the top-of-mind reminders from folks like Heasman

https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf

led me to suggest adding an ‘SRTV’ to the firmware to complement the existing ‘SRTM’ we had been building. I roughed out some of those thoughts in the 2007 paper

https://github.com/vincentjzimmer/Documents/blob/master/SAM4542.pdf https://dblp.uni-trier.de/rec/conf/csreaSAM/Zimmer07.html?view=bibtex mentioned in earlier post

http://vzimmer.blogspot.com/2022/08/pqc.html, too. 

In other words, leaving the OS loader hanging in space to start the verification chain seemed fragile, so having the underlying firmware act as a static RTV for the loader would strengthen this static verification chain. It was also complemented by the SRTM since the TPM could provide evidence or an audit log of the verification actions. 

Given the difficulty in crafting pre-OS malware w/ MBR's for PC/AT boot, the lack of interoperable code integrity in UEFI would have made things so painful as I noted in http://vzimmer.blogspot.com/2012/09/late-september-mumbling.html. Also, extending CI into the host firmware felt as natural as extending the OS filesystem via the EFI System Partition (ESP) into the firmware for purposes of interoperability.

One of the challenges posed during this work was to have a reasoned approach to the infrastructure. That’s where Varugis (former NGSCB TA architect turned Windows CI architect) and I tried to create an integrity model of the pre-OS https://github.com/vincentjzimmer/Documents/blob/master/integrity-protection-analysis-of-OS-preboot.pdf. Varugis would often rail against folks who said the BitLocker was for code-integrity since it was largely a data integrity feature. He wanted to ensure that any functionality built into the ecosystem had a sound foundation. To that end the platform was decomposed into a series of Clark-Wilson compartments (although the CDI’s of CW and reuse of acronym of the same in TCG DICE is amusing). The OEM compartment, extensible pre-OS UEFI compartment, and finally, the OS compartment had rules, including guards and access controls.

It turns out that since CI was just for internal use by Microsoft tooling, the Authenticode hashing algorithm and signature section of the PE/COFF were not documented. Just as UEFI needs MS FAT and PE/COFF itself for purposes of interoperability, this information was added to the public document from Microsoft to support this capability

https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/authenticode_pe.docx, as were the required infrastructure elements in the 2.1+ specifications. The variant of UEFI Secure Boot that ultimately shipped as a required capability in Windows 8, along with UEFI measured boot, was the specification version 2.3.1 http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_1.pdf.

Another interesting tie-in to last week's Bluehat was the keynote from Mark Russinovich. Mark was one of the people to whom we presented this UEFI Secure boot work back in the day, too. Others in the audience at the included MS security arch, and former Intel colleague, Carl Ellison.

BTW
ECR48 was remastered in M279 https://uefi.org/specs/UEFI/2.10/Frontmatter/Revision_History.html

Mark's keynote at Bluehat covered confidential computing, large language models (LLMs) for security, open source firmware foundation, safe languages, and the software supply chain. 

On safe languages

I was reminded of https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf, https://uefi.org/sites/default/files/resources/Enabling%20RUST%20for%20UEFI%20Firmware_8.19.2020.pdf, and https://link.springer.com/chapter/10.1007/978-1-4842-6106-4_20.

And for the challenges of the open source supply chain, and software supply chains in general, I commiserated with

These slides reminded me of the long-used

from https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure, too.

OK. Back to the narrative. By this time the UEFI secure boot capability had iterated through early discussions and into the standards incubation mix. The final clean-up of how authenticated variables work, including the append option for servicing, were introduced by Magnus. Magnus Nystrom was the security lead in Windows core OS and managed to get the feature finally into the OS. We described some of this journey in https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf.

One of the challenges of this work was how to apply trust for the more open PC architecture. Cell-phones and other appliances had locked-down bootloaders, but with the PC and its ability multi-boot (think reason for UEFI existence) and adapter cards, the trust needed to be more interoperable. This is where the concept of the various stakeholders, through the OEM with the PK, the OS vendors and ISV’s with the KEK’s, and the hash or verification certificates in the allowed DB and disallowed DBX were created. 

Tim Lewis https://uefi.blogspot.com/ championed a lot of the details on this design through the forum, too. Tim also led the UEFI Security Subteam (USST) in those first heady years.

A spate of additional publications were created to describe this capability, including https://github.com/tianocore-docs/Docs/blob/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf created in the wake of my first ToorCamp talk, to https://www.intel.com/content/www/us/en/content-details/671464/a-tour-beyond-bios-with-the-uefi-tpm2-support-in-edk-ii.html and https://www.intel.com/content/www/us/en/content-details/671120/a-tour-beyond-bios-uefi-authenticated-variables-in-smm-with-edk-ii.html on how to use the code https://github.com/tianocore/edk2/tree/master/SecurityPkg. Given the long arc of this work, https://link.springer.com/book/10.1007/978-1-4842-6106-4 was created to collect this background in one location.

The evolution of UEFI secure boot wasn't without some controversy, especially from privacy groups and others who worried about lock-down of the PC https://www.csoonline.com/article/2221385/geeks-under-fire--war-on-privacy--freedom-and-general-computation.html, but Microsoft logo requirements like a physically-present user control for this feature, along with the UEFI CA signing Linux shim's, helped calm those concerns - some of the great work w/ Linux in this space was described in https://www.intel.com/content/dam/develop/external/us/en/documents/sf13-stts002-100p-820238.pdf, too, although it was always smooth sailing as I recall people glowering at me when I presented https://github.com/vincentjzimmer/Documents/blob/master/PLUG-UEFI-001.pdf in Portland. One of the MS PM's even told me that Sinofsky considered pulling all of the UEFI features from Windows 8 if the issue were not resolved in a timely fashion which makes sense given that wide-scale UEFI deployment without integrity controls would have led to unbounded pre-OS malware concerns for users.

Work continues apace in this area, from investigations into post quantum cryptography https://eprint.iacr.org/2021/041.pdf https://uefi.org/sites/default/files/resources/Post%20Quantum%20Webinar.pdf to better revocation models https://github.com/rhboot/shim/blob/main/SBAT.md. And DRTM is getting great traction in the platform now https://cdrdv2-public.intel.com/756963/DRTM-based-computing_whitepaper_FINAL_MAY2021.pdf, although contemporary with Windows 8 we worked hard to see if we could have a standards-based solution https://trustedcomputinggroup.org/work-groups/trusted-platform-module/, too. DRTM definitely reduces the trusted computing base (TCB),

thus why the DRTM and optional DRTV were mentioned in https://www.intel.com/content/www/us/en/content-details/671466/trusted-platforms-uefi-pi-and-tcg-based-firmware.html, too.

And some of the ecosystem challenges of distributed trust, as shown in the 'figure 5' above with the various trust anchors for UEFI secure boot (including the UEFI CA and revocation lists like the dbx https://uefi.org/revocationlistfile), don't magically disappear. I was reminded of Mark Twain's 'History never repeats itself, but it does often rhymes' recently during a presentation in the Open Compute Project Security team  https://www.opencompute.org/wiki/Security discussion on January 31 https://docs.google.com/document/d/1VVMUzYESZNuyT1_YJlQSdSKBy-5t1otJIyXTbXuOoX4/edit# regarding a CA for the device firmware for usages like SPDM. Some of those melodies included:

"If there is an explosion in the number of CAs how will verifier vet the trustworthiness of the CAs?

..

Want to see a manageable number of CAs under a common policy

..

Trust stores in components will have large number of anchors and have reoccuring updates

..

Devices without internet connectivity cannot retrieve trust anchor info

..

Small vendors may have difficulty operating root CAs

..

Common PKI CA policy."

These are many of the issues UEFI has encountered and grappled with since the late 2000's.

So back to the quote at the top of the posting. The reason for many ‘fathers’ is often that for an idea to come to market the originator of the concept needs many hands to help shepherd it forward through the vagaries of business, development, validation, and ultimately shipping at scale. And as I updated Ubuntu on a home PC this weekend and noticed,

this stuff is still pretty cool. 

PS

A PhD colleague of mine recently decried the lack of authoritative knowledge, from blogs to arxiv. Luckily in this scurrilous post (aka 'blog')  I haven't claimed any refereed, authoritative discourse. These are more the late weekend musings motivated by wonderful arc of interactions with colleagues, many of who have changed companies, retired, or passed away. 

Lest that sound unhappy, though, I did catch up with David and crew over Teriyaki on Thursday. As I offered them some Bluehat swag

David let me know that he and the Microsoft team who implemented UEFI Secure Boot in Windows actually won a Microsoft-wide award that year, viz.,

Very nice (although the referenced link is dead).

Even in the world of cyber-everything, I do like the physical relics (including security faux currencies)

spanning journey's from 

to

https://github.com/rrbranco/BlackHat2017 

I guess this closes the circle for this blog. I opened with Nate Warfield prezo https://www.helpnetsecurity.com/2022/06/19/eclypsium-executive-team/ and he's part of https://eclypsium.com/company/ which is led by Yuriy and John, my co-presenters from the 2013 Cisco seccon talk. 

operating system vendors and firmware

The PC industry has followed an interesting arc, beginning with the hardware and firmware details of the original IBM PC http://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf and the closed source Microsoft (MS) operating system MS/DOS https://github.com/microsoft/MS-DOS. The former allowed for the ability to have clones of the IBM PC, whereas the latter ensured some consistency in the platform design as compatibility with DOS, and then Windows, helped provide for the open platform that non-MS OS's like Linux today enjoy. 

Was the distinction between MS as an OS vendor (OSV) and the industry as a platform provider always so stark? In fact, the existence of MS-written firmware, as one example, has had various examples spanning the 90's up through today's news. 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To begin:

In the early days of Windows NT, including 3.51 and 4.0, Microsoft wrote the ARC boot firmware for their DEC Alpha and MIPS NT platforms. ARC stands for Advanced RISC Computing https://en.wikipedia.org/wiki/Advanced_RISC_Computing and the document http://www.netbsd.org/docs/Hardware/Machines/ARC/riscspec.pdf provided guidance on both platform hardware and firmware. A couple of MS engineers wrote the first ARC firmware and the ARC specification, along with IEEE 1275 Open Firmware (OF) https://www.openfirmware.info/data/docs/of1275.pdf, were considered as a solution for 'how to boot Itanium' during the early days of the IBI/EFI specification. 1275 came up because the PowerPC port of NT booted via OF. EFI ended up looking more like ARC, see similarity between the ARC Firmware Function Vector and UEFI System Table, although OF does have some advantages, especially for security https://www.cs.cornell.edu/~kozen/Papers/acsac.pdf. 

Another interesting aspect of the ARC Alpha firmware was that the NT NDIS miniport drivers from NT were embedded in the firmware for purposes of pre-OS networking, such as network booting. Other than boot loaders like U-Boot which liberally leverages portions of device driver code, this OS and firmware code sharing helps solve one of the main challenges of boot firmware, namely having to create a firmware version of a device driver for the block, network, and console services in the pre-OS and another variant for the OS runtime. 

 |

 |

\/

Fast forward to the early 2000's. At that time there was a project called FlexGo    https://en.wikipedia.org/wiki/Microsoft_FlexGo which allowed for a metered, or subscription PC.  There was MS firmware integrated into the code morpher, or microcode-like firmware of the Transmeta device https://en.wikipedia.org/wiki/Transmeta https://www.extremetech.com/extreme/76602-amd-to-resell-transmetas-payasyougo-chip. For some of the standard PC's at the time, there was exploration of having the monitoring agent from MS as an additional handler in System Management Mode (SMM) of the BIOS

 |

 |

\/

In the early 2010's, the industry was moving from a TPM 1.2 to 2.0. One of the learning's from the 1.2 era was that the specification for the commands lent themselves to various interpretations. As such, the TPM 2.0 specification was written in 'literate code' where the C based implementation of the commands could be extracted. The latter C code has formed the underlying implementation   https://github.com/microsoft/ms-tpm-20-ref for all of the integrated and discrete 2.0 devices. This code was born of the 'firmware TPM' work described in the technical report https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2015-84.pdf. 

 |

 |

\/

In the 20-teens, there emerged from Microsoft Project Mu for BIOS https://microsoft.github.io/mu/. Although this is officially referred to as a downstream fork of EDKII on tianocore.org, there are many unique aspects, especially features like DFCI in https://github.com/microsoft/mu_plus.

A more recent example includes MS writing the SMM supervisor for AMD SecureCore PC https://www.microsoft.com/security/blog/2020/11/12/system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform/ variant mentioned during OSFC '20 'hallway chat.'

And for the broader industry MS wrote many SMM audit and checking tools in Mu to help prepare the OEM ecosystem for having their handlers running in the jailed context of the SecureCore PC SMm supervisor.

 |

 |

\/

In the future, MS hardware Pluton hardware and firmware https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton-processor-the-security-chip-designed-for-the-future-of-windows-pcs/ may be even more deeply integrated.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Beyond the long run of the MS examples above you can see a similar, albeit shorter in time, arc for Google, especially Google as an OSV with respect to ChromeOS. It begins with the Google Chromebooks leveraging coreboot + vboot  https://www.coreboot.org/ where Google employees are many of the upstream maintainers. 

 |

 |

\/

More recently, the Titan/OpenTitan  https://opentitan.org/ has emerged. This is a root of trust with the CPU based upon RISC-V and the operating system based upon the Tock OS https://github.com/google/tock-on-titan written in Rust. Interesting stuff.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And you cannot have firmware without hardware, of course. Google Titan-M and the OpenTitan are one example.

For Microsoft, MS already has its XBox360 https://en.wikipedia.org/wiki/Xbox_360_technical_specifications and XBox One https://en.wikipedia.org/wiki/Xbox_One, which were custom PowerPC "Watermoose" and AMD "Jaguar" based SOC's, respectively.

There are also always rumors in the air for MS, such as recent one on ARM https://arstechnica.com/gadgets/2020/12/microsoft-may-be-developing-its-own-in-house-arm-cpu-designs/ and earlier one on custom designs like E2 https://www.theregister.com/2018/06/18/microsoft_e2_edge_windows_10/.

For Google we already have ample public details on their Tensor Processing Unit (TPU) https://semiengineering.com/knowledge_centers/integrated-circuit/ic-types/processors/tensor-processing-unit-tpu/ and the above-listed Open Titan first party silicon, but these are not general purpose system on a chip (SOC). Of course even Google has the rumor mill swirling on occasion with stories like "Whitechapel" https://www.theverge.com/2020/4/14/21221062/google-processor-pixels-chromebooks-whitechapel-samsung-qualcomm, too.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So how does the OS impact the firmware? Well, since the firmware is closely tied to the overall platform and hardware design, OS 'requirements' documents http://download.microsoft.com/download/7/0/e/70e74967-b0fe-477a-974f-c1ed16ee31df/windows8-1-hardware-cert-requirements-system.pdf and https://source.android.com/compatibility/10/android-10-cdd can dictate some of these choices. And even for more open firmware implementations like Chromebooks you can see the coupling https://www.chromium.org/chromium-os/2014-firmware-summit.

Regarding a prediction for 2015

Given it is the final day of 2014, I thought that my final blog of 2014 would treat the year.next which commences in a few hours, maybe with another one of my infamous TL:DR-style postings? Specifically, I'd like to build upon missive from Tim Lewis at http://uefi.blogspot.com/2014/10/security-to-eclipse-user-features-as.html wherein he shared his belief that security concerns in the platform firmware will predominate as the top user story of 2015. Given the sampling below from 2014, he may be observing an unenviable trend line.

Regarding that trend, there have been talks at several venues in 2014, such as the Black Hat (BH) talks a few months ago https://www.blackhat.com/docs/us-14/materials/us-14-Kallenberg-Extreme-Privilege-Escalation-On-Windows8-UEFI-Systems.pdf. This talk had an associated CVE http://www.kb.cert.org/vuls/id/552286 and white paper https://www.mitre.org/sites/default/files/publications/14-2221-extreme-escalation.pdf.

In addition, just this week there were a couple of talks featured on UEFI at the Chaos Communications Conference (CCC), including https://www.youtube.com/watch?v=5BrdX7VdOr0 and the associated presentation https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf
by researchers from Bromium and Mitre, respectively.

The other CCC talk was on EFI and Thunderbolt https://www.youtube.com/watch?v=5BrdX7VdOr0. Glad to hear from the Matthew Garrett question to the presenter near the end of the talk that the option ROM vulnerability could have been mitigated if the Apple platforms implemented UEFI Secure Boot with option ROM verification (i.e., UEFI Driver Loading) enabled.

These security events and broad use of UEFI and edk II-based platforms definitely argue for the need to have additional industry coordination. This is a role that CERT has done admirably, but as Tim noted, they are now joined by the UEFI Security Response Team (USRT) http://www.uefi.org/security. This effort has been followed by a more code base-specific effort, too http://tianocore.sourceforge.net/wiki/Security. I am happy to be involved in both and although my CVSS-Fu isn't too evolved yet, I'm trying my best in writing technical advisories and doing the associated grading.

It is interesting that the references for both BH and CCC  https://www.youtube.com/watch?v=5BrdX7VdOr0 talks above cite the Intel Framework Specifications at www.intel.com and not the superseding UEFI Platform Initialization (PI) specifications http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. This might contribute to some of the ambiguity seen in the boot script implementations, for example, noted in the CCC talk, since the Intel Framework specifications are frozen after having been contributed to the UEFI Forum. Maybe posting a ZIP of the PI specs and a PDF of the Framework makes the latter more search-engine friendly?

For the CCC talk https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf, it was good to see that slide 53 mentions the work done with my Intel colleague

      [11] A Tour Beyond BIOS:
      Implementing S3 Resume with EDK2 –JiewenYao and Vincent Zimmer,
      October 2014

Jiewen and I designed features like the Lock Box protocol https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h to allow for protecting the boot script memory, via SMM or other container, back in 2009. But issues in seeing the protections deployed are compounded by the sheer difficulty in implementing S3 resume in platforms. Specifically, getting the functionality correct and having less-easily testable properties like securing the boot script has proven challenging. As a platform developer the last call you want to hear during product development is from the SQA team, saying "Everything works great, but our S3 resume testing fails once out of 10,000 times."

The above S3 document represents part of an effort to document some of the design intent on edk II source artifacts. We already have architectural intent documents such as http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf (including the companion talk https://www.youtube.com/watch?v=lZ505uz1TZ4).

Regarding other defenses, in the S3 talk Corey also mentioned the "SMI Transfer Monitor" (STM). Corey's co-presenter Rafal discusses the STM in more detail at http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf. This is also mentioned in CCC 2013 talk http://events.ccc.de/congress/2013/Fahrplan/system/attachments/2266/original/Gal_Diskin_-_Virtually_Impossible_-_30C3__release_version_.pdf by former Intel researcher Gal Diskin.on slide 13. Chapter 13 of Grawrock's 2nd edition of Safe Computing http://www.amazon.com/Dynamics-Trusted-Platform-Building-Approach/dp/1934053171 also describes this feature. The gist of the STM is that it represents a usage of the peer-monitor capability in IA32, a hardware feature defined in chapter 34.15 of the Intel Software Development Manual (SDM) https://www-ssl.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html. There is a nice peer monitor overview at http://virtualizationtechnologyvt.blogspot.com/2011/07/vmx-and-smm-dual-monitor-mode.html. The use of the peer monitor, which is essentially virtualization controls in System Management Mode (SMM), allows for de-privileging today's ring 0 SMM code, such as that built responsive to the infrastructure in volume 4 of the PI 1.3 specification http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. So when Corey said "where is the STM specification?", he was referring to the firmware convention for loading the STM, interaction with Intel TXT, and how to expose resource lists for which the guest SMM code can access. This class of firmware interaction is the "STM specification" and it is built upon the hardware specifications of the peer monitor virtualization capability treated in the SDM. The SDM is the bible for software-visible parts of IA32, i.e., the 'architecture.' The SDM hasn't changed over the last decade plus, whereas the STM specification has, er, evolved. 

I have spent quite a bit of time on SMM over the last decade plus, from having defined the Framework SMM CIS http://www.intel.com/content/www/us/en/processors/itanium/efi-smm-cis-v09.html infrastructure http://www.google.com/patents/US6848046, from which the present PI 1.3 SMM design has been derived, to collaborating on peer monitor and STM work. I'm a big fan of isolation technologies and trusted computing, but I'll have to pause here for this 2014 entry on this topic. If I were a smarter guy I would follow in the foot-steps of Fermat's Last Theorem and claim to have the final proof of solving the SMM security issues but excuse myself for today by noting that the answer is "too large to fit in the margin" of this blog http://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem.

Just as a document cannot replace well commented codes, having more executable methods for assurance are always preferred. These include efforts such as the CHIPSEC work https://github.com/chipsec/chipsec which I also describe in http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf and https://www.youtube.com/watch?v=aV1DSF4cwGw. These tests are run after boot and provide an a posteriori view of the platform.

More recent technology includes having security testability in-situ with the platform, versus a CHIPSEC style post-boot test, and reporting the results. This type of test and reporting capability was mentioned in 2013 at http://www.uefi.org/sites/default/files/resources/UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf and now has a public specification realization at  http://msdn.microsoft.com/en-us/library/windows/hardware/dn879006.aspx (HSTI) This work bridges the semantic gap historically faced by platform builders wherein the various system requirements in a Windows Hardware Certification document, such as http://download.microsoft.com/download/7/0/E/70E74967-B0FE-477A-974F-C1ED16EE31DF/windows8-1-hardware-cert-requirements-system.pdf, can now have a companion reporting channel. Examples include injunctions in System.Fundamentals.Firmware.UEFILegacyFallback, such as

"An OEM may not ship a 64 bit system which defaults to legacy BIOS or loads legacy option ROMs if that system ships with a UEFI-compatible OS. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded."

These Compatibility Support Module (CSM) behaviors are something that only the platform implementation can deduce and are difficult to detect via a later test, although heuristics like scanning 0xC0000p through 0x100000p in the address space 'could' be done.

The HSTI interface builds upon the Adapter Interface Protocol (AIP) class of structure defined in the UEFI 2.4 specification http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf. Since AIP producers are boot service only, a pre-OS agent needs to query the HSTI interface in order to cull the settings and convey the results into the operating system run time, if needed, in a vendor-specific fashion.

Related work to HSTI that goes beyond mapping to Windows requirements include the ability to report BIOS Integrity Attributes, as described in http://csrc.nist.gov/publications/drafts/800-155/draft-SP800-155_Dec2011.pdf in 3.2.1.1. And in order to surface this information, we defined in http://www.trustedcomputinggroup.org/files/static_page_files/D4268663-1A4B-B294-D05DE87EE90558B6/TCG_EFI_Platform_1_22_Final_-v15.pdf the following:

    typedef struct {

       UINT32 VendorId;

       EFI_GUID ReferenceManifestGuid;

    } TCG_Sp800-155-PlatformId_EventStruct

This structure can be used to reference an off-machine Reference Manifest (RM). The idea is that the GUID in the structure above would be specific to a vendor, model, and firmware instance in a XML-based manifest document on the platform suppliers website. The schemas are defined in http://www.trustedcomputinggroup.org/files/resource_files/73638609-1A4B-B294-D0902CC2A13C8697/Reference_Manifest_Schema_Specification_v2.0.r5.pdf, so now it's a set of work items for the industry to map the RM's to platform attributes, such as mentioned in 155.

Who knows, at some point maybe these reporting and testing efforts will all align?

Well, if you have gotten this far, the 'Didn't Read" portion of "Too Long, Didn't Read" (TL;DR) hasn't been the case for you. I'm not sure whether to reward you for your stoicism or not for wading through this entry.

To summarize, 2014 has shows a spate of security-related activities, both by the attackers (BH, CCC) and the defenders (USRT). The firmware-producing and consuming community is acutely aware of assurance concerns and new testing methodologies have been deployed in '14 and are coming in '15, too, including HSTI. I don't necessarily subscribe to the 'Spy versus Spy' aspect of security, or fall into existential angst that the "Defenders Dilemma" is not solvable. Instead, I see many parties passionate about having robust, usable systems and collaboration on art to achieve those goals. Open source, open documentation, open specifications, open platforms,.... All help in the cause.

And if you're still working these last hours of today, pause and have a coffee.

Also, enjoy a happy and safe new year.

Cheers,

V.Z.兹梅

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.   

Windows 8 Hardware Certification Requirements

Check out the document windows8-hardware-cert-requirements-system.pdf, which can be downloaded from http://msdn.microsoft.com/library/windows/hardware/hh748188. The platform builders often refer to these as 'logo requirements.'

The document includes details on UEFI network boot on IPV4 and IPV6 under System.Fundamentals.PXE.PXEBoot, along with more information on implementing UEFI secure boot under System.Fundamentals.Firmware.UEFISecureBoot and measured boot under System.Fundamentals.TrustedPlatformModule.TPMRequirements.

The matter includes guidance that complements the UEFI2.3.1a specification, IETF RFC's (such as RFC5970 on IPV6 network boot), and other industry standards, for purposes of describing how to build a UEFI platform for this class of operating system.

Random notes

After so many years, it is good to see so much activity around UEFI Secure Boot and the proposed usage of this capability in upcoming operating systems. The UEFI Forum www.uefi.org has been working on refining this capability since the publication of the UEFI 2.0 specification in 2006, culminating in its present form in the UEFI 2.3.1a specification published this year.

I introduced the concept of a UEFI-based Root of Trust for Verification / Enforcement (RTV/RTE) in the 2007 paper Platform Trust Beyond BIOS Using the Unified Extensible Firmware Interface http://dblp.uni-trier.de/rec/bibtex/conf/csreaSAM/Zimmer07. As I concluded in that paper:

This paper has shown that the future of extensible platform firmware beyond BIOS holds many perils and opportunities. The perils include the new ability to have extensible code loading in the pre-operating system regime, but the opportunities include the use of measured and secure boot to harden the platform and authorize code loading. And in a world of ever-more-secure operating systems, the pre-OS may become a more interesting target for the Blackhat's of the world. As such, these UEFI protections are even more important to implement.

The paper also describes how the UEFI RTV complements a Trusted Computing Group Trusted Platform Module (TPM) Root of Trust for Storage/Recording (RTS/RTR) and a UEFI based Root of Trust for Measurement (RTM) to work in tandem with the TPM. Finally, the paper describes using formal integrity models like Clark-Wilson to decompose a system and the use of UEFI Capsule updates to have a cryptographically-assured update of the underlying UEFI Platform Initialization (PI)-based UEFI features.

For more recent information on a UEFI RTM, check out the IBM/Intel paper http://download.intel.com/technology/efi/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf.

http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf

In addition to that material from 2007 and 2009, article 5 of the November Intel Technology Journal describes the UEFI Secure and Measured Boot scenario in light of the UEFI 2.3.1a specification

http://www.intel.com/content/www/us/en/research/intel-technology-journal/2011-volume-15-issue-01-intel-technology-journal.html.

Other interesting discussions of the Measured and Secure boot interplay can be found in http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T. Matt Garrett also notes "Secure boot is a valuable feature. It does neatly deal with the growing threat of pre-OS malware" http://mjg59.dreamwidth.org/6503.html.