It has been some time since I touched this blog. Thanks to Lee F. for his recent email bump "the blogosphere misses you" for reminding me of gap. I'll try to play a bit of catch up with today's posting.
I also need to refresh my postings to https://firmware.intel.com/blog but I have to admit that I prefer the Blogger interface - it auto-saves the content, it doesn't ask me to update my password every time I log in, it's easy to important graphics,....
And I'm really glad to see Tim Lewis blogging again http://uefi.blogspot.com/. He's one of the most talented guys I know in this industry and I enjoy reading his postings almost as much as I enjoy talking with him in person.
Regarding Tim's blog, he described the recent UEFI Forum publication of the PI 1.5 specification http://uefi.blogspot.com/2016/10/pi-15-released.html. The most notable update is the generalization of the System Management Mode (SMM) software model in volume 4 to the "Management Mode" or "MM" model that can accommodate both ARM TrustZone (R) (TZ) and IA32/x64 SMM. Historically we didn't unify the Itanium PMI software model with SMM since the former didn't offer the curtained execution model of both SMM and TZ. There are many commonalities of the latter two, though, such as the "SMI" activation mechanism, with "System Management Interrupt" for SMM and "Secure Management Interrupt" for TZ, etc. The ability to load earlier was informed by some ARM implementations establishing memory early and provisioning TZ, and also a potential SMM implementation of an early load https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf. One potential usage of the PI1.5 would be to cross-compile error logging code https://firmware.intel.com/sites/default/files/resources/A_Tour_beyond_BIOS_Implementing_APEI_with_UEFI_White_Paper.pdf between a x64 Server to an Aarch64 based server, for example.
Beyond the UEFI Forum, there has been more industry discussion of the Intel(R) Firmware Support Package (FSP). Specifically, this technology figures prominently in Tim's BlinkBoot (R) white paper http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-secure-iot-solutions-insyde-software-blink-boot-fsp-white-paper.pdf mentioned in http://uefi.blogspot.com/2016/10/intel-and-insyde-embedded-white-paper.html. That paper is co-authored by another FSP fellow traveler, Ravi R, who helped create the series of Intel FSP producer/consumer papers, including 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. Along with the latter white paper co-author Giri Mudurusu I delivered the talk “Intel Firmware Support Package 2.0 Overview” at the coreboot conference, San Francisco, CA, June 14, 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016. The presentation is posted to
At the same conference, my colleague Lee Leahy and I delivered “EDKII and CorebootPayloadPkg." The presentation is at https://github.com/vincentjzimmer/Documents/blob/master/EDK-II_and_CorebootPayloadPkg.pdf and the video at https://www.youtube.com/watch?v=I08NHJLu6Us.
On the coreboot payload package, in retrospect this code could have been generalized to the 'UEFI Payload Package.' Although the coreboot package has cbmem as its input data structures, which are then converted to HOB's, DXE and a UEFI implementation are easily launched from any environment with a HOB list. In fact, in the early days of Framework development we have a PEI shell command that would launch the DXE from the EFI Shell by just forging a HOB list. So this payload package could subsume today's DuetPkg https://github.com/tianocore/edk2/tree/master/DuetPkg, or EDKII on a PC/AT BIOS. Or the payload could be appended to U-Boot http://www.denx.de/wiki/view/U-Boot as an alternative to U-Boot native EFI implementation http://lists.denx.de/pipermail/u-boot/2016-February/244378.html, perhaps?
The coreboot conference was at a Google office near the waterfront in San Francisco, with the following view from the Google cafe.
With the following poster.
The poster chat provided a lot of discussion with members of the industry around data center host firmware and deployment, including interest in HTTP-S style deployments in lieu of today's TFTP-based PXE.
It was great to see Kushagra https://azure.microsoft.com/en-us/blog/author/kvaid/ on stage during the data center keynote, too.
When Kushagra was at Intel as a CPU architect he helped the firmware team pioneer the cache-as-RAM usages http://google.com/patents/us7254676 and later as a data center technologist some interesting platform solutions http://google.com/patents/us8984265 and http://google.com/patents/us7747846.
And during the event I was able to catch up with some colleagues on the show room floor, including Jeff Bobzin and Tim Lewis from Insyde, Dick Wilkins (thanks Bob H. for catching my typo in original posting) and Jonathan from Phoenix, and Stefano and Zach from AMI. Good folks all around.
After these sojourns to California, I gave a talk at the UEFI Plugfest http://uefi.org/2016FallUEFIPlugfest here in the Seattle area. You can find the talk material at http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf and the video at https://www.youtube.com/watch?v=_N1v_bWN4zk. Many of my slides on the specification's features listed the corresponding Github repository. I omitted a link to the capsule work since at the time of the talk the EDKII feature was under community review. If I were to reprise the presentation today I'd affix https://github.com/mdkinney/edk2/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery to the top of slide 7.
During the Plug Fest Microsoft's Scott Anderson also provided an overview of http://www.pcworld.com/article/3106726/windows/golden-keys-that-unlock-windows-secure-boot-protection-uncovered.html in slides 4 and 5 http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Security_Microsoft_Fall_2016.pdf.
In my UEFI Plugfest talk I also gave an update of the standards and some of the developments on EDKII, including mentioning some DMTF alignment topics I had also discussed at OCP https://www.youtube.com/watch?v=3yGbwUwwjxc. I also enjoined the community to complement the industry standards with more informative information. To that end, beyond the above presentations and new industry standards, I co-authored a few new white papers since my last blog posting, including:
“A Tour Beyond BIOS - Security Enhancement to Mitigate Buffer Overflow in UEFI,” October 2016,
I also need to refresh my postings to https://firmware.intel.com/blog but I have to admit that I prefer the Blogger interface - it auto-saves the content, it doesn't ask me to update my password every time I log in, it's easy to important graphics,....
And I'm really glad to see Tim Lewis blogging again http://uefi.blogspot.com/. He's one of the most talented guys I know in this industry and I enjoy reading his postings almost as much as I enjoy talking with him in person.
Regarding Tim's blog, he described the recent UEFI Forum publication of the PI 1.5 specification http://uefi.blogspot.com/2016/10/pi-15-released.html. The most notable update is the generalization of the System Management Mode (SMM) software model in volume 4 to the "Management Mode" or "MM" model that can accommodate both ARM TrustZone (R) (TZ) and IA32/x64 SMM. Historically we didn't unify the Itanium PMI software model with SMM since the former didn't offer the curtained execution model of both SMM and TZ. There are many commonalities of the latter two, though, such as the "SMI" activation mechanism, with "System Management Interrupt" for SMM and "Secure Management Interrupt" for TZ, etc. The ability to load earlier was informed by some ARM implementations establishing memory early and provisioning TZ, and also a potential SMM implementation of an early load https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf. One potential usage of the PI1.5 would be to cross-compile error logging code https://firmware.intel.com/sites/default/files/resources/A_Tour_beyond_BIOS_Implementing_APEI_with_UEFI_White_Paper.pdf between a x64 Server to an Aarch64 based server, for example.
Beyond the UEFI Forum, there has been more industry discussion of the Intel(R) Firmware Support Package (FSP). Specifically, this technology figures prominently in Tim's BlinkBoot (R) white paper http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-secure-iot-solutions-insyde-software-blink-boot-fsp-white-paper.pdf mentioned in http://uefi.blogspot.com/2016/10/intel-and-insyde-embedded-white-paper.html. That paper is co-authored by another FSP fellow traveler, Ravi R, who helped create the series of Intel FSP producer/consumer papers, including 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. Along with the latter white paper co-author Giri Mudurusu I delivered the talk “Intel Firmware Support Package 2.0 Overview” at the coreboot conference, San Francisco, CA, June 14, 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016. The presentation is posted to
https://github.com/vincentjzimmer/Documents/blob/master/Intel_FSP_2.0_Overview.pdf and the video can be found at https://www.youtube.com/watch?v=uzfiTiP9dEM&feature=youtu.be.
At the same conference, my colleague Lee Leahy and I delivered “EDKII and CorebootPayloadPkg." The presentation is at https://github.com/vincentjzimmer/Documents/blob/master/EDK-II_and_CorebootPayloadPkg.pdf and the video at https://www.youtube.com/watch?v=I08NHJLu6Us.
On the coreboot payload package, in retrospect this code could have been generalized to the 'UEFI Payload Package.' Although the coreboot package has cbmem as its input data structures, which are then converted to HOB's, DXE and a UEFI implementation are easily launched from any environment with a HOB list. In fact, in the early days of Framework development we have a PEI shell command that would launch the DXE from the EFI Shell by just forging a HOB list. So this payload package could subsume today's DuetPkg https://github.com/tianocore/edk2/tree/master/DuetPkg, or EDKII on a PC/AT BIOS. Or the payload could be appended to U-Boot http://www.denx.de/wiki/view/U-Boot as an alternative to U-Boot native EFI implementation http://lists.denx.de/pipermail/u-boot/2016-February/244378.html, perhaps?
The coreboot conference was at a Google office near the waterfront in San Francisco, with the following view from the Google cafe.
Nice view and food. Over breakfast one morning Ron Minnich and I discussed the RISC-V Supervisor Binary Interface (SBI) https://github.com/riscv/riscv-pk/blob/1e62fdfce7b0095a57e4672c6c5fa4d3efb33d2a/machine/sbi.S and how it was a similar model to the DEC Alpha PALcode https://en.wikipedia.org/wiki/PALcode. We each agreed that having a hardware interface is often preferable to yet more run time firmware interfaces like sbi.
And the after-hours activity for the conference included a visit to http://longnow.org/ with a mock-up of the 10,000 year clock
After this conference I revisited San Francisco again to deliver a poster chat at the Intel Developer Forum. Below is the abstract of the talk:
And the after-hours activity for the conference included a visit to http://longnow.org/ with a mock-up of the 10,000 year clock
After this conference I revisited San Francisco again to deliver a poster chat at the Intel Developer Forum. Below is the abstract of the talk:
SOFTC01 — New Firmware Security Requirements for the Modern Data Center
Details
Data center security relies on a core root of trust, which is provided by platform firmware. The latest Trusted Platform Module (TPM) standard, TPM 2.0*, and updated Unified Extensible Firmware Interface (UEFI) requirements for enterprise operating systems are critical for companies deploying modern, secure data centers. In this session, you will learn security practices for UEFI firmware in enterprise and data center environments, based on new OS requirements and capabilities
Data center security relies on a core root of trust, which is provided by platform firmware. The latest Trusted Platform Module (TPM) standard, TPM 2.0*, and updated Unified Extensible Firmware Interface (UEFI) requirements for enterprise operating systems are critical for companies deploying modern, secure data centers. In this session, you will learn security practices for UEFI firmware in enterprise and data center environments, based on new OS requirements and capabilities
Topics include:
• Update on latest UEFI standards for networking and security.
• Latest updates for TPM2.0.
• Guidance on building trusted enterprise class platform firmware.
• Update on latest UEFI standards for networking and security.
• Latest updates for TPM2.0.
• Guidance on building trusted enterprise class platform firmware.
About the Speaker
Vincent Zimmer Senior Principal Engineer, Intel Corporation
Vincent Zimmer is a Senior Principal Engineer in the Intel Software and Services Group. Vincent has been working on the EFI team since 1999 and presently chairs the UEFI Security and Network Subteams in the UEFI Forum www.uefi.org. He has authored several books and articles on firmware.
With the following poster.
The poster chat provided a lot of discussion with members of the industry around data center host firmware and deployment, including interest in HTTP-S style deployments in lieu of today's TFTP-based PXE.
It was great to see Kushagra https://azure.microsoft.com/en-us/blog/author/kvaid/ on stage during the data center keynote, too.
When Kushagra was at Intel as a CPU architect he helped the firmware team pioneer the cache-as-RAM usages http://google.com/patents/us7254676 and later as a data center technologist some interesting platform solutions http://google.com/patents/us8984265 and http://google.com/patents/us7747846.
And during the event I was able to catch up with some colleagues on the show room floor, including Jeff Bobzin and Tim Lewis from Insyde, Dick Wilkins (thanks Bob H. for catching my typo in original posting) and Jonathan from Phoenix, and Stefano and Zach from AMI. Good folks all around.
After these sojourns to California, I gave a talk at the UEFI Plugfest http://uefi.org/2016FallUEFIPlugfest here in the Seattle area. You can find the talk material at http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf and the video at https://www.youtube.com/watch?v=_N1v_bWN4zk. Many of my slides on the specification's features listed the corresponding Github repository. I omitted a link to the capsule work since at the time of the talk the EDKII feature was under community review. If I were to reprise the presentation today I'd affix https://github.com/mdkinney/edk2/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery to the top of slide 7.
During the Plug Fest Microsoft's Scott Anderson also provided an overview of http://www.pcworld.com/article/3106726/windows/golden-keys-that-unlock-windows-secure-boot-protection-uncovered.html in slides 4 and 5 http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Security_Microsoft_Fall_2016.pdf.
In my UEFI Plugfest talk I also gave an update of the standards and some of the developments on EDKII, including mentioning some DMTF alignment topics I had also discussed at OCP https://www.youtube.com/watch?v=3yGbwUwwjxc. I also enjoined the community to complement the industry standards with more informative information. To that end, beyond the above presentations and new industry standards, I co-authored a few new white papers since my last blog posting, including:
“A Tour Beyond BIOS - Security Enhancement to Mitigate Buffer Overflow in UEFI,” October 2016,
"A Tour Beyond BIOS - Security Design Guide in EDKII," September 2016
“A Tour Beyond BIOS Implementing Profiling in with EDK II,” July 2016 https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Implementing_Profiling_in_EDK_II.pdf
And under the guise of the UEFI Forum, "Establishing the Root of Trust," UEFI White Paper, August 2016, http://www.uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf was published.
The intent of such material is to provide rationale and some guidance on how one might successfully refine the standards into a working artifact, including ones based upon EDKII style technology.
Well, so much for a catch-up blog. I wish everyone a happy Thanksgiving tomorrow from the always raining-in-November Seattle area.
Well, so much for a catch-up blog. I wish everyone a happy Thanksgiving tomorrow from the always raining-in-November Seattle area.
