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.

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.

Porting to a new architecture

Part of the excitement of working with system firmware includes programming on bare metal. I recall taking an NT Driver class back in 1998 led by some Ex-DEC engineers. The engineer said "programming kernel mode drivers is tricky, but the real magic entails the work of the firmware guys." As an embedded guy working in this area since 1992, all I could say is 'Yes.'

The news about the RISC-V http://riscv.org/ port of coreboot http://review.coreboot.org/#/c/7065/ reminded me of some of the thrills in porting firmware to a new CPU architecture. A possible UEFI port for RISC-V is even mentioned during the technical discussion of this new instruction set architecture https://www.youtube.com/watch?v=vB0FC1DZqUM&feature=youtu.be.

Some of my favorite work includes bring-up for EFI on new CPU's. We started the EFI journey in 1998 working on Itanium and IA32. The Itanium port built upon SAL-A/B as the PI equivalent code, such as memory and CPU initialization http://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143.  Simarly, for IA32 we originally booted upon a PC/AT BIOS using techniques like DUET https://github.com/tianocore/edk2/tree/master/DuetPkg.

Over time we moved to native code for the platform initialization as the Framework specifications evolved. These Framework specifications became the UEFI Platform Initialization (PI) specifications, and the code base evolved from EDK http://tianocore.sourceforge.net/wiki/EDK to EDKII http://tianocore.sourceforge.net/wiki/EDK2.

In those early 2000's some fun path-finding was a port to XScale http://en.wikipedia.org/wiki/XScale. I mention that work a bit in the above article and also discuss the port in chapter 7 of  the first edition of Beyond BIOS http://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908 since Intel was still delivering XScale-based products, although EFI wasn't an official requirement. Instead, I used the XScale port to show the cross-architecture flexibility and scaling of both the specifications and the associated code bases. In the second edition http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/, I removed that content and replaced it with Intel IA32 SOC examples.

Ironic to think that I was possibly the first person to do an EFI port to 32-bit ARM, albeit EDK-based and it had a faked-PEI but full DXE.

After that the next excitement occurred with Intel64/EM64T/AMD64/X86_64, or as is now known in the UEFI binding, x64.  See chapter 2 of the UEFI2.4 specification at www.uefi.org. There the challenge was having to enable paging. Itanium also needed paging but we used software TLB handlers and had simple logic to program the TR registers in our SAL, then DXE CPU driver. For x64, we kept PEI to 32-bit since page tables in ROM and / or temporary RAM were tricky and ported DXE, our EFI/UEFI core, to 64-bits.

The crafting of .s/.asm files for a new architecture and getting through the first boot is more exciting than a platform port within a given architecture since there is a sense of pioneering with these foundation components.

Since this pioneering, the ARM community has done the EDKII ports to ARM32 and Aarch64 and they are first class citizens in the standards, including UEFI & PI, and the codebase, such as EDKII.

And although there isn't an official MIPS UEFI binding, there is a port to MIPS 32 at http://sourceforge.net/projects/efi-mips/.

I look forward to seeing more ports to UEFI, including the presently non-UEFI Power8 firmware such as https://github.com/open-power/skiboot.

Like the RISC-V work and ARM ports, I'll have to watch the latter efforts from the sidelines. My day job and extra-credit/after hours budget have enough Intel-architecture based efforts and opportunities to pursue.  Although I have to admit I miss some of the excitement of the port to ISA.Next.