[U-Boot] [RFC] efi: variable support

[Alexander Graf]

On 19.07.17 18:38, Rob Clark wrote:
> On Wed, Jul 12, 2017 at 8:57 AM, Alexander Graf <agraf at suse.de> wrote:
>>
>>
>> On 25.06.17 00:29, Rob Clark wrote:
>>>
>>> Mapping from EFI variables to grub variables.  Still almost as many
>>> TODOs as lines of code, but just figured I'd send out an early version
>>> for comments.
>>>
>>> I was thinking of it as a useful way for u-boot to pass values to grub
>>> (although grub is still missing a way for grub scripts to retrieve
>>> UEFI variables).
>>>
>>> The rough idea is to encode GUID + variable name plus "efi_" prefix
>>> (to avoid unintended u-boot variables leaking into the UEFI world).
>>> And then encode the type (and attributes?) in the string value of the
>>> variable.  Ie. something like:
>>>
>>>     setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported
>>> (u64)0
>>
>>
>> That's a pretty nice idea altogether, I agree. I don't think the goal you
>> have in mind is good though.
>>
>> I don't really think we should ever allow grub to override the device tree
>> files - unless for development purposes. The reason we are in the dt mess we
>> are in today is because it's too easy. People associate device trees with
>> kernels, not hardware. That's just plain wrong: device trees describe
>> hardware, not Linux interfaces.
> 
> I kinda wish I could agree with you, but it breaks down quickly when
> you start getting into more complex SoC's.  There is enough that we
> simply haven't figured out how to model properly in dt.  5yrs from now
> I might agree with you ;-)

It's perfectly ok to mismodel things at first. Then the dt would simply 
contain the "old way" nodes as well as the "new way" ones.

Every time we find a case where this approach does not work, we need to 
ask ourselves why. And every time we should ideally find a solution so 
that next time we don't break backwards compatibility.

One good example for that is all of the clock framework mess we have 
today. As a result of that, Andre started to push that logic into ATF 
and made Linux just call into it. Conveniently that also fixes issues with

   a) partitioning hypervisors
   b) trustzone controlling devices in the same clock domain as linux

and I'm sure for other cases where we see it fail we will find solutions 
- at least if people care enough :).

> It might mostly sorta work most of the time if u-boot finds the most
> recent dtb (which at least in fedora would mean parsing all the
> dtb-x.y.z directory names and figuring out which is newest)

Well, the holy grail would be:

   ATF generates DT
   U-Boot uses that DT to configure itself
   U-Boot passes the same DT on to Linux

Of course you can cut the chain at any point. And we have to make sure 
that overrides are always easy enough.

> and btw, as someone who works on kernel to the "development purposes"
> is an important use-case to me..  and generally it isn't a good idea
> to make kernel developer's boot process significantly different from
> end users, or you'll just end up in a state where things constantly
> work for developers and are broken for distros ;-)

I agree :). We still want to have overriding mechanisms. And we do have 
them today. But the normal end user case should really not force them to 
have dtbs and kernels in lock-step.

Take a look at all the server platforms out there. They do work with dtb 
just fine and most of them managed to keep backwards compatibility 
working. The 2 cases I'm aware of really boiled down to "don't care" 
attitudes and thus would've been avoidable.

>> As for real variable support (for example to boot using a native EFI boot
>> order), I think this approach can work. But before committing to a specific
>> path to take, I'd like to see a full solution that allows us to maintain
>> these variables consistently in runtime services too, as that's required for
>> the boot order.
> 
> persisting variables, especially after we exit boot-services will
> be... interesting.
> 
> Rough idea is move env_htab into __efi_runtime_data and some simple
> accessors into __efi_runtime.  I think we'll need some board support
> to saveenv after a variable is written.  It seems tricky depending on
> where the variables are stored (ie. if they are on same eMMC that
> linux thinks it owns).
> 
> In some cases it might make sense for u-boot to own eMMC (and hide it
> from linux) and keep grub and rest of distro media on sd-card /
> usb-disk / etc.  I'm not entirely sure how that would work from
> kconfig option standpoint, and it would mean that we start adding
> drivers and a bunch more in the efi_runtime section.  (And then how to
> deal w/ dynamically allocated memory, etc)

That's why I wanted to push these pieces into EL3, as there's no way 
anyone can make U-Boot drivers work properly with UEFI's dynamic 
relocation mess :).

So if you want a "full uefi env" enabled platform, you'd have to steal a 
storage device completely into the secure world and only drive it from 
there. U-Boot would only call into EL3 to access that device and handle 
its own environment though it. Both in the boot time as well as the 
runtime case.

It really gets tricky if you don't have any dedicated storage available. 
Then we would be able to expose variables in the boot time case, but not 
in the runtime one. And I'm not sure how hard that would confuse 
applications ...


Alex