When OVMF tried to restore the variables from the file-based NvVars, it
failed to set the read-only variable and aborted the restoration with
this message:
Variable Check ReadOnly variable fail Write Protected - 04B37FE8-F6AE-480B-BDD5-37D98C5E89AA:VarErrorFlag
Since it's a read-only variable maintained by the firmware, it's
pointless to restore the previous value, so the check can be
relaxed to allow EFI_WRITE_PROTECTED returned from SetVariable.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
"SerializeVariablesLib.h" is pure LF, while "SerializeVariablesLib.c" is
mixed (its only CRLF terminators are from commit e678f9db89). Convert
them both with "unix2dos".
"git show -b" produces no code hunks for this patch. Due to its simple and
mechanic nature (and because it blocks the application of another patch),
it's being committed without review.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg's file-based NvVar storage is read back as follows at boot (all
paths under OvmfPkg/Library/):
PlatformBdsPolicyBehavior() [PlatformBdsLib/BdsPlatform.c]
PlatformBdsRestoreNvVarsFromHardDisk()
VisitAllInstancesOfProtocol
for each simple file system:
VisitingFileSystemInstance()
ConnectNvVarsToFileSystem() [NvVarsFileLib/NvVarsFileLib.c]
LoadNvVarsFromFs() [NvVarsFileLib/FsAccess.c]
ReadNvVarsFile()
+-------------> SerializeVariablesSetSerializedVariables() [SerializeVariablesLib/SerializeVariablesLib.c]
| SerializeVariablesIterateInstanceVariables()
| +-------------> IterateVariablesInBuffer()
| | for each loaded / deserialized variable:
| +-|-----------------> IterateVariablesCallbackSetSystemVariable()
| | | gRT->SetVariable()
| | |
| | IterateVariablesInBuffer() stops processing variables as soon as the
| | first error is encountered from the callback function.
| |
| | In this case the callback function is
| IterateVariablesCallbackSetSystemVariable(), selected by
SerializeVariablesSetSerializedVariables().
The result is that no NvVar is restored from the file after the first
gRT->SetVariable() failure.
On my system such a failure
- never happens in an OVMF build with secure boot disabled,
- happens *immediately* with SECURE_BOOT_ENABLE, because the first
variable to restore is "AuthVarKeyDatabase".
"AuthVarKeyDatabase" has the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
attribute set. Since the loop tries to restore it before any keys (PK, KEK
etc) are enrolled, gRT->SetVariable() rejects it with
EFI_SECURITY_VIOLATION. Consequently the NvVar restore loop terminates
immediately, and we never reach non-authenticated variables such as
Boot#### and BootOrder.
Until work on KVM-compatible flash emulation converges between qemu and
OvmfPkg, improve the SECURE_BOOT_ENABLE boot experience by masking
EFI_SECURITY_VIOLATION in the callback:
- authenticated variables continue to be rejected same as before, but
- at least we allow the loop to progress and restore non-authenticated
variables, for example boot options.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14390 6f19259b-4bc3-4df7-8a09-765794883524
Gary Lin
Laszlo Ersek
jljusten