On Thu, Nov 01, 2018 at 03:13:37PM +0000, David Rusling wrote:
> I'll attempt not to add noise into an otherwise detailed and technical
> discussion, but I like to go back to first principles:
>
> [1] Does Peter's suggested mechanism extend the use model that exists
> between a kernel and UEFI?
> If so, I would suggest that that is dangerous ground. As a side note, is
> there a how to covering UEFI from a functional use point of view?
Right now (with the language changes discussed in the meeting) the
extent that it changes things are:
- to support platforms where SetVariable() can't work at runtime,
efivarfs needs to emulate create, append, and delete, and expose a
record of that history in order
- to support applying those changes as updates during pre-boot,
something on the shutdown path needs to write that log to a specific
file that's already well standardized.
So the only additional thing we needed or use from UEFI-the-spec is the
ability to tell that SetVariable() won't be there at runtime. That
change was approved in the USWG as of last week. From a running
firmware, we need that indication, and it needs to advertise that it
will read the log and process it during boot.
> [2] Is it reasonable to think about who 'owns' these variables?
> Usual database rules apply, one owner, no duplicates
It's not quite reasonable to think of them in aggregate that way,
because different variables exist for different reasons, and most of
them aren't for storage of things, they're communications mechanisms.
As a result, there are a couple of classes of variables, and who owns
what varies a little with them:
- Variables the platform firmware creates for its own purposes, it owns.
Often, but not always, these are bad ideas and result in lkml threads
about people doing things that are only moderately dumb (like "rm -rf /")
permanently bricking machines.
- Most variables defined by the UEFI spec (or potentially other specs)
that the platform firmware creates to communicate things to the OS,
the firmware owns. "ConInDev", for example, gives a list of devices
or device classes that can be used by the firmware as the console
input.
- Variables defined by specs for the OS to communicate with the
firmware, generally the OS owns, but often the firmware is tasked with
deleting them as part of its consumption. "OsIndications" is one of
these, for example.
As with those last two classes, all the variables defined in the UEFI
spec are owned according to what they do. Some more examples:
- Boot####, BootOrder, and BootNext are owned by the OS and consumed by
firmware (with some minor caveats)
- BootCurrent is owned by the system firmware and consumed by the OS
- Secure Boot key storage variables (PK, KEK, DB, DBX, etc) are owned
by whoever has the private key that matches the public key stored in
PK, or by the firmware if PK is not enrolled.
- Other "Secure Boot Policy Variables" are ("SecureBoot", "SetupMode",
etc) are owned by the firmware and consumed by the OS.
- Normal "authenticated variables" are owned by whoever has access to
the private key matching the public key they were created with, though
strictly speaking there's no actual guarantee the firmware won't throw
them away.
- Everything else, and sometimes Boot####, is owned by malware ;)
> [3] I think that I understand the need to work around a lack of file system
> storage in firmware by using the OS (however indirectly), but see question
> [1]
>
> [4] Bending over backwards to help deal with legacy implementations is a
> good goal, but how far is too far?
Particularly lack of file system storage *after* the OS takes control,
i.e. after the OS calls ExitBootServices(). That's key - what this
allows us to have isn't letting new systems use legacy implementations,
or even be designed like legacy systems. Instead, it gets us the
ability to have a *dramatically* simpler UEFI "Runtime Services"
implementation by not keeping control of the storage.
The mechanism we have here is very small, and requires less (and
simpler) firmware code that runs on the main CPU during OS runtime than
the previous mechanisms. That's a good thing.
--
Peter
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
