This year we’ve again had double track insight into the Open Source Firmware Conference as both participants and presenters. We want to share some thoughts that evolved during the talks and send kudos to many people who made this conference happen, starting with 9elements Cyber Security for gathering crucial voices of contributors from various firmware community corners. In this short, blogpost series, we will leave a few notes on every attended presentation, starting from day 1, according to the schedule with references and sources. You can go through the post or skip to the chosen conference. Remember, presented descriptions are only our humble opinion, not official statements of presenters. To watch the full video and get your own opinion, click the chosen title.
The Linux Vendor Firmware Service, an essential part of the Linux ecosystem, is worth digging in. It allows its users to keep hardware up to date with firmware updates. We appreciate enormous work Richard did for the community, and the success he achieved in convincing vendors. The firmware became living software, no more part of the hardware. Now we are waiting for fwupd for QubesOS. Thanks, Red Hat.
3mdeb – official LVFS consultant also contributes to LVFS:
- flashrom plugin - Artur Raglis
- fwupd for QubesOS - Norbert Kamiński
- fwupd for BSD - approved by NLNet and work in progress on our side
Based on the UEFI lifetime in the presentation it seems that Heinrich and U-Boot developers are interested in ARM and RISC-V support. Great insight for the presentation would be UEFI SCT compliance across various UEFI implementations for various platforms (QEMU, x86, RISC-V). Kudos to U-Boot for reporting status of UEFI validation and problems that we may experience when using UEFI Forum recommended tools.
Intel works on this contribution to enable efficient thermal management for Google Chromebooks. It is an important topic for all types of devices, especially those focused on energy saving, e.g. mobile platforms. The presenters discussed the added ACPI code and explained the code tree with its structure. This is significantly important because DPTF thermal management is used across many laptop devices, not only Chromebooks. Furthermore, the authors mentioned that they removed many duplicated files and code in favour of unification of the implementation. Also they made it more usable by removing hard to understand ACPI code and reducing the amount of code that platform must include.
Trammel, the founder, and contributor of safeboot, presented a great, practical talk around configuring UEFI Secure Boot tools. He explained safeboot configuration options, the threat model, and interestingly described attestation before accessing model (e.g. Google account, Lastpass account etc.) Thanks Trammel for your work safeboot.
PRM stands for Platform Runtime Mechanism and is designed to reduce the privileged SMM mode code. Certain SMI handlers are moved to PRM modules which operating system may call to handle an event. A few noticeable facts:
- some hardware resources can only be accessed in SMM
- RAS relies on SMM and SMI handlers
- UEFI Capsule Update and Authenticated Variables also leverage that mode
- SMM is related to OCP and server use cases
This talk reminded us concept proposed by Ron at the European coreboot Conference 2017.
This was one of the most important presentations during conference since it can be understood without much knowledge about firmware and gives clear signal that something is wrong even from perspective of reasonably big company.
John presented typical stages of hardware production (Prototype -> EVT -> DVT -> PVT -> Mass production) in light of problems with firmware ecosystem. One thing is that Silicon Vendors, ODM and IBVs don’t care about outdated hardware and outdated for them usually means it already was released to the market. Coincidentally it means solid enough to be deployed on server market customers site. Current ecosystem rushing through roadmap to meet stakeholders criteria and customers are left with whatever sub-optimal software stack was produced. Second there is no code code share in UEFI ecosystem. Interesting thing about Facebook build system is full representation (JSON) of every firmware component with hash - this means at least basic software supply chain control, which is critical for stable firmware maintenance. Facebook already coach hardware engineers to develop coreboot code. According to Facebook: it’s 2x faster to enable complex security features on coreboot than UEFI. Good to hear that! Interesting thing is that Facebook use 1000 reboots to test DRAM init, what in fact is interesting and we all should get to the point where this number of iterations works seamlessly on any DRAM configuration.
Jens showed us the details of System Transparency’s bootloader implementation, focusing on stboot LinuxBoot distribution. He described the state development, issues and deployment scenarios with swtpm testing and D-RTM (Intel version) use case for system provisioning with tboot. In light of 3mdeb involvement in TrenchBoot project this is definitely very interesting and since we heard decision about sticking to tboot instead of adopting TrenchBoot we would be glad to talk more about reasons behind that decision. Also we really like introduction of swtpm, which we discussed during 2020 Qubes OS mini-summit in light of S-RTM and D-RTM.
kexec based bootloaders are becoming a very popular and kexec itself are very capable (can boot Linux, Windows, Xen and more). kexec still is not robust, there is still a threat of DMA occurrence during kexec kernel loading. Not all Linux drivers are kexec-ready, they need a shutdown method to avoid undesired DMA and be relaunched correctly in new kernel.
Interesting presentation on the coreboot unit testing infrastructure with the use of cmocka framework. Jan showed the benefits, implementation details, tests build/run and the overall challenges. It looks like Google decided to have unit testing in coreboot and they selected for that job fellow Polish developers, so congratulations to Semihalf for entering the coreboot land and we wish them lot of successful contributions.
NCC Group presented its definition of Secure Boot (BSP), U-Boot usage, and its supply chain. Jon showed us a toolkit built for U-Boot security issues, and it’s functionality. Thank you NCC Group for delivering, as always, high-quality content in the area of embedded systems and embedded firmware security.
Thanks for getting here! We hope that you have found our summary helpful in exploring tech news within the firmware world. In the next blogpost we will present some thoughts on OSFC 2020 day 2.
If you think we can help in improving the security of your firmware or you are
looking for a training that can boost your team of developers inside UEFI,
coreboot or Yocto area, feel free to book a call with
us or drop us email to
contact<at>3mdeb<dot>com. If you are interested in similar content feel free
to sign up to our newsletter