27 or Anniversary.Next^12, AI, Runtime

Anniversary

True to form, today is my work anniversary. I started Intel on February 24, 1997 This post also builds on my last posting in this vein http://vzimmer.blogspot.com/2023/02/26-or-anniversarynext11-and-wisdom-of.html. At this point I have spent more than half of my life on this planet at this single company.  

Since the last posting I've been back to the office daily, sometimes visiting the Crossroads for lunch, where I had my first sighting of a Cyber Truck.

I'd often work through lunch and eat from the local self-serve facilities but the pickings have been slim. So slim that even a 2-month-expired tuna sandwich was eaten by someone.

 I last took a sabbatical in 2011 where I smashed up my arm on the 2nd day and ended up w/ 2 surgeries. I still recall the one-handed typing away at the ITJ articles https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf that appeared later that year.  Typically sabbaticals expire but with the strangeness of COVID there were extensions that turned into a revised evergreen policy where sabbaticals no longer expire.  Regrettably, though, one stops accruing time after reaching 16 years. Looks like I need to pull the trigger on at least one month in the upcoming year, viz.,

 

Beyond cyber trucks, old sandwiches, and sabbaticals, the last year has seen a lot of energy around AI. Even the University of Washington lecture series has been dominated by this topic. An interesting talk from Meta was included in https://www.ece.uw.edu/news-events/lytle-lecture-series/ with slides https://www.ece.uw.edu/wp-content/uploads/2024/01/lecun-20240124-uw-lyttle.pdf and a recording https://www.youtube.com/watch?v=d_bdU3LsLzE. You can catch me at 6:36 on LHS of the screen

It's always interesting to be there in person. One comment that intrigued me was a comment from Yann LeCun about the Metaverse build out and GPU procurement. I cannot recall if it was on-tape or off-the-record so I've avoid going further than that.

This talk was at the Lyceum HUB but all of the other talks were across the street.

Another interesting talk https://www.cs.washington.edu/events/colloquia/details?id=3310 was from Fei-Fei Li of Stanford and ImageNet https://ieeexplore.ieee.org/document/5206848 fame.

This was near the comp sci building

LeCun's and Li's talks were like Taylor-Swift-concert-crowds but for techies. Nice to see these thought leaders share their insights and experience in person. 

Google Waymo was also in the mix with a talk https://tcat.cs.washington.edu/events/taskar-center-memorial-distinguished-lecture/ on the challenges of autonomous driving and AI https://www.youtube.com/watch?v=pK5ChzMsfE0

So let's pivot from AI lectures to a topic closer to home, namely firmware runtime. I chose this topic since one of the most popular posts is on this blog series was UEFI variable runtime http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html. I suspect this stems from the fact that most folks have interactions during life of platform at runtime. In our quest for 0-second boot this makes even more sense. 

Regarding how firmware is exposed to the operating system, and thus ultimately the user, at runtime, there are various modalities. 

These include:

• Static info tables
• Advanced Configuration and Power Interface (ACPI)
• Flattened Device Tree (FDT)
• Interpreter bytecode
• ACPI AML interpreter
• UEFI EBC sandbox
• x86 VDM for video int10h calls
• Native code runtime
• UEFI runtime
• Power9 OPAL
• Platform Runtime Mechanism (PRM)
• Opaque host modes - synchronous and asynchronous activations

• SMI(SMM)- x64
• SMC(TrustZone)- ARM
• Trap(Machine Mode) - RISC-V

These are all for the host firmware, or firmware running on the main application processor/core.

There is also device firmware running in the SOC.

In addition, at the platform level, the host can signal 'non-host' such as an Embedded Controller (EC) on client and Baseboard Management Controller (BMC) on server.

Below shows some of the latter 

 

    

 from https://link.springer.com/book/10.1007/978-1-4842-7939-7.

A lot of the flows are blended. For example, some of the descriptions of ACPI and SMI for errors described in https://cdrdv2.intel.com/v1/dl/getContent/671067 but the paper is light on ACPI.

Regrettably the collection at https://www.amazon.com/stores/Vincent-Zimmer/author/B002I6IW4A is pretty spare on ACPI, too, although https://link.springer.com/book/10.1007/978-1-4842-7974-8 covers construction and design in the case studies.

A curation of ACPI material can be found in the following:

Public documents on ACPI

2022

Intro to ACPI from ACPI spec

https://uefi.org/specs/ACPI/6.5/01_Introduction.html

2019 

ACPI tutorial

https://acpica.org/sites/acpica/files/asl_tutorial_v20190625.pdf 

2013

ACPI and UEFI

https://cdrdv2.intel.com/v1/dl/getContent/671067 

APEI and UEFI

ACPI overview https://www.intel.com/content/dam/www/public/us/en/documents/research/2009-vol13-iss-1-intel-technology-journal.pdf

2009

ACPI and SMM

https://link.springer.com/article/10.1007/s11416-009-0138-0 

2006

ACPI attacks

https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Heasman.pdf 

2004

ACPI HOWTO

https://tldp.org/HOWTO/pdf/ACPI-HOWTO.pdf

2003

IA64 book, including UEFI and ACPI chapter

https://www.amazon.com/Itanium-Architecture-Programmers-Understanding-Processors/dp/0131013726

 

2001

ACPI Book

https://dl.acm.org/doi/book/10.5555/940719 

1997 

ACPI implementation guide

https://www.baldwin.cx/~phoenix/reference/docs/acpi_impguide.pdf 

1996 for first spec - full history in 
https://en.wikipedia.org/wiki/ACPI 

 

A colleague suggested that I should have spent more time in the books writing about ACPI since he spends his time debugging issues on Windows and can quote many instances of poor or misunderstood ACPI constructions. I also chronicled in the past my exchange https://vzimmer.blogspot.com/2018/ with the Linux kernel leadership on the topic. 

A lot of people grouse about UEFI and ACPI when in fact it isn't the standard they are critiquing but instead the implementation.  Namely, it's often a confusion between interface and implementation. 

For example, on topics like the firmware support package (FSP), I hear complaints. I often offer the following dichotomy there:

    Consumer (caller)

    Interface (specification)

    Producer (implementation)

You can find examples of using FSP (consumer/caller) with EDKII 

https://www.intel.com/content/www/us/en/content-details/671038/a-tour-beyond-bios-using-the-intel-firmware-support-package-2-0-with-edk-ii.html or coreboot https://link.springer.com/chapter/10.1007/978-1-4842-0070-4_4. The interface itself is defined at https://github.com/intel/fsp/wiki, and one way of building (producer/implementation)

https://cdrdv2-public.intel.com/671296/a-tour-beyond-bios-creating-the-intel-firmware-support-package-with-the-efi-developer-kit-ii-fsp2-0.pdf.  As such, there are 3 layers.

Sometimes people grouse about FSP when in fact it's the implementation, not the API. And it has been a long run on FSP. The Intel IOTG folks kicked it off in 2010 and then Jiming and I conspired to have a working group that I've lead/co-lead since 2014 on the same with various other co-leads and collaborators along the way. Some of the outputs of that collaboration that record Maurice, Ravi and Jiming details can be found in the '15 book https://link.springer.com/book/10.1007/978-1-4842-0070-4, too. Maurice is now doing great things in fw at MS and Jiming at AMZN, resp., AFAIK. One of my key contributions in those 2013/2014 days was teasing out the FSP spec which was originally an amalgam of silicon details and API's into a couplet of docs, namely the main interface spec, the FSP EAS, and the respective SOC integration guides, such as can be found today in https://www.intel.com/fsp and in https://www.github.com/intel/FSP, respectively. This allowed for creating class drivers for FSP in the various platform code (e.g., coreboot and EDKII at the time) and abstracting SOC specifics. And I should forget how the decade+ of cross-group collaboration allowed for scaling FSP's from embedded to both mainstream client and servers, as demonstrated by the rich postings on Github. It's not a perfect split between EAS and integration guide, though, but as we've struggled with the 2001 Intel Framework API's and 2006+ UEFI PI spec interfaces, building that 'firmware socket' set of abstractions is tough given the variability of silicon and products over time.

Same with UEFI.  The interface is at https://uefi.org/specifications. Two implementations can be found at https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Dxe and https://github.com/u-boot/u-boot/tree/master/lib/efi, respectively. Most folks complain about the EDKII implementation when they invoke 'UEFI is broken', I feel. This reminds me of the sentiment that some person with the handle of 'the_panopticon' mentioned in https://news.ycombinator.com/item?id=39481434. 

So back to ACPI. The evolution of ACPI in the did-90's predates late 90's EFI. EFI started as a sample and then the Tiano project with EDK and then EDKII subsumed Framework/PI and EFI/UEFI but not the ACPI specification. As such, no modularization of ACPI from the beginning because of Conway's Law (i.e., the folks who owned the UEFI spec and its reference implementation didn't own the ACPI spec for the first nearly 2 decades). In fact a lot of the ACPI table construction on the Intel platforms was derived was the DaVinci/Kittyhawk clean-room C BIOS that pre-dated Tiano in that hotbed of late 90's BIOS innovation called DuPont, WA Intel site. This model of static tables differs from the ARM ecosystem which does dynamic table generation since they started much later on the journey and had a single-team/Linaro view of entering standards-based firmware.

An advantage of dynamic table generation is flexibility but a downside is that it is harder to do attestation since the table fields are not known at build time. Even build time calculations, though, are aggravated by patching. So in practice it is not really done, just like a lot of configuration and PCR[1] content not really be reconstructed for some attestation / verifier flows.

Thinking about these taxonomies of firmware, from SAL+BIOS to Kittyhawk to ACSFL to EDK to EDKII to slim bootloader to coreboot to.... I realize that I might have the dubious honor of having worked on the broadest variety of host firmware at my employer.

Time marches on. In mentioning DaVinci/Kittyhawk workstation BIOS, I realize that my colleagues on that late 90's adventure have largely left the company, from retirement to downsizing to becoming execs at other tech shops (e.g., MS). Similar to the thinning of the crowd of others, such as even my 2015 colleagues from https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk who have all left for startups (e.g., Eclypsium) or retirement or other big tech (e.g., Amazon). Well, given those statistics and chaos in tech, this might by be my last Next^* blog. Even if it is, though, I have enjoyed the run and people I've met along the way. Hopefully I have re-payed my employer's and colleagues trust with sufficient contributions these last 27 years.  

Cheers

Deprecation and introduction of interfaces

Specifications may appear to be static codifications set in stone, but they are often evolutionary species. One of the challenges in evolving a specification includes when, if ever, to deprecate content in lieu of new additions. Sometimes technology may fall out of use or be deemed by the market not to be the most viable. Often, though, this class of information is not elided from specifications unless they are hard scientific reasons, like elision of MD5 or SHA1 from specifications 

because of pre-image attacks https://en.wikipedia.org/wiki/Preimage_attack. I recall one person telling me that about 40% of the Wifi specification was relevant; the key was knowing 'which' 40% merited attention.

This blog will talk about a few specifications, such as the UEFI, PI and Intel SDM, that weigh in at several thousands of pages. To be with the UEFI and PI specification, one area that has potential for deprecation is Itanium support. The EDKII upstream has already removed Itanium related code from the various packages. There are vestiges of Itanium in chapter 2 of the UEFI Specification https://uefi.org/specs/UEFI/2.10/02_Overview.html#intelitanium-based-platforms for the calling conventions, though. Similarly, support for the Itanium reset paths https://uefi.org/specs/PI/1.8/V4_MCA_INIT_PMI_Protocol.html# and extended SAL https://uefi.org/specs/PI/1.8/V4_Sal.html services can be found in the PI specification. The latter of which was the EDKII adaptation of calling the Itanium System Abstraction Layer (SAL) (SAL) https://redirect.cs.umbc.edu/portal/help/architecture/24535901.pdf interfaces from a UEFI environment. 

As a quick background, Itanium had a platform scoped SAL and processor scoped Processor Abstraction Layer (PAL) set of firmware layers designed to provide both boot and runtime services. The RISC-V Supervisor Binary Interface (SBI) https://github.com/riscv-non-isa/riscv-sbi-doc is sort of an amalgam of SAL and PAL since it provides both core, SOC and (potential) platform capabilities. SAL is interesting in that unlike UEFI, that goes into a virtual-only calling mode after SetVirtualAddressMap(), the SAL calls could be called in either physical or virtual mode throughout the life of the platform. This posed some challenges for writing UEFI code since position independent code (PIC) options for C compilers haven't been universally supported across all of the EDK toolchains, especially in the early days with Visual Studio, or for IA32 with its inability to read the instruction pointer address as possible in other architectures. For assembly-language Itanium code it was pretty simple to write PIC code. So the Extended SAL (ESAL) of the PI spec and EDKII provided a way to have non-fixed up and fixed up C code that would use a common data area. 

In addition to the SAL support, another fascinating aspect of Itanium was the support for floating point exceptions in the Floating-Point Software Assist (FPSWA) https://redirect.cs.umbc.edu/portal/help/architecture/24541501.pdf driver, as described in https://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143 

This driver was loaded from the EFI System Partition during boot and would provide runtime support for floating point exceptions. Regrettably soft-loading critical flows from disk like the FPSWA have not been pervasive, even in the face of relatively expensive $/byte of semiconductor NOR SPI flash. This stems from the supply chain challenge where the motherboard and fixed disk media may be provisioned, secured, and recovered by alternate parts of the ecosystem, namely OEM/ODM for the board versus OEM/ODM/integrator/VAR/IT for the disk and its bootloader and OS images, respectively.  

Another area that is an interesting artifact from the past is the BIOS interface in the Intel Software Developer Manual https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf. This interface is an Int15h API to manage microcode patches.

Starting in the early 1980s, the PC/AT BIOS exposed services through 16-bit 'int' calls or software traps, which the most famous being Int13h for disk access, Int 10h for video, etc. These API's all have correlatives in UEFI, with Int13h having the equivalent in EFI_BLOCK_IO_PROTOCOL, for example. The Intel Framework Compatibility Support Model (CSM) specification https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-compatibility-support-module-specification-v098.pdf provided a bridge from EFI into BIOS calls in the early days where there were few EFI native drivers, for example. But the CSM support was not introduced into the UEFI PI specification since the idea with PI commencing in 2006 would have UEFI-spec-defined APIs. In fact, Intel declared the PC/AT BIOS interfaces to be end-of-life in 2020 https://www.phoronix.com/news/Intel-Legacy-BIOS-EOL-2020 

and http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf.

That's where the Int15h API mentioned above is interesting. It can either go away as its the only BIOS API in the SDM, or it could be complemented by/replaced with a UEFI equivalent. To that end, the https://raw.githubusercontent.com/tianocore-docs/Docs/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf design reads on this capability 

The mapping of the UEFI interfaces to the Int15h included

with the specific capsule itself having the following layout

The generic capsule overview flow is described in the UEFI specification https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#update-capsule 

and other write-ups https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure and https://archive.fosdem.org/2020/schedule/event/firmware_culisfu/attachments/slides/3709/export/events/attachments/firmware_culisfu/slides/3709/FOSDEM_2020_Intel_Capsule_Update.pdf. As the code-base has been re-arranged in the open, the most recent location to find the FMP DXE Microcode Capsule support is https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Intel/IntelSiliconPkg/Feature/Capsule and of course https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg. 

This builds upon the generic FMP 

and capsule update flow 

widely deployed today. Maybe avoiding putting something 'post-Int15h' in the SDM is a wise move, though, considering the plurality of interfaces for firmware updates, from https://slimbootloader.github.io/security/firmware-update.html to https://uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf to https://uefi.org/sites/default/files/resources/PRM_Platform_Runtime_Mechanism_1_1_release_candidate.pdf to https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf to.... It's a veritable embarrassment of riches.

24 or Anniversary.Next^9 and 128 bits

I was pretty late last year in posting http://vzimmer.blogspot.com/2020/05/recovery-tech-talks-23-or.html in order to maintain this ritual. It's OK to be late but I cannot really make up by being early in 2021 since there is no guarantee that will be employed on the anniversary date, of course.

As such, here's the anniversary year 24 edition. It features rolling into upcoming year, which may culminate in the '25' edition of this posting. Either way, I hope to have a "Anniversary^10 and 25 years" post. 

I have definitely learned many things in the past past couple of decades, including how to take criticism, whether code & spec review or paper and patent feedback. It's tough sometimes but feedback provides one of the key ways to grow. There is always room to learn, too. Thanks to Hot, via Rob, for recent reference https://www.amazon.com/12-Essential-Skills-Software-Architects/dp/0321717295. I especially like the quote "Architecture is about business. It focuses on representing, communicating, and building on the key points of a technology or even a nontechnology solution that has beneficial impact to the business in some way."

Beyond keeping up with the times via feedback and book learning, I sometimes like to ponder the basics in this fast moving technology world. The basics include maths, science, and for computers. Vintage computer topics include the EDVAC http://web.mit.edu/STS.035/www/PDFs/edvac.pdf. This led me to think about pointer sizes. I started my career programming 8-bit 8051's with its infamous 16-bit 'DPTR' and Harvard Architecture. Then I moved to the 16-bit 186, 16-bit V20 286, 32-bit 386EX & 486 from Intel, 29k from AMD, and Pentium Pro. Then I segued to 64-bit with Itanium here at Intel where I on-boarded to lead some of the boot firmware development, and then EM64T/x64/x86_64 to provide the first EFI boot. But what about 128-bit https://en.wikipedia.org/wiki/128-bit_computing ?

My journey into the past led to some questions about the integer and pointer size of the Unisys 1100 (72 bit ptr, 576 bit integer?) mentioned in https://www2.cs.arizona.edu/~mccann/cstyle.html. GCC has a data type https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html. Maybe a future ILP128/LP128 to scale beyond today's ILP64/LP64 http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm?

The C style document mentions DEC, which reminded me of some of the innovation they, as chronicled at http://simh.trailing-edge.com/dsarchive.html. During my undergraduate days at Cornell Digital was to place to go for systems work, and at Intel in the late 90's many ex-DEC engineers led the workstation work (e.g., Dileep B.).

Intel has been evolving physical addresses, too 5-level paging on Intel x86 https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf. 

Most interesting regarding deployed systems is the AS/400 single level store w/ 64 or 128 bit pointers. I ran into this while reading 'inside the as/400' https://www.amazon.com/Inside-AS-400-Frank-Soltis/dp/1882419669 book, Some CPU's have 96-bit physical addresses with the size hidden by the SLIC - system level interface code. IBM also has 80 bit VA and 64-bit PA on IBM https://www.ibm.com/support/knowledgecenter/ssw_aix_71/generalprogramming/address_space.html.

These pointer size ruminations led me to think of the more recent paper on the subject, namely the RISC-V paper and the architecture's support of 128 bit addressing. From https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf:

"At the historic growth rate of the memory capacity of TOP500 champions, about 70% per year, a 64-bit address space would be exhausted in about two decades. To the extent that global addressability of such systems is desired, we contend that flat addressability is the best approach; RV128I provides a promising solution."

Andrew W. mentioned that the 128 bit binding was considering something of a joke when he described it at the 2016 coreboot conference https://www.youtube.com/watch?v=f0ykeMmqglI&feature=youtu.be (12:25). 

In the intervening 5 years, though, the 'joke' takes on some more gravity with the comment about needing to work on the base spec for 128 bits (minute 3:58 of https://www.youtube.com/watch?utm_content=152341011&utm_medium=social&utm_source=linkedin&hss_channel=lcp-7579420&v=lg33UqZ_en0&feature=youtu.be)

There are no known soft or hard core IP implementations of RV128 I could find on the web, although the https://bellard.org/tinyemu/ RISC-V system emulator supports the RV128IMAFDQC base ISA (user level ISA version 2.2, privileged architecture version 1.10).

But extra bits do not have to be used for addressing. There are potential security usages https://riscv.org/wp-content/uploads/2017/12/Tue1554-xbgas-JLEIDEL.pdf, or more fringe ideas like mapping ipv6 address to memory locations https://patents.google.com/patent/US8266238. 

Again, these are 128 bit pointers, not 128 bit data types. A lot of the SIMD/Vector ISA extensions have broken the 128 bit data type long ago. This is a "sizeof (pointer_in_128_bit_ISA) == 128" thing.

Speaking of RISC-V, I was interested to see the progress in the EDK2 RISC-V port https://fosdem.org/2021/schedule/event/firmware_uor/. Some of this work was inspired after my posting http://vzimmer.blogspot.com/2014/11/porting-to-new-architecture.html which led to position papers https://github.com/vincentjzimmer/Documents/blob/master/risc-v-uefi-talk-001.pdf https://github.com/vincentjzimmer/Documents/blob/master/risc-v-uefi-talk-004.pdf and standards/open source work.

I asked the Fosdem developer if he had considered porting the UEFI Platform Initialization (PI) Management Mode (MM) to the System Binary Interface (SBI) https://github.com/riscv/opensbi machine mode. This is work we did https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf 

in order to allow decoupling the SMM from the host firmware environment https://github.com/tianocore/edk2/tree/master/StandaloneMmPkg was originally done for loading SMM from the Firmware Support Package (FSP) with a prototype at https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64_smm. The work was then picked up by the ARM community who need to load the TrustZone-variant of MM during early boot (e.g., SEC or PEI). The architecture neutrality of MM software model could thus be applied to RISC-V, just as the original "SMM Framework" mentioned "xMI's" to cover by the x86 system management interrupt (SMI) on x86 and the platform management interrupt (PMI) on Itanium. 

Today, though, SBI is really a set of call interfaces similar to the DEC Alpha PALcode or Itanium SAL/PAL Code.  I mention both PAL and SAL from Itanium since some of the SBI are SOC-specific (e.g., ISA emulation) whereas others may map to the platform (e.g., debug console). The runtime of host firmware is always challenging, whether it's traditional SMM on x64 and UEFI runtime and the interpreted ACPI, or the IBM Opal runtime or device tree. As always the execution of runtime should be minimized in order to avoid impacting host OS / hypervisor resource management, with 'minion cores', Embedded Controllers, BMC's, and other SOC microcontrollers providing independent execution regimes.

Different boot and testing schemes

In the news, interesting to see the details of the M1-based Apple devices. As a firmware person, I was curious about how the machines boot. 

They mention the omission of bootcamp https://support.apple.com/boot-camp https://discussions.apple.com/thread/252021896 or the support of 3rd party OS's https://www.zdnet.com/article/top-apple-exec-native-windows-10-on-m1-macs-is-a-choice-microsoft-needs-to-make/.

Does that mean the boot paradigm of the Macs has changed from UEFI http://refit.sourceforge.net/info/boot_process.html? Apple was never fully UEFI compliant and often eschewed more complex capabilities like SMM-protected Authenticated Variables and other rich runtime services, although they did support ACPI.

The answer was formally revealed in the video https://developer.apple.com/videos/play/wwdc2020/10686 at 16:22

which mentions that the boot process is leveraged from the iPhone/iPad, namely iBoot https://en.wikipedia.org/wiki/IBoot. 

The native iBoot launch was confirmed by Apple UEFI engineer https://twitter.com/NikolajSchlej/status/1275951574200709120, along with using device tree https://elinux.org/Device_Tree_What_It_Is in lieu of ACPI https://twitter.com/NikolajSchlej/status/1275951827754774528. Flattened Device Tree predates ACPI and was part of how the original PowerPC MACs booted, with OpenFirmware Forth-based FCode and FDT as the equivalent of UEFI/ACPI for the programmatic and declarative runtime tables interfaces, respectively. Open Firmware was circa 1994 https://en.wikipedia.org/wiki/Open_Firmware whereas ACPI was 1996 https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#:~:text=First%20released%20in%20December%201996,Play%20BIOS%20(PnP)%20Specification.&text=ACPI%20defines%20a%20hardware%20abstraction,UEFI)%20and%20the%20operating%20systems., respectively. EFI, the precursor the UEFI, is the youngest of all three, dating its earliest appearance in 1998 https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface.

As Apple showed in slide 14, the T2-based Mac's already support the bridgeOS kernel going from iBoot to UEFI. This sort of layering of UEFI implementations on top of a non-PI based platform code is pretty common, with the https://github.com/tianocore/edk2/tree/master/UefiPayloadPkg providing an EDK2-based implementation of UEFI for coreboot https://doc.coreboot.org/ and slim bootloader https://slimbootloader.github.io/index.html. We discussed this in figure 6-17 of https://link.springer.com/chapter/10.1007/978-1-4842-0070-4_6 and we are trying to generalize the use of payloads in https://github.com/universalpayload. We compare a T2-based secure boot chain to other implementations in chapter 4 of https://www.amazon.com/Building-Secure-Firmware-Armoring-Foundation/dp/1484261054, too.

I suspect the disk layout is still based upon the GUIDed Partition Table (GPT), which was an invention of EFI. You can support GPT even without performing a non-UEFI OS boot, as showed by Chromebooks https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format, for example. To support a non-UEFI OS you simple can omit the EFI System Partition (ESP) and have your boot loader load a kernel from some arbitrary GUID-defined partition type.

We also show how the concept of a phase-based boot and clean interfaces to payloads enables more radical firmware stacks, such as slide 24 of https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf. 

 

Another interesting example of stacking a Rust-based UEFI implementation on an alternate platform initialization layer can be found in https://github.com/retrage/rust-hypervisor-firmware/tree/coreboot-support, too, that I saw on the open source firmware's oreboot slack channel. 

Speaking of another A-prefixed company that's not Apple, Amazon has been doing some pretty interesting things in firmware. Former Intel colleague Mark Tuttle's work in mentioned in the write-up https://www.freertos.org/2020/02/ensuring-the-memory-safety-of-freertos-part-1.html about using the C Bounded Model Checker (CBMC) https://www.cprover.org/cbmc/ to ensure memory safety of FreeRTOS. This is a nice balance of providing better assurance with an existing type-weak language like C versus the forklift upgrade to something like Rust. We discuss CBMC a bit in chapter 21 of https://www.amazon.com/Building-Secure-Firmware-Armoring-Foundation/dp/1484261054, including an example of usage in listing 21-2. 

This work in the rebar-embossed book is nothing like the fully operationalized example of the real-time OS listed above, though. Beyond this specific work, I appreciate how Amazon endeavors to make formal methods more developer friendly, as described in the work by Nathan, Mark, and their colleagues in https://assets.amazon.science/d0/de/cbec0b4547e3ae7ff077f8aa978f/code-level-model-checking-in-thesoftware-development-workflow.pdf. This type of analysis is much more relevant to my day-job than the former treatise on FM they wrote regarding TLA https://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods/fulltext, although some of Hillel Wayne's https://www.hillelwayne.com/post/why-dont-people-use-formal-methods/ work may help build a bridge for me. More examples of the good stuff published by their engineers/'builders' that I also referenced in my last blog posting.

And formal verification of system software is popping up in other places, such as the mention "Formal verification of the code running at EL2" in https://linuxplumbersconf.org/event/7/contributions/780/attachments/514/925/LPC2020_-_Protected_KVM_.pdf. I haven't dug into this too much, but I wonder if it is aligned with Google Project Oak, including the Hafnium hypervisor https://hafnium.googlesource.com/hafnium/+/HEAD/docs/Architecture.md and its Coq based verification https://github.com/project-oak/hafnium-verification/tree/hfo2/coq-verification? Or some other KVM-focused verification? 

As a parting note, I'd like to thank the work of Tim Lewis https://uefi.blogspot.com/ as the technical reviewer of https://link.springer.com/book/10.1007/978-1-4842-6106-4 and Leendert Van Doorn https://www.paramecium.org:4443/~leendert/ for writing the preface. I have appreciated the opportunity to work with these two technical leaders in various roles since the 2000's.

Open platforms and 21 or Anniversary.Next^6

This covers my 6th blog aligned with my work anniversary, a successor to http://vzimmer.blogspot.com/2017/02/this-one-is-for-20-or-anniversarynext5.html. I always mean to post this on the anniversary day, but I'm a bit laggard this year. Luckily this is a personal blog with random musings, so I don't have to worry about conformance to an SLA or other criteria... This anniversary year marks crossing the 21 year marker. As a multiple of 7, we have both a lucky number and also a milestone for sabbatical eligibility.

The journey has taken many twists and turns, commencing in 1997 with joining Intel to work on Merced https://en.wikipedia.org/wiki/Itanium boot firmware for server platforms. Merced was Intel's first 64-bit Itanium CPU. I am awed by scope of firmware changes, from that era of bringing up a new CPU, leading to events like this week where an open source EDKII based server firmware is announced at the Open Compute Project (OCP) Conference https://youtu.be/Dh6N7Pj1CLs and https://www.youtube.com/watch?v=4a1QHQ76it8.

For the latter, the system stack roughly follows the figure shared with the OCP Open System Firmware (OSF) effort  http://files.opencompute.org/oc/public.php?service=files&t=1ab7018c4aac16910255681b2eff469f&download.  

The server provides a minimal viable product design based upon the Min-Platform that we introduced with client in https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform. The specific server platform is Mt. Olympus https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus described in http://www.opencompute.org/wiki/Server/ProjectOlympus.

Some of the design rationale for the minimum platform design approach can be found in https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II%20-%20V2.pdf which has been updated to cover the server port.

Here are a couple of salient pages from this week's OCP deep-dive session on this topic https://2018ocpussummit.sched.com/event/DJ8H/firmware-the-final-frontier-achieving-the-promise-of-ocp-by-making-ocp-nodes-truly-open which describes work in the Open System Firmware (OSF) workstream http://opencompute.org/wiki/Open_System_Firmware

This is a forum where cloud service providers (CSP's), hardware, firmware, and software parties can engage on how to further ease development of servers in a more open, community fashion. This includes many types of lower-level boot firmware, OS hand-off interfaces, etc. Very much a pragmatic, 'getting things done' type of group.

Again back to the scale of scale. For the original Itanium we had closed source SAL, PAL, BIOS, and partially open source EFI sample. Now we can build a server image from content off the web. Quite the evolution over these last 2 decades.

Beyond the bits and bytes of the technology, the view of others on platform firmware standards like UEFI and ACPI is sometimes amusing. For example, many people type 'uEFI' (micro-EFI?) versus the full UEFI, or pronounce UEFI as 'YOO-FEE.'  We typically just pronounce each letter, U-E-F-I. Less often I've heard ACPI as ACK-PEE, including Heasman in his '07 talk https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf. This reminds me of my teen-age years, pre-internet, and growing up in Texas, when I'd read a lot of philosophy books, including Berkeley and Hegel. When I later had an opportunity to discuss these writers with others, I'd invariably mispronounce the names (e.g., HEGEL versus HAY-GEL, BERKLEY versus BARK-LEY). I guess we've all had this problem of reading a name for years but not hearing it spoken aloud.

It's time to close this tardy blog. I surely missed addressing some interesting events since my last blog posting given the many month absence from blogging. As such, the choice of topics herein less represent overall importance than proximity in time. So please assess using that lens.

© 2018, Vincent Zimmer. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 

Open Compute Project, CanSecWest and new specifications from the UEFI Forum

"The goal in technical writing is not to be possible to understand, but to be hard to misunderstand."- Cook

"Writing is nature's way of letting you know how sloppy your thinking is." - Guidon

Background
This blog is probably disappointing Cook and affirming Guidon's wisdom at the same time.

The danger of delaying posting a blog is catching up with recent events. As such, I have a bit of content to soldier through in this posting. The most exciting of late is the posting of the UEFI 2.5, PI 1.4, and ACPI 6.0 specifications http://www.uefi.org/specifications, but the preceding events definitely argued for much of the content and motivation which has appeared in those specifications.

I was on the road for a few weeks in March and April. First I attended the Open Compute Project (OCP) Summer 2015 summit http://www.opencompute.org/community/events/summit/ocp-us-summit-2015/ in sunny San Jose.

After that I sojourned north to attend the CanSecWest (CSW) conference in less-than-sunny Vancouver, B.C., Canada.

Although OCP treated opening up the designs of servers, and CSW was an information security conference, there were some common threads, such as openness, firmware, UEFI,....

And speaking of openness, I finished the tour in southern Washington State at the Open Source Technology Summit (OSTS).

OCP
To begin, the Open Compute Project http://www.opencompute.org/ hosts a community where common elements to build out the data center, such as network switch, server board schematics, rack mechanicals, etc can be shared.

Many companies are involved in OCP, with a recent discussion of resultant hardware at http://www.anandtech.com/show/9138/open-compute-hardware-tried-and-tested.

The keynote videos and presentations can be found at http://www.opencompute.org/blog/ocp-u.s.-summit-2015-video-and-presentation-links/.

OCP has made a lot of progress on opening up board designs, chassis specs, etc over the last few years.  But aligning on firmware hasn’t been a first priority.  I chatted w/ one company VP and his engineer afterward.  The quote from engineer was “firmware is our biggest head-ache, it should have been the first focus area of OCP.” This is because of requirements around device update, boot policy, and other aspects of a system that read directly on host boot firmware.

Mallik Bulusu from Microsoft and I https://www.flickr.com/photos/106659057@N08/16966691206/in/set-72157651601950765 spoke about some of the problem statements and opportunities in the cloud.  Material presented can be found at:

http://www.uefi.org/sites/default/files/resources/OCP_SJC_2015_UEFI_for_Cloud.pdf

This paper also treats briefly on the topic of open source support for these technologies and possibly entire server platforms.

Regrettably, the talk preceded the release of UEFI 2.5, ACPI6.0, and PI1.4, so we were not able to discuss some of that material as it was under UEFI Confidentiality at the time. We mentioned the firmware-related Cloud problem statements, such as scalable configuration and network provisioning. The latter, namely the boot-from-HTTP work defined in UEFI 2.5 via wire protocols, DHCP extensions, and new API's for HTTP, TLS, and DNS, will be touched upon later in this blog posting.

This talk seemed well-received, with some nice social media responses, too

Curt Brune ‏@curtbrune  Mar 11

Great #UEFI for Cloud preso by @vincentzimmer at #OCPSummit2015 @uefibios @OpenComputePrj

2 retweets3 favorites

Reply

 Retweeted2

 Favorite3

More

Speaking of Curt Brune above, his company Cumulus announced a usage of ACPI http://www.enterprisenetworkingplanet.com/netsp/cumulus-networks-introduces-the-acpi-platform-description-apd.html for network switches. Essentially the effort entails making the switch look like a server for purposes of running general purpose OS’s.  That’s another trend that is auspicious for the UEFI Forum-based technology and Intel as a component supplier to the switch hardware as a more open platform.

Beyond accretion of new functional technology in the UEFI Forum specification corpus, there were discussions of open source from http://www.rackspace.com/ in the context of their Power8 support. Specifically, from

http://www.theplatform.net/2015/03/23/inside-the-rackspace-openpower-megaserver/

"The parts that Rackspace is changing are inside the server and will take advantage of all of the firmware and systems software work that Rackspace has done already with X86-based systems and will also leverage the open firmware that IBM and Google have created for Power8 systems, which weighs in at around 420,000 lines of code."

Facebook also had a session on open sourcing their BMC with Yocto Linux, and discussions around mini-BMC's and FreeRTOS were also in the air.

So the addition of consistency of interfaces, in addition to more openness in the development model were described.

Open source is a prevailing theme of this blog, and I was chided by some in the open source community that firmware should be one of these things:

1- either perfect at inception
or
2- give people the source to do themselves
or
3- remove from pre-OS altogether

I argue that no software is perfect, but a community can strive to patch software, #1 can become 'imperfect but will patch." This is a place where UEFI2.5, ESRT, and capsules can help.

On #2, there are challenges with technology like hardware-verified boot, where 'protecting the user' and 'allowing innovation' have some interesting tension.  NIST 800-147 reads on allowing for physically present users to bypass protections, and Chromebooks have both developer mode and the write-protect screw, so I believe that you can balance the end-user protection and choice dialectic.

Finally, on #3 maybe there is a path forward? For client systems that boot in non-human perceptible time, maybe deferring things like graphics initialization into the operating system and omitting from the pre-OS could be a future-looking option?

CSW
Next, I embarked on a road trip from Seattle to Vancouver, BC, to attend CanSecWest https://cansecwest.com/agenda.html

As shown in the agenda, the Friday sessions led off with three offence talks and one defender talk, namely mine.  Throughout the sessions Dragos reiterated "The BIOS vulnerability beatings will continue until morale improves." https://twitter.com/dragosr/status/578988308853698560

My talk, now posted at https://cansecwest.com/slides/2015/UEFI%20open%20platforms_Vincent.pptx was intended to provide an alternative perspective on the firmware ecosystem. I led off with a summary of the history of boot firmware, the present standards and open source activities, and detailed a list of the salient open source collateral and platforms.

The one slide that most resonated with the crowd detailed the difference between the open source trunk, with fixes on http://www.tianocore.org/security/ and the resultant product trees on shipping platforms.

This is again where UEFI 2.5 and capsule updates, ESRT, and OS support across the Linux upstreams, disributions, and Windows comes into play.

Luckily I had the opportunity to speak to David Aucsmith ahead of my session, and he mentioned that a review of UEFI Secure Boot as a "Ceremony" was an appropriate lens to apply https://eprint.iacr.org/2007/399.pdf.

Carl Ellison http://world.std.com/~cme/ was a great mentor http://www.google.com/patents/US7328340 of mine during his time at Intel. Methodologies like Ceremonies remind us that the security of a system is rarely just in the mechanics of the cryptography, but instead spans the human and organizational actors. In the case of UEFI Secure Boot this includes the ecosystem, manufacturing-time provisioning, end user and enterprise management, etc. All of these flows need to be considered for purposes of system assurance.

Speaking of mentors, happy to see http://www.google.com/patents/US9015455 issued with Jim Held http://newsroom.intel.com/community/intel_newsroom/bios?n=James%20P.%20Held&f=searchAll, too.

SUSE's pioneering work on MOK https://www.suse.com/communities/conversations/uefi-secure-boot-details/ is a great example of a broader view of the solution space and required technology. Additional details on SUSE's work was also discussed at http://intelstudios.edgesuite.net/idf/2013/sf/aep/STTS002/STTS002.html.

I also had the opportunity to meet with the USB Armory http://www.inversepath.com/usbarmory.html team. They described how ARM TrustZone (TZ), although an architectural CPU mode, has configuration issues. Specifically, each SOC vendor does the configuration differently of ranges reserved for TZ. I smiled since this is similar to some of the malaise around System Management Mode (SMM) on IA32/x64, namely a consistent set of CPU behaviors but different SOC/CPU/chipset configuration techniques per product families.

The final aspect of the talk included threat modeling and open platforms. On the former, I reminded the audience of the threat modeling that motivates today's UEFI features and some future looking opportunities on protection. I also reviewed the Quark and Minnowboard MAX platforms, with their fully and partially open source UEFI EDK II implementations, respectively, as great opportunities to collaborate. On the topic of the MAX I elaborated recently on some of these sentiments at http://firmware.intel.com/blog/security-technologies-and-minnowboard-max.

Although it was tough to follow several hours of attack talks on UEFI, I felt it important to show up at CSW for several reasons. I wanted to show that the UEFI community was engaged, concerned and results-oriented in the face of these issues afflicting the platform. And I also wanted to reach out to the researchers on how we can work together to make the platforms, and thus the internet, a safer place for all of us.

Beyond this talk, we also posted some material on how to defend a EDK II-based platform during boot http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf.

The UEFI Forum has posted the revocation list, or DBX for UEFI Secure Boot, at http://uefi.org/revocationlistfile.

OSTS
My final stop has been the Open Source Technology Summit (OSTS), an Intel-hosted event in Skamania, WA. You can find some mention with the Twitter hash-tag #osts2015.

https://www.flickr.com/photos/davest/3339316813/in/photostream/ provides one view of the surroundings.

This final talk folded in some of the open source trends touched upon at OCP and CSW, and added some color on other community evolution.

I was jovial at the beginning, at least.

At this point I was fielding questions on secure boot, and I see that Linus in the audience has a grin.

Speaking of open source, another notable event since the last posting has been the release of the coreboot payload on http://www.tianocore.org. I mentioned this technology in http://firmware.intel.com/blog/edkii-fsp-and-other-topics and have some content in http://www.apress.com/9781484200711, but the code's now live at https://github.com/tianocore/edk2/tree/master/CorebootPayloadPkg and  https://github.com/tianocore/edk2/tree/master/CorebootModulePkg with a wiki at https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload.

Interesting community response after the posting included:

Patrick Georgi

Shared publicly  -  Mar 31, 2015

 #UEFI

coreboot support in Tianocore (so Tiano acts as coreboot payload, providing UEFI services to the OS), committed by Intel employees.

I'm not sure I would have believed this 4 years ago.

Specifications
Although I cannot hope to do this topic justice tonight, I'd like to elaborate on
PI1.4 spec http://www.uefi.org/sites/default/files/resources/PI_release_1_4.zip,
ACPI6.0 http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, and
UEFI2.5 http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf,
as described in the press release http://www.uefi.org/node/897.

On the back of the PI1.4 release, the Intel Firmware Support Package (FSP) 1.1 release has also been made
http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf. The latter leverages some of PI1.4, such as the graphics HOB definition. We also published a couple of papers on the creation / production of a FSP http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf and consumption / integration / usage http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf, respectively.

These specifications tie into the above talks via a few threads. One thread is the need to evolve UEFI technology for the cloud, and to that end the boot-from-HTTP portion of the UEFI 2.5 specification squarely targets this space. Below shows schematically model of booting wherein TFTP (and thus UDP) based PXE can move to HTTP (and thus TCP) based booting. The move to a connection oriented protocol removes some of the chronic data center complaints, such as time-outs in "booting the Skynet" http://en.wikipedia.org/wiki/Skynet_%28Terminator%29, or more formally, provisioning warehouse-scale computers http://research.google.com/pubs/pub35290.html.

In addition to the wire protocols and DHCP extensions, additional API's for the network boot program were created, such as HTTP, DNS, and TLS. The latter allows for an optional boot-from-HTTP-s flow. This solution also allows for in-band and out-of-band RESTful messaging, such as http://www.redfishspecification.org/. Although many data centers use dark fibre and don't have threat models beyond the integrity concerns mitigated by UEFI Secure Boot, TLS allows for confidentiality cover where deemed necessary.

And TLS comes more into play in order to support another scenario enabled by the UEFI 2.5 specification, namely boot-from-wifi.  Wi-Fi security requires a supplicant, which is typically EAP-TLS support. So the UEFI 2.5 specification updated EAP to work on concert with TLS for the WI-FI use case. Some of the WI-FI support is shown below.

In addition to WIFI, Bluetooth support was also added to the UEFI 2.5 specification. This allows for building IOT-style usages in UEFI, but more importantly works in tandem with WIFI above for the no-wires style usages found in today's phone, tablets, and slim laptops. Without this wireless evolution, UEFI and its wired networking support was becoming more of a server/datacenter technology and missing some of the prevailing client trends.

In order to support boot-from-HTTP, and other firmware network boot art, such as U-Boot, the
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml list has also evolved since the last blog posting.

Processor Architecture Types

Registration Procedure(s)

Expert Review

Expert(s)

Vincent Zimmer

Reference

[RFC5970]

Available Formats

CSV

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

In addition to boot-from-HTTP, DNS, TLS, wireless, Bluetooth, UEFI 2.5 also added REST support. REST can be built upon the new HTTP API for in-band networking usages, such as https://www.redfishspecification.org/, or via out-of-band to a baseboard management controller (BMC), with the new BMC device path providing identity.

As the chair of the UEFI Networking Sub-Team (UNST) and the UEFI Security Sub-Team (USST), I am proud of the work that the team members did the create this collateral.

And this is just a taste. USST also produced interfaces for inline cryptographic interface (ICI) hardware, smart cards, enterprise deployment of UEFI Secure boot, additional protection capabilities of the boot, stylized operating system and platform recovery, among the various additions. I am working with the subteams to provide rationale documents in order to let the world into the insights and deliberations that gave birth to these new technologies. In no way can a blog like this hope to scratch the surface on the topic areas.

Upcoming talks

Next stop of the talking tour is a bit easier for me. I only need to wander to the nearby UEFI Plugfest in Seattle to speak about "Addressing Firmware Challenges for the Cloud with UEFI" in mid-May http://www.uefi.org/node/887. This is a variant of the OCP talk above that will include insights and matter that is now public in the UEFI 2.5, ACPI 6.0, and PI1.4 specifications.

And then it's off to San Francisco to share a panel talk at the Design Automation Conference (DAC)
http://www2.dac.com/events/eventdetails.aspx?id=182-18 on hardware versus software security.

TUESDAY June 09, 1:30pm - 3:00pm | Room 300 

TRACK: SECURITY

TOPIC AREA: SECURITY

SESSION 18
PANEL: Design for Hardware Security: Can You Make Cents of It?

Moderator:

Saverio Fazzari - Defense Advanced Research Projects Agency, Washington, DC

Organizer:

 Saverio Fazzari

Given the proliferation of counterfeit electronics in the supply chain, recent breaches at major retailers and the ever-growing Internet of Things, there is evidence that electronic hardware is the "new frontier" for security compromise.  Yet the protection of hardware continues to take a back seat to software in cyber-defense. How real is the problem of hardware security?  Should there be a stronger push to develop and deploy security techniques in design? Finally, is there money to be made in hardware security? Who benefits and who pays?  

Panelists:

Ingrid Verbauwhede - Katholieke Univ. Leuven, Belgium
Siva G. Narendra - Tyfone, Inc., OR
Vincent Zimmer - Intel Corp., Seattle, WA
Dino A. DaiZovi - New York Univ., New York, NY
Lisa McIlrath - Raytheon BBN Technologies, Cambridge, MA

I'm glad to see "Intel Corp, Seattle, WA" next to my name. I'm hoping to put more of the Intel-in-the-Emerald-City visibility out in the community.

On the latter topic of "Hardware Security", as the 'firmware guy' it's always interesting to see which side of the fence I most straddle (psst - I still say 'software').