"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:
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
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
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.
Patrick Georgi
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.
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
SESSION 18
PANEL: Design for Hardware Security: Can You Make Cents of It?
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?
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').
"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:
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
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.
"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
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.
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.
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 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
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 FazzariGiven 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
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').
