3 Jan
2024
3 Jan
'24
9:56 p.m.
On Wed, Jan 3, 2024 at 12:10 AM Warner Losh <imp(a)bsdimp.com> wrote:
On Tue, Jan 2, 2024 at 9:30 PM Theodore Ts'o
<tytso(a)mit.edu> wrote:
Sadly the situation is even more complex than this.
Consider AMD's EPYC processors: before the x86 cores start up, the PSP
(Platform Security Processor) starts up and does a lot of
pre-pre-initialization: it does DRAM timing training, for instance.
It's also responsible for loading the x86 payload out of the local
flash and setting up the x86 environment so that when those cores come
out of reset, they're running whatever was loaded (for instance, they
can load %cs on the BSC so that it starts somewhere other than the
architecturally-defined segment right below 4GiB). While cool in some
ways ("I don't have to train DRAM? Score!") the PSP is embedded in the
SoC and the firmware is a signed blob you get from AMD. I know there's
an ARM Cortex-A5 in there, but don't know much more about it and even
if I did, I have no way to generate signed images for it. :-/
The point is, even if you've got a completely open stack running on
x86 from the reset vector, there's almost certainly something else
somewhere that's not open (yet).
[snip]
I was confusing LinuxBoot with coreboot, which is
used on all ChromeOS devices after 2012, and which completely doesn't
use any magic binary blobs supplied by the mainbord vendor. The
tradeoff is that coreboot only supports a very restricted set of
hardware, since it has to do all of the things that are "normally"
done by the vendor's binary blobs to initialize the hardware devices,
etc. This only works if you have very tight control over hardware,
and you have enough influence that you can lean on the mainboard
vendors to allow the low-level programming details of their devices to
be released in open source code which that can be independently
verified and digitally signed by the OS vendor (such as Google in the
case of ChromeOS).
I think that some of the open laptops might have a binary blob or two
buried deep in their coreboot implementation. But it is far more open
system than EDK2 is... Most of the open parts of EDK2 are what are nerfed
by LinuxBoot. The private hidden ones are all that remain, alas. So if you are large enough, you can get all the
sources. If not, then you
have to put up with the binary blob, or not run on some computers. :(.
Yup. :-(
- Dan C.