Saturday, July 13, 2019

Evolving infrastructure takes time

There are many truisms you learn after working a while, such as the reality of meetings (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 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

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 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 This 2016 work, in turn, expanded and added server class systems two years later in March of 2018. Now many of the elements of this work appear in the May 2019 Min Platform Architecture

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) (described more below), minimize the platform code, and then right-size the generic 'core' code, such as the Efforts to the latter end can be found at 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 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 have been deleted in the last few months or migrated into Projects like also provide a minimized UEFI core, in addition to Rust based virtual firmwares UBoot and the hypervisor VMM only provide enough compatibility for the OS but avoid providing any PI capability. provides both UEFI and elements of DXE PI, such as dispatching drivers from FV's Going forward offers a venue to explore some of these directions in smaller profile cores and language-based security

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 Another high level view of bringing all of these components together can be found in figure 6-19 of

Speaking of ModernFW and FSP's, I'm pretty excited by some of the examples of alternate boots, such as and built upon 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 or Linux or....does that mean the X64 UEFI variant is a "CSM64", as a dual to the CSM16 (just kidding)?

Telescoping into the Intel FSP, its development followed a similar arc, with some of the direction intent described in The scaling of FSP commenced with codifying existing FSP practices as the 1.0 specification commencing in April 2014 and then point evolutions in 1.1 and 1.1a 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 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 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 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, thus allowing for dropping the binary directly into a firmware device layout containing other FV's with PEI, DXE, and UEFI 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 and platform code demonstrating "dispatch mode" at 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 and its code embodiment Moving forward  the separate elements are being made serviceable via the Firmware Management Protocol, and it makes sense to enable separate servicing of components like Intel FSP's and other elements of the system based upon provenance. This will potentially help remove some of the friction in delivering on requirements like

And speaking of security, there are nice call outs at and 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 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.