I'm sorry, this looks more about securing the boot for embedded devices and not really related to user control of firmware and preventing closed source code that takes away freedom/spy's on the user. The program of day one is below:
Main Room
OSFC 2022 Opening Event
Christian Walter , Philipp Deppenwiese
Open firmware on your infrastructure, not only for hyperscalers.
Erwan Velu
Talk details: Open firmware on your infrastructure, not only for hyperscalers.
Introduction to VBE - Verified Boot for Embedded
Simon Glass
Talk details: Introduction to VBE - Verified Boot for Embedded
Tillitis Key - A USB security key inspired by measured boot and DICE
Fredrik Stromberg , Sasko Simonovski , Michael 'MC' Cardell Widerkrantz
The “Thing” Around Your System Firmware
Christian Walter , Subrata Banik
Talk details: The “Thing” Around Your System Firmware
Protecting TPM Commands from Active Interposers
Jordan Hand
Talk details: Protecting TPM Commands from Active Interposers
FirmwareBleed: The industry failures to adopt SMM mitigations introduced years ago
Alex Matrosov , Philipp Deppenwiese
Talk details: FirmwareBleed: The industry failures to adopt SMM mitigations introduced years ago
I have come to bury the BIOS, not to open it: The need for holistic systems
Bryan Cantrill
Talk details: I have come to bury the BIOS, not to open it: The need for holistic systems
Linux as a UEFI bootloader and kexecing windows
Trammell Hudson
Talk details: Linux as a UEFI bootloader and kexecing windows
How Min Platform led to Max coreboot; a case study
ronald g. minnich
Talk details: How Min Platform led to Max coreboot; a case study
I'm not sure what exactly you're after, but much of firmware's responsibility is system initialization -- to be interested in open source firmware but be disinterested in booting is to not understand firmware's role in a system. And certainly there is nothing at OSFC about "preventing" closed firmware -- the only way to do that is to not purchase devices that have compute elements in them. (Good luck!)
And finally, if there's something different you would like to see at OSFC, submit a talk for OSFC 2024!
My understanding of open firmware is making sure that the booting process is accessible to the user. Securing the boot process from intruders is secondary to that. It appears that these talks are more about securing the boot process, rather than talking about how to make the boot process more accessible.
Secondly, these events looks like their geared toward the private sector, rather than enthusiasts. Why would I want to invest my time in contributing to a problem that is already made worse by commercial endeavors that seem to want to take control away from the user?
The OSFC is a direct outgrowth of the coreboot hackathons/conferences between 2014-2017, opening up to wider open source firmware topics. All the fun "how to open things up" subjects* have been talked to death in that community, so the conferences are now about questions like "how to improve on the state of the art in firmware?"
* https://ecc2017.com/schedule-location has the list of 2017 with gems like: DDR3 on Sandy Bridge, reversing Mediatek MT8173, reversing x86 microcode.
No disrespect intended, and you probably have good motives. I looked at those links and it still seems like the focus is on boot security, focused around ChromeOS. Regardless of whether or not the issue of "opening things up" has been talked to death in the coreboot/hackathon community (which sounds like a tactic to marginalize the enthusiast community), This is a critical topic right now for me, and i'm sure many others. Not everything is about providing security for embedded devices. I know this is an important topic for the commercial sector, but this push toward more security in the boot process seems more about locking people out of customizing their systems instead of providing security. IMHO, that is a terrible path to take if it becomes a standard for all computing, which many things seem to be heading in that direction.
No disrespect intended, but somehow you seem to expect others to solve your problems.
If you want to see talks about that "critical topic right now for" you, or even work done in that area, the surest way to get that is to put in the effort yourself.
Maybe the shout-out on this platform encourages somebody (e.g. you?) to present on the subject next year - that would be a win in my book.
The people and projects surrounding the OSFC has been working tirelessly for many years on changing things for the better. I can personally attest to the fact that the people involved are incredibly passionate about open source firmware.
Making firmware open source benefits vendors AND users. It serves commercial interests AND software freedom.
I'm noticing keywords like "tirelessly" "open source firmware" being used over and over without actually saying anything. Lots of generic terms, instead of being specific about what you mean.
I don't mean to nitpick, but people that actually care about the future of technology and want to make things better usually talk in specific terms rather than throwing out unspecific terminology.
"Tirelessly" is apt in this case. Please educate yourself about this community in general, and this conference in particular -- which I believe to be one of the best in tech: technically interesting, grounded in reality, relevant problems, terrific hallway track, supportive community, reasonable price!
I've been dealing with silicon vendors (Intel, AMD, some ARM implementers, a couple of other folks) on the subject of open source firmware (as in: GPLv2) for 15 years (as in: tirelessly). I've been arguing against locked boot processes behind the scenes and in public (e.g. https://patrick.georgi.family/2015/02/17/intel-boot-guard/). I held talks at coreboot conferences, even though I despise the spotlight.
That said: 15 years of activity is a lot of work to unpack in "specific terms", so "unspecified terminology" that still provides a rough overview it is.
> That said: 15 years of activity is a lot of work to unpack in "specific terms", so "unspecified terminology" that still provides a rough overview it is.
How about list of open firmware(preferably consumer grade, big corps can get it anyway) that you helped or developed?
And if it is so good, why more and more hardware needs closed firmware?
The relevant firmware project to answer here is coreboot: My contributions range from technical contributions (see git log, ~3.5% of commits are mine, as poor a benchmark as that is) to support in our forums to documentation to behind-the-scenes work that keeps the community together or pushes back against even more blobs.
As for "why more and more hardware needs closed firmware": In 2005, which PC started from open source firmware, outside select data center deployments?
Go watch Ron talks at this conference and Open Compute project. He and others have done an amazing to make sure its possible in the first place to use open fireware. And you know what, its not just 'technical' it has to do with politics and community.
If you want something 'specific' then I would point you to the Open Compute Project that has now basically mandated that certified servers allow consumers to install alternative fireware. That required a lot of effort and lobbying.
At the same time creating a community of users and vendors that enable new platforms before they are even released. Go look at the coreboot git to see this work.
The lobbying of the community has lead to AMD next generation boot firmware, OpenSil to be open source. Again, this didn't come out of no-where.
Open source firmware is mostly funded by hyperscalers; the consumer side (Purism/System76/Dasharo) is a small sideshow in comparison (for now). Ultimately open source firmware is less locked-down than proprietary firmware and the way to encourage more openness in the future is to buy open source firmware now. Is there any specific feature you want?
[0] https://www.osfc.io/2021/talks/on-hubris-and-humility-develo...
[1] https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...