Security Friends and Collaborators

I am humbled to be included among the list of researchers mentioned by Ilja van Sprundel https://hardwear.io/netherlands-2022/speakers/ilja-sprundel.php in the photo

https://twitter.com/hardwear_io/status/1585619730412486657 with the prezo https://hardwear.io/netherlands-2022/presentation/assessing-security-of-SMM-supervisor.pptx. I have huge respect for Ilja and the research he has done. I am also happy to see former Intel colleagues and co-authors Alex and John from https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk listed, along with other former Intel colleagues Matrosov, Jesse, Mickey, Rodrigo https://www.blackhat.com/us-17/briefings/schedule/index.html#firmware-is-the-new-black---analyzing-past-three-years-of-biosuefi-security-vulnerabilities-6924, Yuriy, and Eugene. And it's only seemly having my present colleague Jiewen, who I also mentioned in the prior blog post http://vzimmer.blogspot.com/2022/10/a-tale-of-two-books.html, prominent on the list.

Speaking of John, I was reminded of him recently when reading a slack osf thread about CVE's and security. I still recall working with John when he came to Intel and took over leading the BIOS response issues. His first rebuke to me was the lack of an advisory process which led to the creation of the bespoke https://edk2-docs.gitbook.io/security-advisory/. This included the MOAP (mother of all patches) https://edk2-docs.gitbook.io/security-advisory/boot_failure_related_to_uefi_variable_usage. I still recall the strident feedback on having 'too much error checking' in a BIOS given the space constraints prior to MOAP. But threat models evolve, and from some of the same parties I was challenging to defend against errant i/o devices, with subject defenses now in place w/ IOMMU https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi.pdf and testing https://ieeexplore.ieee.org/document/9218694. Since then the community worked on having a closed mailing list and private Bugzilla, including moving the community to be a CVE Naming Authority (CNA) https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues. As always, still challenges in remediating issues but also opportunities in creating new defenses.   

Similar challenges over time supporting more open EDKII platform code for a big core client https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf, 

big core server 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, 

and a small core client https://cdrdv2.intel.com/v1/dl/getContent/671281. 

And sometimes this early pathfinding landed me in some unusual situations. After helping advice the community on getting RISC-V support into EDKII 

and working through some of the UEFI PI changes, one of the collaborators added me to a prospective speaker list for a RISC-V summit. This summit agenda was mentioned by eetimes https://www.eetimes.com/google-hp-oracle-join-risc-v/ 

 as including HP and Intel speakers. That notification led to some interesting Saturday morning cell phone call following an email thread with a set of executives, all of whom are in this picture and no longer with the company. 

I explained my advisory role in the standards work as co-chair of the Platform Initialization https://uefi.org/sites/default/files/resources/PI_Spec_1_7_A_final_May1.pdf (the PI spec looks after the API's in the green H in the figure above, and EDKII is used to 'build' the green H) Working Group and I summarily corrected the error with the RISC-V conference chair. Thus we had an interesting point on the RISC-V arc in 2015 that has now led to 2022 and a more salubrious story from eetimes https://www.eetimes.com/intels-invests-in-foundry-ecosystem-embraces-risc-v/.

Regrettably I couldn't make OSFC this year, but I caught a few of the slides and prezos online. I appreciated having a mention at minute 5:55 of https://www.osfc.io/2022/talks/how-min-platform-led-to-max-coreboot-a-case-study/ for the relicensing of FSP https://www.phoronix.com/news/Intel-Better-FSP-License. And speaking of books, the venerable Beyond BIOS has a mentioned at minute 15:50 of https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/, and the new books in final slide of https://talks.osfc.io/media/osfc2022/submissions/YXYNPF/resources/The__Thing__Around_Your_System_Firmware_HiPr4Ug.pdf. 

Another OSFC talk that would have been interesting is https://www.osfc.io/2022/talks/collaborative-firmware-payload-handoff-design/. Luckily the speaker was able to reprise at the USF meeting this week https://www.youtube.com/watch?v=oEBtWsBZve4&list=PLehYIRQs6PR6J9Zf6CajwsFkAHedDXjLI&index=13. As always great to see the various collaborators.

and I bumped into Lean Sheng later in the area, too. Interesting details on use of https://www.devicetree.org/specifications/ in lieu of HOBs.

Some background on payloads in https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_6 with presentations at USF at https://universalscalablefirmware.groups.io/g/discussion/files including CBOR https://universalscalablefirmware.groups.io/g/discussion/files/New%20data%20format%20for%20Universal%20Payload%20Interface.pdf and ARM https://universalscalablefirmware.groups.io/g/discussion/files/USF_meeting_4_May_2022.pdf.

Speaking of the new books and PI, the predecessor to PI was the "Framework." My co-presenter Bob Hart was giving my feedback on the 2022 books https://twitter.com/Apress/status/1585602975401140230

19 years after our joint prezo in 2003

And this morning I saw a patch on the EDKII mailing list that read on the network stack. It reminded me of that same 2003 IDF event where I gave another talk that included

This was part of the erstwhile "EFI1.2" specification that never came to light. Instead this work was contributed to the UEFI2.0 specification when the Intel-published EFI1.10 specification became the inaugural deliverable of the UEFI Forum in 2005. Since 2005 I have led the UEFI Network Subteam (UNST) in the UEFI Forum and I'm happy to have delivered some enhancements, such the "6" version of the above API's for IPV6 via the dual-stack model adopted by the UEFI forum for this space. After that the big lift was going from TFTP-based PXE to HTTP boot and bringing along more network-based security like TLS. Along the way other security enhancements like IPSec were removed, although not before a lot of the ecosystem shipped the upstreamed version with the test key https://www.cvedetails.com/cve/CVE-2021-28213/.

I have to admit that UEFI networking innovation has slowed a bit. The introduction of the HTTP boot & wireless missed the UEFI 2.3.1 specification upon which Windows8 and subsequent OS's depended upon so it didn't enjoy the broad industry enabling uplift at the time. And even if people want to continue using PXE because of its simplicity, work like https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf and its code https://github.com/tianocore/edk2-staging/tree/MpNetworkStack, driven by feedback from datacenter folks at the time, have been shadowed by move of many folks doing high-performance network deployment to https://www.linuxboot.org/ https://trmm.net/LinuxBoot_34c3/ and the scalable network stack maintained by the Linux community.

Heavy sigh. I'm definitely feeling the years.