[TUHS] Question about BSD disklabel history

[Warner Losh]

On Tue, Jan 2, 2024 at 9:30 PM Theodore Ts'o <tytso at mit.edu> wrote:

> On Tue, Jan 02, 2024 at 08:57:34PM -0700, Warner Losh wrote:
> >
> > Indeed. I got to deal with all of that, and more. I have finished writing
> > LinuxBoot support for FreeBSD. The normal kexec-tools, u-root, etc aren't
> > sufficient for FreeBSD because FreeBSD's kernel expects the boot loader
> > to setup a number of meta-data items that go with the kernel that include
> > all the information about the system that the kernel simply can't get
> once
> > you've entered long mode...
> >
> > Even with LinuxBoot, you are booting with UEFI, albeit with a much small
> > much smaller UEFI.
>
> Yeah, one of the older names of LinuxBoot was NERF (Non-Extensible
> Reduced Firmware).


I love the secondary meaning for nerf from gaming too:
"to reconfigure (an existing character or weapon), making it less powerful."


> 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. :(.

There's also a rewrite of coreboot in Rust called 'oreboot' which is
coreboot
without the 'C', since they want it to be even safer.

Many hyper-scale cloud companies will tend to use coreboot or related
> software instead of UEFI.  A public/published example of this is
> Facebook's Open Compute Project.
>

Yes. It was a concerted effort of all these stakeholders that got the
Linux kernel so it could tolerate such an early handoff.


> It *is* nice not to have to deal with UEFI at all, if you're lucky
> enough to be able to use hardware where it's not necessary....  Of
> course you won't be able to run Windows on those systems, but some
> would consider that a feature.  :-)
>

Yea... There's several experimental attempts at booting windows on
at least the UEFI-remnant machines. And it's (a) too F'ing weird and
(b) to far afield to get into here...

https://www.osfc.io/2019/talks/booting-windows-on-linuxboot/

has all the horrors of one such attempt. I think this is the 'create an
exec handler in Linux that can run .efi programs and emulate UEFI'
version...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240102/9c2cfb31/attachment.htm>