RFC: Handling of multiple EFI System Partitions

[Ilias Apalodimas]

On Mon, Dec 19, 2022 at 08:18:43PM +0900, Hector Martin wrote:
> On 19/12/2022 19.52, Ilias Apalodimas wrote:
> > Hi Janne, 
> > 
> > [...]
> > 
> >>>> function that can be called from board-specific code that sets the 
> >>>> UUID.
> >>>>
> >>>> Thoughts?  Would such a feature be useful on other hardware 
> >>>> platforms?
> >>>
> >>> efi/boot/bootaarch64.efi is only a fallback if load options are not 
> >>> set up. Once the operating system has generated a load option it is 
> >>> not used anymore.
> >>
> >> Setting load options from operation systems is currently not 
> >> implemented. The only readily available method to store variables is a 
> >> file in the ESP. This obviously can not be supported as UEFI runtime 
> >> service while the operation system is using the same disk.
> > 
> > Yes, but I'd skip the 'currently not implemented' part.  If you store your EFI
> > variables in a file on the ESP, we will *never* be able to (sanely) support SetVariable
> > at runtime. 
> > 
> >> It might be possible to use NOR flash as UEFI variable store. This could 
> >> cause issues with the primary boot loader iboot which we can not avoid 
> >> or with macOS in dual boot configurations.
> > 
> > It is possible.  In fact we already have code in U-Boot that stores the EFI
> > variables in an RPMB partition of the eMMC.  We also have (unfortunately
> > not yet upstreamed) code that stores the in an i2c eeprom in the secure
> > world. 
> > 
> > This is again situational though and none of these applies to MBPs.
> > SetVariable at runtime in an RPMB comes with it's own set of problems.
> > You basically need to replace the runtime services with OS provided ones...
> > The I2C one works fine.
> > 
> > But letting the implementation details aside, what we need to keep in mind,
> > is that being able to support SetVariable-RT primarily depends on the *hardware*
> > and there's gonna be hardware we'll never be able to support this. 
> 
> As far as I'm concerned, the NOR is an implementation detail under
> Apple's control and I would NAK any attempt at shoehorning EFI variables
> in there.
> This is global storage and Apple already have their own NVRAM
> format for boot settings (based on CHRP). Trying to abuse it for our own
> purposes is asking for trouble, since we can't coordinate anything like
> that with Apple. Plus there's a good chance they'll ditch the NOR and go
> NVMe-only in the future (they already do it like that on iOS devices).
> And if anything goes wrong we make user systems unbootable. Plus we
> still have the problem that there is a logical OS environment split
> before EFI, which means we'd still need multiple ESPs and an independent
> EFI variable store for each. And then if the EFI services owns the NOR,
> we *still* need to provide an Apple NVRAM interface to the OS, since we
> do want to be able to mutate that for things like configuring boot
> settings (boot chime, next boot OS, etc.) at the Apple/iBoot layer.

Yep we agree here

> 
> In my opinion, the only sane way to get EFI variables to work here is to
> use ubootefi.var and teach OSes how to manipulate it directly, in lieu
> of runtime services being available (or perhaps with some kind of
> callback layer so the OS can provide ESP file R/W services back to the
> runtime services). I'm not sure it's worth actually doing this, but I
> can't think of any other viable option if we decide we really want it.

We agree here as well.  In fact we are doing exactly the same thing for
variables that are stored in the RPMB (teach the OS how to do that) and
we'll send an RFC shortly.

Unfortunately this is not optimal, since we will violate the EFI spec, but
tbh there's nothing better we can do.  The spec basically dictates your
hardware configuration and if you don't have a dedicated storage for the
variables, it offers no sane alternatives.

Cheers
/Ilias
> 
> - Hector