Just get back from Chinese New Year holiday.
On 2016/2/6 1:55, Laszlo Ersek wrote:
On 02/05/16 13:37, Laszlo Ersek wrote:
On 02/05/16 13:18, Gerd Hoffmann wrote:
Hi,
So, my question is: is this intended and supported behavior (that is,
going from a Secure Boot-capable build to a Secure Boot-disabled build,
while preserving the contents & functionality of the variables), or just
a lucky coincidence that results from the design choices you made while
unifying the variable drivers?
Related followup question: If the driver can dynamically switch formats
now, is there any reason to ever create new varstores in the old format?
... Not only could this simplify packaging of binaries (because a single
varstore template could be shared by the different binaries), but also
OvmfPkg/VarStore.fdf.inc could be made independent of SECURE_BOOT_ENABLE.
Okay, I have some good news. I think the driver's and libraries'
behavior is not a lucky coincidence, they seem too well thought out for
that :)
Yes, it was well thought out.
So, I created a variable store like this:
- built OVMF with -D SECURE_BOOT_ENABLE
- saved the varstore template (with the auth variable GUID in its sig)
let's call this "auth-ed.tmpl"
- also created an actual varstore file from the template
- started a guest on top, created a non-volatile variable in the UEFI
shell (using the SET command, which places variables in the shell's
variable namespace), then shut off the VM. The variable name was
"foo", the contents were "bar".
- stashed the varstore in this state; let's call it "authed-with-var.fd"
- restarted the guest, enrolled the usual set of keys, booted Fedora
Live, verified Secure Boot was active, shut off the guest
- stashed the varstore in this state too; let's call it
"authed-with-var-and-keys.fd"
Then I rebuilt OVMF without Secure Boot, and booted it on top of the
three stashed varstores in turn. Results:
- in each case the guest started okay
- Secure Boot was *never* active (not even with
"authed-with-var-and-keys.fd")
- The UEFI shell listed (SET -v) the variable "foo" correctly, when
running on "authed-with-var.fd" and "authed-with-var-and-keys.fd".
This means that flipping the build from SB-capable to SB-less:
- non-authenticated variables will survive,
- Secure Boot will not be advertized even if it was enabled previously
I also tried to enroll keys anew with the SB-less OVMF binary. The
result is good, it didn't work -- the visual config utility
(SecureBootConfigDxe) is not built into the firmware to begin with, and
my own EnrollDefaultKeys.efi utility bails out immediately with an error:
error: GetVariable("SetupMode", 8BE4DF61-93CA-11D2-AA0D-00E098032B8C):
Not Found
SetupMode is a read-only, UEFI-standard variable; if it's not there in
an SB-less build, then everything's fine.
Then, I checked these results against the code, and the OVMF debug log.
In all three SB-less test cases, the following is logged:
Variable driver will work with auth variable format!
...
NOTICE - AuthVariableLibInitialize() returns Unsupported!
Variable driver will continue to work without auth variable support!
Note that the first line quoted is about the format of the varstore,
while the last line is about actually supporting authenticated variables.
The first line corresponds to the auth variable GUID in the varstore sig
(and to the matching variable header format) that the SB-less firmware
binary inherited from the SB-capable one. So that's good.
The last two lines come from this call stack:
VariableWriteServiceInitialize()
[MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c]
AuthVariableLibInitialize()
The VariableWriteServiceInitialize() function is common driver code, but
AuthVariableLibInitialize() is provided by one of the following library
instances (= "plugins"):
MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.c:
-- simply returns EFI_UNSUPPORTED
SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c:
-- here AuthVariableLibInitialize() does a bunch of things, among them,
it calls InitSecureBootVariables(), which ultimately creates the
"SecureBoot" read-only, UEFI-std variable that communicates whether the
platform is operating in Secure Boot Mode.
The selection between these library instances is correctly made in the
OVMF DSC files, based on -D SECURE_BOOT_ENABLE:
https://github.com/tianocore/edk2/commit/285542eb
Although I did test and review that patch:
http://news.gmane.org/find-root.php?message_id=%3c558d548a.8070...@redhat.com%3E
my testing at that time didn't cover this kind of switch-over from
SB-capable to SB-less build.
It's great that the variable driver is this flexible. I plan to submit a
patch that simplifies "OvmfPkg/VarStore.fdf.inc".
The only penalty for this flexible is the space waste by
MonotonicCount/TimeStamp/PubKeyIndex in AUTHENTICATED_VARIABLE_HEADER
after switch-over from SB-capable to SB-less build with auth variable
format, but I believe it is worthy.
Thanks,
Star
Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
