Subrata Banik
Subrata Banik is a Firmware Engineer with more than a decade being spent in the computer industry and acquired experiences in system firmware design, development and debugging across various firmware architectures like UEFI, coreboot, Slim bootloader etc. for x86 and ARM platforms. Subrata has profound experience on platform enablement that leads into working for all the leading PC-makers’ products. Subrata is an active member of open-source firmware (OSF) development across different projects like coreboot, oreboot, flashrom, EDKII etc., where he is one of the leading contributors in the open firmware (coreboot) development. Subrata has received multiple US Patents and is very passionate about learning new technology and sharing knowledge among enthusiast engineers. Subrata has presented his technical talks at industry events such as Open Source Firmware conference, Institute for Security and Technology, Intel Developer Forum etc.
Subrata is passionate about reading and writing, recently finished authoring two books (along with Vincent Zimmer) on embedded system firmware which is available for pre-order at https://www.amazon.com/Subrata-Banik/e/B09N9CXVQS. When not writing or working, he can be found enjoying watching sports (especially football) or spending time with his daughter. A fun fact about Subrata is, he is a strong believer of Time travel existence.
You can chat with Subrata on Twitter at @abarjodi or at Subrata Banik - Software Engineer - Google | LinkedIn.
The “Thing” Around Your System Firmware
Since the origin of the system firmware, it’s always remained closed-source and only nourished by a closed group knowing it might not be interesting for a larger audience. Over the last decade the movement around freedom in software development also touches the core of the firmware and open-source community demands even more openness in system firmware development. System firmware which is running at the most privileged level than any Ring 0 software (may be refer it as, Ring -1 or Ring -2 where CSE or PSP is running and lots of direct access to the hardware registers, sideband access etc.) is now demanding more openness.
In the last decade of open-source firmware (OSF) development, the community has experienced the support from most of the Silicon and Hardware vendors to ensure system firmware development using open-source projects like coreboot (as an example). But the fundamental problem that has been ignored so far is the invisible control of the silicon vendors in this entire system firmware development activity in terms of silicon reference code which has deployed as closed source binaries. coreboot, like any other OSF project, doesn't have any way to escape from its dependency. Additionally, open-source community members can’t contribute (honestly no visibility) to the silicon reference code. Hence, this talk is going to walk you through the “Thing” (a.k.a silicon reference code and associated firmware code running on your embedded device) that is around your system firmware and finally controls your free movement.
Outline:
- Current situation in OSF
- Problem statement
- Working towards standardizing how to handle silicon code in OSF
- One path towards more open-source in firmware
- Case Study: FSP-S Reduction in coreboot
- Outlook
Runtime configuration for coreboot
Currently coreboot limits update of many boot parameters such as FSP UPD, firmware configuration, devicetree settings etc. This limits developers/advanced users to change settings on the fly and requires recompilation of code which might not be everyone's forte. Last year we presented a talk on mitigating the FSP UPD setting issue using Micropython as a payload.Initially Micropython was enabled on coreboot using libpayload using QEMU platform and later extended for x86 platform to do initial proof-of-concept.
This lightning talk presents the demonstration of the earlier proposed design as well as improvements over the proposed design to make it architecture agnostic and more secure by aligning coreboot's existing infrastructure of security (vboot).
This holistic approach of updating configuration without recompilation of the image will allow coreboot to reach a wider audience and mitigate single most complaints from most of the OEM/ODMs who might want to change many configurations on the fly.