I'd like to begin this posting with a review of work presented years ago. Specifically, my friend Harry H provided me copies of my first three Intel Developer Forum (IDF) presentations from 2003 https://github.com/vincentjzimmer/Documents/blob/master/Non-IA%20Silicon%20Support%20with%20the%20Intel%20Platform%20Inovation%20Framework%20for%20EFI%20-%202003.pdf https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf and 2004 https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf, respectively.
The first presentation was jointly delivered https://github.com/vincentjzimmer/Documents/blob/master/Non-IA%20Silicon%20Support%20with%20the%20Intel%20Platform%20Inovation%20Framework%20for%20EFI%20-%202003.pdf with Bob H and Michael K. This work informed some of the information in chapter 7 of the UEFI Book. The basics of the architecture haven't changed, with the notable exception of advocating the use of Intel(R) FSP https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf and associated marriage with open source platform code on http://www.tianocore.org.
That same 2003 event featured a solo talk on security features https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf. This talk included an introduction of the modular network stack which we internally ear-marked for a never-released "EFI 1.2" specification. These API's on slide 15 ended up appearing in the UEFI 2.0 specification circa 2006 http://www.uefi.org/sites/default/files/resources/UEFI_Specification_2_and_Errata_Sept16_08.pdf and later in the open source https://github.com/tianocore/edk2/tree/master/NetworkPkg. Beyond these API's, though, other elements like the EAP-Teanie method were never realized in the market. The best documentation of the latter appeared in a paper on using UEFI in the Cloud on pp. 4-5 https://github.com/vincentjzimmer/Documents/blob/master/SAM6560.pdf. Custom EAP methods violate the design precept of UEFI, namely leveraging well-known art, including authentication methods. Thus the recent focus on TLS for HTTP-S and EAP-TLS for our various network use-cases.
From 2004, other items that landed on the cutting run floor included the EFI_SECURITY_SUPPORT_PROTOCOL on page 20 of the presentation. In the ensuing ten years I attempted to standardize an interface like this in the standards body, but we have ended up instead with a library class https://github.com/tianocore/edk2/tree/master/CryptoPkg which can be layered directly on a static library such as OpenSSL or a private protocol. Finally, the pp 23-24 "COB's" of the EFI_CONFIGURATION_OBJECT_PROTOCOL never appeared in the open source or the standards, but the configuration aspects of slide 30 finally appeared in the UEFI standard from the original OEM-scoped HII Framework standard http://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-human-interface-infrastructure-specification-v091.pdf.
So much for IDF in 2003. In 2004 we presented on EFI Security extensions again in https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf. In this talk we elaborated on the 2003 talk with more details, including slide 17 for PE/COFF EFI image integrity. Since that talk we have evolved a UEFI image integrity model in https://github.com/vincentjzimmer/Documents/blob/master/SAM4542.pdf (2007),
https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Networking-and-Pre-OS-Security.pdf (2011), and https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf (2012). Same story on the rest of the vision, though. The vision of smart objects like COB's was not realized in the market.
A common theme on the IDF 2003 and 2004 presentation was the topic of provisioning, though. With the UEFI 2.6 specification, x-UEFI, and HTTP boot, the vision has been realized in a different figuration in 2016 https://github.com/vincentjzimmer/Documents/blob/master/UEFI%20Plugfest%202015%20-%20UEFI%20and%20the%20Cloud%20-%20003%20Bulusu%20-%20Zimmer%20.pdf https://github.com/vincentjzimmer/Documents/blob/master/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf. As such, I can claim the ball has been moved down the field in the last decade.
Another topic that perhaps hasn't progressed as much in the last decade entails language-based security (LBS). Back in the early 2000's I investigated how technology like http://www.cs.cornell.edu/talc/ might be applied to the EFI firmware https://patents.google.com/patent/US6978018B2/en, including a failed port to https://cyclone.thelanguage.org/. That's why I am excited to see efforts like https://firmwaresecurity.com/2015/09/04/rust-and-uefi/, including the write up http://ceur-ws.org/Vol-1746/paper-15.pdf. These efforts show promise to complement other security efforts in this space. I also enjoyed the reference in the latter paper to the EFI memory map white paper, UEFI book, and Cloud presentation. To me this affirms the value of openness, from publications down to the source code, in evolving an ecosystem.
Another interesting intersection of Rust and system software is http://www.tockos.org/ which a colleague at a nearby company mentioned to me over lunch. I need to dig into this work in the future.
Speaking of ecosystem evolution, I also want to cite our write up on the recently upstreaming capsule design https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. If this paper work were to have pre-dated the Rust paper perhaps it would have been the capsule reference in lieu of the "BZ15" one? This latter white paper reads on 'platform recovery,' such as described in the UEFI PI specification. As a complementary overview of operating system (OS) recovery there is https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf which explicates some of the technology in the UEFI specification and touched upon by me at the last UEFI plug fest.
Now off from working in an urban area
to a more suburban office
I'm not sure which is spookier.
Well, enough of looking in the rear-view mirror today. Let's instead face the wind screen and continue forward down the road.
The first presentation was jointly delivered https://github.com/vincentjzimmer/Documents/blob/master/Non-IA%20Silicon%20Support%20with%20the%20Intel%20Platform%20Inovation%20Framework%20for%20EFI%20-%202003.pdf with Bob H and Michael K. This work informed some of the information in chapter 7 of the UEFI Book. The basics of the architecture haven't changed, with the notable exception of advocating the use of Intel(R) FSP https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf and associated marriage with open source platform code on http://www.tianocore.org.
That same 2003 event featured a solo talk on security features https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf. This talk included an introduction of the modular network stack which we internally ear-marked for a never-released "EFI 1.2" specification. These API's on slide 15 ended up appearing in the UEFI 2.0 specification circa 2006 http://www.uefi.org/sites/default/files/resources/UEFI_Specification_2_and_Errata_Sept16_08.pdf and later in the open source https://github.com/tianocore/edk2/tree/master/NetworkPkg. Beyond these API's, though, other elements like the EAP-Teanie method were never realized in the market. The best documentation of the latter appeared in a paper on using UEFI in the Cloud on pp. 4-5 https://github.com/vincentjzimmer/Documents/blob/master/SAM6560.pdf. Custom EAP methods violate the design precept of UEFI, namely leveraging well-known art, including authentication methods. Thus the recent focus on TLS for HTTP-S and EAP-TLS for our various network use-cases.
From 2004, other items that landed on the cutting run floor included the EFI_SECURITY_SUPPORT_PROTOCOL on page 20 of the presentation. In the ensuing ten years I attempted to standardize an interface like this in the standards body, but we have ended up instead with a library class https://github.com/tianocore/edk2/tree/master/CryptoPkg which can be layered directly on a static library such as OpenSSL or a private protocol. Finally, the pp 23-24 "COB's" of the EFI_CONFIGURATION_OBJECT_PROTOCOL never appeared in the open source or the standards, but the configuration aspects of slide 30 finally appeared in the UEFI standard from the original OEM-scoped HII Framework standard http://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-human-interface-infrastructure-specification-v091.pdf.
So much for IDF in 2003. In 2004 we presented on EFI Security extensions again in https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf. In this talk we elaborated on the 2003 talk with more details, including slide 17 for PE/COFF EFI image integrity. Since that talk we have evolved a UEFI image integrity model in https://github.com/vincentjzimmer/Documents/blob/master/SAM4542.pdf (2007),
https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Networking-and-Pre-OS-Security.pdf (2011), and https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf (2012). Same story on the rest of the vision, though. The vision of smart objects like COB's was not realized in the market.
A common theme on the IDF 2003 and 2004 presentation was the topic of provisioning, though. With the UEFI 2.6 specification, x-UEFI, and HTTP boot, the vision has been realized in a different figuration in 2016 https://github.com/vincentjzimmer/Documents/blob/master/UEFI%20Plugfest%202015%20-%20UEFI%20and%20the%20Cloud%20-%20003%20Bulusu%20-%20Zimmer%20.pdf https://github.com/vincentjzimmer/Documents/blob/master/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf. As such, I can claim the ball has been moved down the field in the last decade.
Another topic that perhaps hasn't progressed as much in the last decade entails language-based security (LBS). Back in the early 2000's I investigated how technology like http://www.cs.cornell.edu/talc/ might be applied to the EFI firmware https://patents.google.com/patent/US6978018B2/en, including a failed port to https://cyclone.thelanguage.org/. That's why I am excited to see efforts like https://firmwaresecurity.com/2015/09/04/rust-and-uefi/, including the write up http://ceur-ws.org/Vol-1746/paper-15.pdf. These efforts show promise to complement other security efforts in this space. I also enjoyed the reference in the latter paper to the EFI memory map white paper, UEFI book, and Cloud presentation. To me this affirms the value of openness, from publications down to the source code, in evolving an ecosystem.
Another interesting intersection of Rust and system software is http://www.tockos.org/ which a colleague at a nearby company mentioned to me over lunch. I need to dig into this work in the future.
Speaking of ecosystem evolution, I also want to cite our write up on the recently upstreaming capsule design https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. If this paper work were to have pre-dated the Rust paper perhaps it would have been the capsule reference in lieu of the "BZ15" one? This latter white paper reads on 'platform recovery,' such as described in the UEFI PI specification. As a complementary overview of operating system (OS) recovery there is https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf which explicates some of the technology in the UEFI specification and touched upon by me at the last UEFI plug fest.
Now off from working in an urban area
to a more suburban office
I'm not sure which is spookier.
Well, enough of looking in the rear-view mirror today. Let's instead face the wind screen and continue forward down the road.
