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.