Hi Star, before you merged the two separate variable drivers in July 2015, each of the authenticated and the non-authenticated variable drivers would enforce its own GUID in the VARIABLE_STORE_HEADER.Signature field -- gEfiAuthenticatedVariableGuid and gEfiVariableGuid.
The consequence was that if you built a firmware with one of these drivers included, and the varstore that you passed it contained the *other* GUID (because it was originally formatted for the *other* driver), then the driver actually included in the firmware triggered an ASSERT(). Now, the unified driver seems to handle the varstore format dynamically. I just did a quick check: - I built OVMF with -D SECURE_BOOT_ENABLE first, - created a new varstore from the appropriate template (with gEfiAuthenticatedVariableGuid), - then rebuilt OVMF with SECURE_BOOT_ENABLE disabled, - and booted it on top of the preexistent varstore. It didn't fail. It would have failed before. 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? (The other direction, that is, going from SB-incapable to SB-capable with the same varstore, is not relevant for us; and it wouldn't be secure anyway.) Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
