Re: [edk2-devel] [PATCH] OvmfPkg/PlatformInitLib: Fix integrity checking failed of NvVarStore in some cases

["joeyli" <jlee@suse.com>]

Hi Gerd,

Thanks for your response! 

On Wed, Dec 14, 2022 at 07:15:28AM +0100, Gerd Hoffmann via groups.io wrote:
>   Hi,
> 
> > When the variable store has those variables, then system booting/rebooting will
> > hangs in a ASSERT:
> > 
> > NvVarStore Variable header State was invalid.
> > ASSERT
> > /mnt/working/source_code-git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
> > ((BOOLEAN)(0==1))
> 
> I'm wondering how you manage to trigger this assert?
>

Sorry for I forgot to put my testing environment in patch description.
My testing is on qemu with OVMF:

- edk2-master or edk2-stable202211
	build --verbose --debug=1 -D SECURE_BOOT_ENABLE -D TPM_ENABLE -D TPM_CONFIG_ENABLE \
	-D NETWORK_IP6_ENABLE -D NETWORK_HTTP_BOOT_ENABLE -a X64 -b DEBUG -t GCC5 \
	-p OvmfPkg/OvmfPkgX64.dsc -D FD_SIZE_4MB -D NETWORK_TLS_ENABLE 

- qemu-7.1.0 with libvirt-8.0.0
  pc-q35 with pflash type and nvram:
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <loader readonly='yes' secure='no' type='pflash'>/usr/share/qemu/ovmf-x86_64-code.bin</loader>
    <nvram template='/usr/share/qemu/ovmf-x86_64-vars.bin'>/var/lib/libvirt/qemu/nvram/opensuseTW_VARS.fd</nvram>
 
- grub2 2.06 and Linux kernel 6.1.0-rc5

Two test cases, both of them can reproduce the assert:

- First booting to grub2 menu, then "virsh destroy" the guest.
  The second boot hangs in the "NvVarStore Variable header State was invalid." assert

- First boot to Linux kernel 6.1.0-rc5, bash shell prompt shows up.
  Then run shutdown or reboot command.
  The second boot hangs in in the "NvVarStore Variable header State was invalid." assert 
 
> > Adding more log to UpdateVariable() and PlatformValidateNvVarStore(), we
> > can see there have some variables have 0x3C or 0x3D state in store.
> > e.g.
> 
> PlatformValidateNvVarStore() validates the varstore in ROM before
> copying it to RAM.  The normal UpdateVariable() cycle changes the
> copy in RAM ...
>

Yes, in the first boot, those variables have 0x3C or 0x3C state be
created. After shutdown or reboot, system hangs in the second boot.
The assert shows up in debug log.

Thanks a lot!
Joey Lee