Re: FreeBSD EFI projects

On Sun, Sep 16, 2018 at 11:29 PM Rebecca Cran <rebecca_at_bluestop.org> wrote:

> On 9/16/18 9:32 PM, Warner Losh wrote:
>
> >
> > What did you have in mind working on? I have a few things that are in
> > various stages of completeness around this issue that I've not had
> > time to polish off for the tree. Some I'd like to, but some may
> > benefit from a fresh perspective. Also, there's a fair number of
> > hidden bugs in the stuff committed around finding the whole path
> > sometimes and the like.
>
>
> One thing I've started working on is switching the ESP to use FAT32
> everywhere except the ISO images (due to the limitation in the El Torito
> format not supporting sufficiently large regions). The specifications
> from EFI 1.10 onward have been clear that only FAT32 is supported for
> the ESP (but that FAT12 and FAT16 must be supported for removable
> devices), and I've read that some systems do enforce that. Unfortunately
> that does mean the ESP must be a minimum of 33MB, but I think it's
> worthwhile for increased compatibility.
>

I think this is a good change. We've seen issues with the tiny systems and
FAT12 format, so we've switched to FAT16. But even with that, we're seeing
some issues, so using FAT32 is great.


> Related to that, I've also been working on removing the FAT filesystem
> templates that are currently checked into svn, instead generating them
> during the release stage.
>

I'd like to simply remove them entirely. They serve no useful purpose if we
have an installer / script that can newfs + copy files. they were
originally done so that we didn't have to change geom too much and could
just DD something to a partition, which matched well the GPT boot code case.

I've had some interest on #bsdmips about booting a 64-bit FreeBSD on old
> Apple systems that use 32-bit EFI: it sounds like it should be possible,
> and is something I'd like to try and get working.
>

That should be possible, but there's a number of issue dealing with the
32-bit EFI not having a direct map that we can use to generate the mapping
tables we need for the loader early in our boot. It's why we can't call the
EFI runtime on armv7, for example.


> I'd also really like to help move the changes to mount an existing ESP
> during installation instead of clobbering it towards being committed, if
> possible.
>

Another very worthwhile project.


> Another thing I'd like to work on is trying to catch corner cases like
> in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210244 where
> calling GetMemoryMap causes the memory map to become fragmented. I'd
> also like to try and improve diagnostics, for example at the moment if
> the system doesn't have enough memory to run the loader it silently
> exits instead of displaying an error message.
>

That would be awesome. When things work today, they work. When they don't,
it an be quite opaque to figure out, absent help from kib :).


> And I would also be interested in taking a look at any projects you've
> not completed yet, to see if I can help in any way.
>

Items on my list are:

(1) Retiring boot1.efi entirely before 13.0. It was originally designed to
be a small, never changing blob we'd toss into an ESP and have all the
smarts in loader.efi. However, to support GELI encryption, ZFS, and other
things, it's had to grow an increasingly frustrating amount of
functionality. Better to just use loader.efi. This does, however, require
that we solve the problem of updating loader.efi on installworld /
freebsd-update times, even on systems with non-standard setups. Moving to a
'standard' setup for EFI would be a good first step, as well as having a
script to do this both for when the ESP is mounted in a non-standard place,
as well as for when it's not mounted.

(2) Create a /dev/efi/boot for the drive/partition that we booted off of.
This will allow us to have a standard fstab which is more resilient to
oddities. NanoBSD could use this for it's ping-pong setup. I have some very
basic code here, but it's more the stubs to add this to geom, and not so
much on finding this information. Might be nice to also have a /dev/efi/esp
to identify the ESP we booted off of as well to cope with systems that may
have multiple potential ESP locations (at work we have this sort of setup
for redundancy).

(3) Add network interfaces to things that we know how to generate EFI
DEVICE PATH entries for.  I have some preliminary code that tries to match
up the ifnet entries with a MAC DEVICE_PATH that I'd hoped to use to add
netbooting support to efibootmgr.

(4) Final integration of efibootmgr into the installer so we can generally
install things robustly. Sadly, this has issues with some BIOSes not
honoring BootOrder. I have no code, but have been working with nathanw_at_ on
this.

(5) For those systems that do honor BootOrder, having nextboot implemented
using EFI variables would be sweet. I have vague ideas on this only.

Warner