Open Source Firmware Conference 2022 [videos]
osfc.io
osfc.io
It is fairly easy to backdoor or infect firmware, yet very few companies use components with open source firmware.
Infections can be dealt with frequent firmware verification but only solution for backdoors seems to be open source firmware.
UEFI is a big bloat of closed source security mess.
Secure boot. Just jump to start address of M2.SSD nothing more.
It happens to be the case that most organizations using UEFI-based firmware don't, and they keep everything beyond that core closed-source. This is not the fault of UEFI - those companies were closed source beforehand, and that trend continued. UEFI neither caused nor enabled them to be that way.
Now you may not want any of the things UEFI brings to the table, like GPT and booting to partitions larger than 2.2TB, or filepath based booting rather than sector based booting (or sector-booting into a boot manager and file booting from there). That's fine, but there's a difference between "X provides Y which I don't need" and "X causes Z which is bad" - UEFI causes almost none of the things people blame it for.
If you must blame UEFI for one thing, you can blame it for Secure Boot, as that wasn't (easily) possible with legacy BIOS. But neither is it mandated what keys it does or doesn't include, or even that it be implemented/enabled! UEFI has nothing to do with whether you should use Secure Boot - only that you can. The blame lies mostly with Microsoft for pushing so hard on vendors to ship with it enabled/locked/whatever.
Modern board, https://www.phoronix.com/review/coreboot-adl-dream
> If wanting to run Coreboot on a system today it basically means running a Google Chromebook, using an outdated server motherboard or old Lenovo ThinkPad that has seen a Coreboot port, or out of reach to most individuals are various server motherboards that are reference platforms or board designs from hyperscalers. But over the past several months the folks at the 3mdeb consulting firm have carried out a terrific feat: porting their "Dasharo" downstream of Coreboot to a modern and readily available Intel desktop motherboard. I've been trying this out and it has worked out surprisingly well.
Full coreboot board list: https://coreboot.org/status/board-status.html
A few laptop OEMs support coreboot, including Purism, System76, Starlabs Systems.
Protectli has mini firewalls with coreboot, including a model with ME disable and optional dTPM for measured boot, https://protectli.com/ & https://protectli.com/kb/coreboot-security-features/
https://puri.sm/products/librem-server/ https://puri.sm/products/librem-mini/
There are some other boards you may be interested in, which you can find at https://docs.dasharo.com/ Supported Hardware section.
I believe NovaCustom laptops are worth to mention especially that 12th Gen coming soon: https://configurelaptop.eu/coreboot-laptop/
Medical devices have a lot of strict regulations from multiple certification bodies (most famous one being FDA). Under IEC 62304, any RTOS becomes a SOUP item (Software Of Unknown Provenance). In practice this means that you would have to provide beyond reasonable evidence that the RTOS will do what you say it does, consistently. This is a long and expensive regulatory endeavor.
If you are going through the certification process and selling a medical device and then choose to open source its firmware, then more power to you.
However if you are thinking of publishing _open_ source firmware that will work on either 3rd party or open hardware, in my opinion you are setting yourself up for a world of litigation that very few individual persons can afford.