On 02/15/16 03:08, Zeng, Star wrote:
> 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.
Thank you for confirming, and yes, I agree it's a small price to pay for
the compatibility.
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
