There are many truisms you learn after working a while, such as the reality of meetings https://twitter.com/MichaelCarusi/status/1149162281294581761 (although I hear some people perennially relish meetings in order to not feel 'lonely' at work). There are other facts, such as 'nothing significant can be done quickly', especially in evolving a technology. I don't believe it's just a matter of the 99% rule https://en.wikipedia.org/wiki/Ninety-ninety_rule#cite_note-Bentley1985-1. Instead, it entails a process of successively building something and learning from usage and feedback. This takes time. Also, it needs to be done in an open, transparent fashion with the stakeholders so that the 'tech transfer' doesn't have a valley of death between R&D and deployment. Maybe this latter sentiment is an instance of my musings from years ago http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html?
A couple of 'recent' examples of this arc of evolution includes the dynamics of the "Min Platform", which really started out as an element of the Min-Tree, or "Minimal Tree" effort described in
slide 16 of https://github.com/vincentjzimmer/Documents/blob/master/OSTS-2015.pdf from 2015. Namely, move the EDKII code base from being a Hummer to a Yugo. I learned thereafter that a Yugo might not be the best example of a smaller end-state analogy.
Regarding moving toward the Yugo, construction had its first milestone in March 2016 via a 'code first' approach, as described in
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. This 2016 work, in turn, expanded and added server class systems
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 two years later in March of 2018. Now many of the elements of this work appear in the May 2019 Min Platform Architecture https://edk2-docs.gitbooks.io/edk-ii-minimum-platform-specification/.
Going back to the overall goal of a Min-Tree, the idea was to segregate silicon critical initialization code into the Intel Firmware Support Package (FSP) http://www.intel.com/fsp (described more below), minimize the platform code, and then right-size the generic 'core' code, such as the https://github.com/tianocore/edk2/tree/master/MdeModulePkg. Efforts to the latter end can be found at https://github.com/jyao1/edk2/tree/ReOrg/Mde where the packages needed to build a minimal platform's core can be derived. Another use case is an "Intel FSP SDK" where the minimal code to 'create' an Intel FSP https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf could be derived, enabling a future where more of the FSP elements could be shared. Other advantages of 'less code' include cognitive complexity, fewer attack surfaces (and time for 1st and 3rd party code reviews), easier maintenance, easier integration, and potentially easier updates/servicing (more on that later).
Although the Min-Core mention above has yet to be up streamed, many of the packages in https://github.com/tianocore/edk2 have been deleted in the last few months or migrated into https://github.com/tianocore/edk2-platforms. Projects like https://github.com/u-boot/u-boot/tree/master/lib/efi_loader also provide a minimized UEFI core, in addition to Rust based virtual firmwares https://github.com/jyao1/rust-hypervisor-firmware. UBoot and the hypervisor VMM only provide enough compatibility for the OS but avoid providing any PI capability. https://github.com/yabits/uefi provides both UEFI and elements of DXE PI, such as dispatching drivers from FV's https://github.com/yabits/uefi/blob/master/core/dispatch.c. Going forward https://github.com/intel/modernfw offers a venue to explore some of these directions in smaller profile cores and language-based security https://github.com/intel/ModernFW/issues/4.
Again, to build a full platform, you need platform + core + FSP in this model. A nice embodiment of bringing all three together is described in the Apollo Lake https://firmware.intel.com/sites/default/files/uefi_firmware_enabling_guide_for_the_intel_atom_processor_e3900_series.pdf. Another high level view of bringing all of these components together can be found in figure 6-19 of https://www.apress.com/us/book/9781484200711.
Speaking of ModernFW and FSP's, I'm pretty excited by some of the examples of alternate boots, such as https://github.com/intel/ModernFW/issues/10 and https://github.com/rprangar/ModernFW/tree/SBL_DNV_POC built upon https://github.com/slimbootloader/slimbootloader. The latter is again an arc of evolution from primarily coreboot based solutions to coreboot and Slim Bootloader. Leveraging the FSP's across these different 'consumers' demonstrates the scalability of the technology. Since Slim Boot Loader and coreboot take 'payloads', which can include UEFI https://github.com/tianocore/edk2/tree/master/UefiPayloadPkg or Linux or....does that mean the X64 UEFI variant is a "CSM64", as a dual to the CSM16 https://github.com/tianocore/tianocore.github.io/wiki/Compatibility-Support-Module (just kidding)?
Telescoping into the Intel FSP, its development followed a similar arc, with some of the direction intent described in https://firmware.intel.com/sites/default/files/SF14_STTS001_Intel%28R%29_FSP.pdf. The scaling of FSP commenced with codifying existing FSP practices as the 1.0 specification commencing in April 2014 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec.pdf and then point evolutions in 1.1 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf and 1.1a https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1a.pdf in April/November 2015. The 1.0 was really capturing the then-current practices and separating out the generic, class-like API's from the SOC specific "Integration Guide" dictum's. The 1.1/1.1a changes were derived from learning's with different flash layouts and roots of trust designs. These were still monolith FSP's. The 2.0 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf evolution in May 2016 was based upon SOC boot flow with non-memory mapped flash, think 'boot from eMMC/NAND/UFS', thus creating the FSP-T, M and S modules that could comprehend these boot flows. The Apollo Lake usage described above was one of the driving factors for this change.
Why the FSP2.1 evolution? In May of this year the FSP 2.1 https://cdrdv2.intel.com/v1/dl/getContent/611786 specification was released. It was created in response to the overhead of creating 'wrappers' to invoke the FSP 2.0 from a native EDKII firmware. These wrappers are defined in the 'consuming FSP' document https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf. The design of 2.1 maintains FSP 2.0 interface compatibility via "API Mode" usage and extends the design to include "Dispatch Mode." The latter entails guidance of how to use the FSP 2.1 binary as a well-formed UEFI PI Firmware Volume that includes a PEI core https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Pei, thus allowing for dropping the binary directly into a firmware device layout containing other FV's with PEI, DXE, and UEFI https://uefi.org/specifications images. This 2.1 change was based upon learning's in scaling FSP 2.0 in the last 3 years.
And in the spirit of evolving code with specifications, there are FSP 2.1 binaries available at https://github.com/IntelFsp/FSP/tree/master/AmberLakeFspBinPkg and platform code demonstrating "dispatch mode" at https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/KabylakeOpenBoardPkg. This in contrast to the Apollo Lake "FSP 2.0" example mentioned earlier.
In addition, there are more opportunities for streamlining platform construction with art like MinPlatform's, thinner core code, ModernFW, and Intel FSP's. These include optimizing servicing the platform. Work is available on microcode and monolithic firmware updates via https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf and its code embodiment https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg. Moving forward the separate elements are being made serviceable via the Firmware Management Protocol https://github.com/tianocore/edk2/tree/master/FmpDevicePkg, and it makes sense to enable separate servicing of components like Intel FSP's https://github.com/jyao1/edk2/tree/FspCapsule and other elements of the system based upon provenance. This will potentially help remove some of the friction in delivering on requirements like https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf.
And speaking of security, there are nice call outs at https://twitter.com/IntelOpenSource/status/1148638118867849217 and https://firmwaresecurity.com/2019/07/01/new-uefi-tianocore-documents/ for some of the updates to guidance on securing the firmware and having a shareable threat model with the community. This is especially important as we treat issues submitted via https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues. As described earlier, minimal* (core, platform, etc) ease in the assurance analysis given there is less complexity, but such analysis still requires some base erudition upon which to lead the design and code assessments.
I'll close with a bit or irony and humor. I mention above the use of safer languages like Rust, in addition to extolling the virtues of open,
but there really is no silver bullet. Similarly, I mentioned smaller, simpler and less complex, but the product still needs to be useful
And on those parting thoughts I'll close this blog.
Cheers
A couple of 'recent' examples of this arc of evolution includes the dynamics of the "Min Platform", which really started out as an element of the Min-Tree, or "Minimal Tree" effort described in
slide 16 of https://github.com/vincentjzimmer/Documents/blob/master/OSTS-2015.pdf from 2015. Namely, move the EDKII code base from being a Hummer to a Yugo. I learned thereafter that a Yugo might not be the best example of a smaller end-state analogy.
Regarding moving toward the Yugo, construction had its first milestone in March 2016 via a 'code first' approach, as described in
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. This 2016 work, in turn, expanded and added server class systems
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 two years later in March of 2018. Now many of the elements of this work appear in the May 2019 Min Platform Architecture https://edk2-docs.gitbooks.io/edk-ii-minimum-platform-specification/.
Going back to the overall goal of a Min-Tree, the idea was to segregate silicon critical initialization code into the Intel Firmware Support Package (FSP) http://www.intel.com/fsp (described more below), minimize the platform code, and then right-size the generic 'core' code, such as the https://github.com/tianocore/edk2/tree/master/MdeModulePkg. Efforts to the latter end can be found at https://github.com/jyao1/edk2/tree/ReOrg/Mde where the packages needed to build a minimal platform's core can be derived. Another use case is an "Intel FSP SDK" where the minimal code to 'create' an Intel FSP https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf could be derived, enabling a future where more of the FSP elements could be shared. Other advantages of 'less code' include cognitive complexity, fewer attack surfaces (and time for 1st and 3rd party code reviews), easier maintenance, easier integration, and potentially easier updates/servicing (more on that later).
Although the Min-Core mention above has yet to be up streamed, many of the packages in https://github.com/tianocore/edk2 have been deleted in the last few months or migrated into https://github.com/tianocore/edk2-platforms. Projects like https://github.com/u-boot/u-boot/tree/master/lib/efi_loader also provide a minimized UEFI core, in addition to Rust based virtual firmwares https://github.com/jyao1/rust-hypervisor-firmware. UBoot and the hypervisor VMM only provide enough compatibility for the OS but avoid providing any PI capability. https://github.com/yabits/uefi provides both UEFI and elements of DXE PI, such as dispatching drivers from FV's https://github.com/yabits/uefi/blob/master/core/dispatch.c. Going forward https://github.com/intel/modernfw offers a venue to explore some of these directions in smaller profile cores and language-based security https://github.com/intel/ModernFW/issues/4.
Again, to build a full platform, you need platform + core + FSP in this model. A nice embodiment of bringing all three together is described in the Apollo Lake https://firmware.intel.com/sites/default/files/uefi_firmware_enabling_guide_for_the_intel_atom_processor_e3900_series.pdf. Another high level view of bringing all of these components together can be found in figure 6-19 of https://www.apress.com/us/book/9781484200711.
Speaking of ModernFW and FSP's, I'm pretty excited by some of the examples of alternate boots, such as https://github.com/intel/ModernFW/issues/10 and https://github.com/rprangar/ModernFW/tree/SBL_DNV_POC built upon https://github.com/slimbootloader/slimbootloader. The latter is again an arc of evolution from primarily coreboot based solutions to coreboot and Slim Bootloader. Leveraging the FSP's across these different 'consumers' demonstrates the scalability of the technology. Since Slim Boot Loader and coreboot take 'payloads', which can include UEFI https://github.com/tianocore/edk2/tree/master/UefiPayloadPkg or Linux or....does that mean the X64 UEFI variant is a "CSM64", as a dual to the CSM16 https://github.com/tianocore/tianocore.github.io/wiki/Compatibility-Support-Module (just kidding)?
Telescoping into the Intel FSP, its development followed a similar arc, with some of the direction intent described in https://firmware.intel.com/sites/default/files/SF14_STTS001_Intel%28R%29_FSP.pdf. The scaling of FSP commenced with codifying existing FSP practices as the 1.0 specification commencing in April 2014 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec.pdf and then point evolutions in 1.1 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf and 1.1a https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1a.pdf in April/November 2015. The 1.0 was really capturing the then-current practices and separating out the generic, class-like API's from the SOC specific "Integration Guide" dictum's. The 1.1/1.1a changes were derived from learning's with different flash layouts and roots of trust designs. These were still monolith FSP's. The 2.0 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf evolution in May 2016 was based upon SOC boot flow with non-memory mapped flash, think 'boot from eMMC/NAND/UFS', thus creating the FSP-T, M and S modules that could comprehend these boot flows. The Apollo Lake usage described above was one of the driving factors for this change.
Why the FSP2.1 evolution? In May of this year the FSP 2.1 https://cdrdv2.intel.com/v1/dl/getContent/611786 specification was released. It was created in response to the overhead of creating 'wrappers' to invoke the FSP 2.0 from a native EDKII firmware. These wrappers are defined in the 'consuming FSP' document https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf. The design of 2.1 maintains FSP 2.0 interface compatibility via "API Mode" usage and extends the design to include "Dispatch Mode." The latter entails guidance of how to use the FSP 2.1 binary as a well-formed UEFI PI Firmware Volume that includes a PEI core https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Pei, thus allowing for dropping the binary directly into a firmware device layout containing other FV's with PEI, DXE, and UEFI https://uefi.org/specifications images. This 2.1 change was based upon learning's in scaling FSP 2.0 in the last 3 years.
And in the spirit of evolving code with specifications, there are FSP 2.1 binaries available at https://github.com/IntelFsp/FSP/tree/master/AmberLakeFspBinPkg and platform code demonstrating "dispatch mode" at https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/KabylakeOpenBoardPkg. This in contrast to the Apollo Lake "FSP 2.0" example mentioned earlier.
In addition, there are more opportunities for streamlining platform construction with art like MinPlatform's, thinner core code, ModernFW, and Intel FSP's. These include optimizing servicing the platform. Work is available on microcode and monolithic firmware updates via https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf and its code embodiment https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg. Moving forward the separate elements are being made serviceable via the Firmware Management Protocol https://github.com/tianocore/edk2/tree/master/FmpDevicePkg, and it makes sense to enable separate servicing of components like Intel FSP's https://github.com/jyao1/edk2/tree/FspCapsule and other elements of the system based upon provenance. This will potentially help remove some of the friction in delivering on requirements like https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf.
And speaking of security, there are nice call outs at https://twitter.com/IntelOpenSource/status/1148638118867849217 and https://firmwaresecurity.com/2019/07/01/new-uefi-tianocore-documents/ for some of the updates to guidance on securing the firmware and having a shareable threat model with the community. This is especially important as we treat issues submitted via https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues. As described earlier, minimal* (core, platform, etc) ease in the assurance analysis given there is less complexity, but such analysis still requires some base erudition upon which to lead the design and code assessments.
I'll close with a bit or irony and humor. I mention above the use of safer languages like Rust, in addition to extolling the virtues of open,
Cheers
