Re: RFC: Handling of multiple EFI System Partitions

[Hector Martin <marcan@marcan.st>]

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.

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.

- Hector