----- Original Message ----- > From: "Jonathan Zhang" <[email protected]> > To: "Timothy Pearson" <[email protected]> > Cc: "coreboot" <[email protected]> > Sent: Monday, September 2, 2019 12:06:54 AM > Subject: Re: [coreboot] Web site revamp
> Hi, > > I believe we have consensus that the current wording as-is may be > misleading to some audiences: >> "coreboot is an extended firmware platform that delivers a lightning fast and >> secure boot experience on modern computers and embedded systems. As an Open >> Source project it provides auditability and maximum control over technology." > > The proposal of "coreboot is an extensible firmware platform that aims > to provide a minimal boot environment for modern computers and > embedded systems. As an Open Source project it provides a flexible > framework for insertion of vendor specific firmware modules, and on > open ISA platforms aims to provide a fully open, auditable boot > process with maximum control over the technology.", however, does not > reflect the project's goal and architecture. > > Coreboot community (and its leadership) has been taking a (rightfully) > pragmatic approach, which moves the industry to the right direction. > Even though the pace is not as fast as many would wish, evidences show > the current strategy is the best we could have. > > What about following proposal: > coreboot is an extended firmware platform that delivers a lightning > fast and secure boot experience on modern computers and embedded > systems. As an Open Source project it aims to provide auditability and > maximum control over technology; On some platforms (especially > non-open ISA platforms), some boot functionalities are provided by > Silicon Vendor binary blobs. > > Thanks, > Jonathan I think it's far clearer than where we are today, and represents a step in the right direction for the public site. Perhaps even clearer would be to replace "especially" with "primarily" and "non-open ISA" with "proprietary ISA"? Just a thought. Regarding the AMD coreboot position, I am aware of it and have been for some time. I am also aware that AMD requires a PSP binary and has shown no actions toward removing that hard requirement, in fact moving more and more platform initialization into the signed PSP binary. This is my main contention -- EFI aside, what action has actually been taken by silicon vendors to reduce the amount of binary only and vendor-signed code required to execute from first system power on to the coreboot payload stage (i.e. where EFI, Linux, or GRUB tends to take over)? A quick glance through the tree is showing FSP practically everywhere for non-ancient Intel boards, so the number of Intel contributors is not exactly a relevant statistic -- of course Intel has interest in keeping its FSP working if that's all it needs to do to stop reverse engineering and replacement of the FSP / MRC code. And that's not even going into the ME problems. EFI was never the concern, I apologize if somehow that was not clear. My understanding was that LinuxBIOS was dealing quite well with the EFI objection alone. I understand pragmatism but I don't share the optimism here -- what I see directly (and some of this is also due to visibility into non-public items I likewise can't share) is that the vendor takeaway has been quite simple: move all the platform init away from what people traditionally call the EFI/BIOS, lock it behind a vendor signature, and then you can offer coreboot (or indeed any "payload" type firmware) support without ever running the risk of revealing any sensitive IP. This of course only works because lower level systems like the ME and PSP appear to be largely kept outside of coreboot's firmware model for, I presume, pragmatic reasons, and therefore no one from the public or even from the firmware development side questions the magic that happens to bring the system into a running state with DRAM trained and verifi ed boot already well into its measurement sequence. I keep bringing this up because I consider it a tragic loss for coreboot to be reduced to a mere loader or late stage device / ACPI setup role. I see nothing obvious in tree right now that contradicts this opinion, except for the rare cases where the larger community reverse engineered and re-implemented support for older Intel and AMD systems, and where those systems still have to run the ME/PSP binaries even at that level unless they are nearly a decade old or more. I welcome any improvements in the actual owner control situation, I simply do not trust Intel and AMD to adapt to service that requirement given past history and current smokescreen attempts surrounding the PSP in particular. Until I can literally compile my own PSP firmware, modify it, inspect it, load it, run it on real production hardware, etc. those systems represent a massive step backward from where we were even 7 years ago, with no statements from Intel or AMD that they will ever agree to unwinding that level of control at any point (in fact public statements have been made from both that state the exact opposite). I can download the complete firmware code from the very first instructions through the late stage loader on RISC-V and POWER systems. I can change that code, I can make a minimal firmware that truly fulfills the goals listed on the coreboot site if I want to, then run it on real production hardware. Why should that progress be hidden away in the (IMO vain) hope that the two x86 vendors will at some point embrace the same level of openness and owner control that we have *right here and right now* on so many other platforms? -- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
