This should be my last blog of 2018, so I'll keep it short.
I just wanted to note a couple of news items on the SMI Transfer Monitor which I long ago noted in https://firmware.intel.com/content/smi-transfer-monitor-stm. The NSA's evolution of the design as a checker was described earlier this year https://www.platformsecuritysummit.com/2018/speaker/myers/ and now has a public example https://github.com/EugeneDMyers/STM. This work, along with the patches to Xen to support the launch of the STM https://github.com/PPerfLab/xen/tree/stm-optin provides an exciting example of this technology being enabled.
Speaking of SMM, an interesting study of building systems without SMM was mentioned by an Intel colleague in the OCP talk described at https://firmwaresecurity.com/2018/12/30/alternatives-for-smm-usage-in-intel-platforms/. As opposed to jailing SMM code with an STM, this approach speaks to alternatives to implement capabilities formerly found in OEM SMM code in UEFI runtime and other portions of the platform.
Beyond the STM there is other interesting happenings in the world of open source firmware, including Microsoft's 'Project Mu' described in the blog posting
https://blogs.windows.com/buildingapps/2018/12/19/%E2%80%AFintroducing-project-mu/ and represented by various Github repositories https://github.com/topics/projectmu. There are interesting elements to be found, including test infrastructure https://github.com/Microsoft/mu_basecore/tree/release/201808/MsUnitTestPkg and https://github.com/Microsoft/mu_plus/tree/release/201808/UefiTestingPkg. On the security front, UEFI crypto interfaces https://github.com/Microsoft/mu_plus/tree/release/201808/MsCorePkg/MuCryptoDxe and a secure configuration infrastructure https://github.com/Microsoft/mu_plus/blob/release/201808/DfciPkg/Dfci_Feature.md for zero touch management can be found. These packages meet the spirit of the more 'code first' methodology I mentioned on slide 15 of http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf, for example. I've been told that although some folks in the Redmond area refer to UEFI as YOO-FEE https://vzimmer.blogspot.com/2018/03/open-platforms-and-21-or.html, no one refers to Project Mu as MOO-FEE.
Regarding EFI topics on Github, I opined about the EFI Byte Code (EBC) many years ago http://vzimmer.blogspot.com/2015/08/efi-byte-code.html, including challenges with natural integers, so I was happy to hear about an open source compiler with an EBC back-end https://github.com/retrage/elvm/tree/retrage/ebc-v2. I haven't dug in to see how they handle the sizeof(INTN) issue or if they just support x64. Either way, good stuff seeing the open source community pick up on this gap.
For my final topic I'd like to cover a talk from the Chaos Communications Conference (CCC). Watching this over the holiday has been a ritual of mine since I learned of talks like Trammell's Thunderstrike talk https://www.youtube.com/watch?v=TsRt76v8gPQ in 2014. This year's talk of interest was https://media.ccc.de/v/35c3-9778-open_source_firmware given by the organizer of OSFC https://osfc.io/ Zaolin. He mentioned the EFI on U-Boot work https://www.suse.com/media/article/UEFI_on_Top_of_U-Boot.pdf, which I find valuable since having alternate clean-room implementations helps increase the quality of the standard. Without alternate implementations, a single code base can become the de facto standard (recall the byte swap bug from my last blog). A couple of the data items were a bit off, though, such as the timeline with "1998 Apple EFI by Intel" when Apple didn't convert to EFI until the x86 transition in 2005 https://en.wikipedia.org/wiki/Macintosh.
The PowerPC Macs prior to the transition used Open Firmware based upon Forth. Maybe the first article in https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf can provide a better timeline? Beyond small nits like the latter, though, it was a great talk and advocacy for more openness in firmware. This blog also had a short mention in the talk, too.
Other talks at CCC I liked include https://hackaday.com/2018/12/31/35c3-safe-and-secure-drivers-in-high-level-languages/ which reinforces the argument around using safer languages in low-level code like device drivers. And of course I cannot forget Trammell's talk https://media.ccc.de/v/35c3-9597-modchips_of_the_state. It was a definite counterpoint to the Portland BSides panel https://bsidespdx.org/events/2018/speakers.html on this topic. When I asked Joe F. about the variety of panel members he smiled and replied "yes, we have diversity. Some of the panel members have beards, some don't." Ah, 2019.
Here's looking forward to a safe and productive 2019.
© 2018, Vincent Zimmer. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License
I just wanted to note a couple of news items on the SMI Transfer Monitor which I long ago noted in https://firmware.intel.com/content/smi-transfer-monitor-stm. The NSA's evolution of the design as a checker was described earlier this year https://www.platformsecuritysummit.com/2018/speaker/myers/ and now has a public example https://github.com/EugeneDMyers/STM. This work, along with the patches to Xen to support the launch of the STM https://github.com/PPerfLab/xen/tree/stm-optin provides an exciting example of this technology being enabled.
Speaking of SMM, an interesting study of building systems without SMM was mentioned by an Intel colleague in the OCP talk described at https://firmwaresecurity.com/2018/12/30/alternatives-for-smm-usage-in-intel-platforms/. As opposed to jailing SMM code with an STM, this approach speaks to alternatives to implement capabilities formerly found in OEM SMM code in UEFI runtime and other portions of the platform.
Beyond the STM there is other interesting happenings in the world of open source firmware, including Microsoft's 'Project Mu' described in the blog posting
https://blogs.windows.com/buildingapps/2018/12/19/%E2%80%AFintroducing-project-mu/ and represented by various Github repositories https://github.com/topics/projectmu. There are interesting elements to be found, including test infrastructure https://github.com/Microsoft/mu_basecore/tree/release/201808/MsUnitTestPkg and https://github.com/Microsoft/mu_plus/tree/release/201808/UefiTestingPkg. On the security front, UEFI crypto interfaces https://github.com/Microsoft/mu_plus/tree/release/201808/MsCorePkg/MuCryptoDxe and a secure configuration infrastructure https://github.com/Microsoft/mu_plus/blob/release/201808/DfciPkg/Dfci_Feature.md for zero touch management can be found. These packages meet the spirit of the more 'code first' methodology I mentioned on slide 15 of http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf, for example. I've been told that although some folks in the Redmond area refer to UEFI as YOO-FEE https://vzimmer.blogspot.com/2018/03/open-platforms-and-21-or.html, no one refers to Project Mu as MOO-FEE.
Regarding EFI topics on Github, I opined about the EFI Byte Code (EBC) many years ago http://vzimmer.blogspot.com/2015/08/efi-byte-code.html, including challenges with natural integers, so I was happy to hear about an open source compiler with an EBC back-end https://github.com/retrage/elvm/tree/retrage/ebc-v2. I haven't dug in to see how they handle the sizeof(INTN) issue or if they just support x64. Either way, good stuff seeing the open source community pick up on this gap.
For my final topic I'd like to cover a talk from the Chaos Communications Conference (CCC). Watching this over the holiday has been a ritual of mine since I learned of talks like Trammell's Thunderstrike talk https://www.youtube.com/watch?v=TsRt76v8gPQ in 2014. This year's talk of interest was https://media.ccc.de/v/35c3-9778-open_source_firmware given by the organizer of OSFC https://osfc.io/ Zaolin. He mentioned the EFI on U-Boot work https://www.suse.com/media/article/UEFI_on_Top_of_U-Boot.pdf, which I find valuable since having alternate clean-room implementations helps increase the quality of the standard. Without alternate implementations, a single code base can become the de facto standard (recall the byte swap bug from my last blog). A couple of the data items were a bit off, though, such as the timeline with "1998 Apple EFI by Intel" when Apple didn't convert to EFI until the x86 transition in 2005 https://en.wikipedia.org/wiki/Macintosh.
The PowerPC Macs prior to the transition used Open Firmware based upon Forth. Maybe the first article in https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf can provide a better timeline? Beyond small nits like the latter, though, it was a great talk and advocacy for more openness in firmware. This blog also had a short mention in the talk, too.
Other talks at CCC I liked include https://hackaday.com/2018/12/31/35c3-safe-and-secure-drivers-in-high-level-languages/ which reinforces the argument around using safer languages in low-level code like device drivers. And of course I cannot forget Trammell's talk https://media.ccc.de/v/35c3-9597-modchips_of_the_state. It was a definite counterpoint to the Portland BSides panel https://bsidespdx.org/events/2018/speakers.html on this topic. When I asked Joe F. about the variety of panel members he smiled and replied "yes, we have diversity. Some of the panel members have beards, some don't." Ah, 2019.
Here's looking forward to a safe and productive 2019.
© 2018, Vincent Zimmer. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License
