[edk2-discuss][edk2-devel] UEFI variables not getting stored in nvram disk

[edk2-discuss][edk2-devel] UEFI variables not getting stored in nvram disk

[Het Gala]

[-- Attachment #1.1: Type: text/plain, Size: 7382 bytes --]




-------- Forwarded Message --------
Subject: 	[edk2-discuss] UEFI variables not getting stored in nvram disk
Date: 	Mon, 17 Jul 2023 23:24:45 +0530
From: 	Het Gala <het.gala@nutanix.com>
To: 	discuss@edk2.groups.io
CC: 	Kallol Biswas [C] <kallol.biswas@nutanix.com>



Hi edk2 community,


We have a scenario - testcase1, with uefi enabled VM having an Empty 
CDROM. PxE boot, EFI internal Shell (already mentioned by default by 
UEFI) and CDROM are the boot options. We also have a pflash / nvram disk 
by default attached if it is an uefi enabled VM. So, we have a nvram 
disk attached to the system.


In testcase1, (opened the UEFI Boot Manager --> changed Boot Order --> 
saved Boot Order --> continue --> Guest reboot followed by power cycle 
--> again open UEFI Boot Manager) changed Boot Order is not persisted 
and falls back to the default Boot Order. Same observation is seen for 
other uefi variables (ex. autoboot timeout / Next Boot / Display 
resolution changes) too. None of the modified / changed uefi variables 
are persisted after guest reboot followed by power cycle.


On the other hand, when we have a similar scenario testcase2, but 
instead of an empty CDROM, we have a vdisk (~ 10G) with an guest OS 
image (~ 1.7G) mounted on that disk. We observed that, the modified uefi 
variables (ex. change in Boot order / change in display resolution) are 
persisted after modifying uefi variable value followed by guest reboot 
and power cycle. The modified variables are stored inside NvVars file (~ 
200 MB). This file is inside efi/boot partition, which is made on the 
same vdisk where guest OS image is also mounted, because the vdisk is 
having space left.


IIUC, if SMM driver enabled while building OVMF binary, and have an 
external pflash drive to save the uefi variables (nvram disk), the 
modified uefi variables are stored inside the nvram disk, otherwise in 
absence of SMM driver stack, the NvVars file gets mounted on the OS disk 
if enough space is available.

In testcase2, SMM driver option (-D SMM_REQUIRE) is present in the OVMF 
binary file, and also has external nvram disk attached to the VM, even 
then the uefi variables are stored on the vdisk instead of nvram disk.


Question is : How can we make Boot Order (and other modified uefi 
variables) persistent when a OS vdisk is not mounted to the uefi enabled 
VM ?


---------------------------------------------------------------------------------------------------------------------------------------------------

(Attaching references for testcase1 and testcase2 below)


For testcase1 : attaching some debug statements here of the default Boot 
order (1.a), the changed boot order (1.b), and the boot order followed 
by guest reboot and power cycle (1.c).

(1.a) Here it shows the default initial Boot order


  [Bds]OsIndication: 0000000000000000^M
  [Bds]=============Begin Load Options Dumping ...=============^M
    Driver Options:^M
    SysPrep Options:^M
    Boot Options:^M
      Boot0000: UiApp              0x0109^M
      Boot0001: UEFI QEMU DVD-ROM QM00005 0x0001^M
      Boot0002: UEFI PXEv4 (MAC:506B8D83F4DB) 0x0001^M
      Boot0003: EFI Internal Shell                 0x0001^M
    PlatformRecovery Options:^M
      PlatformRecovery0000: Default PlatformRecovery               0x0001^M
  [Bds]=============End Load Options Dumping=============^M
  [Bds]BdsWait ...Zzzzzzzzzzzz...^M
  [Bds]Exit the waiting!^M
  ValidateSetVariable - Variable 
(8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootCurrent) returning Success.^M


(1.b) Changed the order from 1->2->3 to 1->3->2 from the UEFI Boot 
Manager Menu. To verify whether the Boot order has actually changed or 
not after saving the Boot order from uefi GUI, added some debug 
statments after 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L614 
<https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L614>.


   DEBUG((EFI_D_INFO, "Printing the boot Order here.\n"));

   for (Index = 0; Index < BootOrderSize / sizeof (UINT16); Index++) {

     DEBUG ((

       EFI_D_INFO, "  BootOption %u: %04x\n",

       Index,

       BootOrder[Index]

       ));

   }


And the log files printed the changed Boot order, below and that 
confirmed that the modified Boot Order has been set 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L624 
<https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L624>.

  Printing the boot Order here.^M
    BootOption 0: 0001^M
    BootOption 1: 0003^M
    BootOption 2: 0002^M
    BootOption 3: 0000^M


(1.c) On Guest reboot followed by power cycle, on reopening the UEFI 
Boot Maintainance Manager GUI, found the Boot Order to fall back to the 
default order. (Attaching a screenshot of the Boot Order as attachment).


-------------------------------------------------------------------------------------------------------------------------------------------------------

For testcase2 : attaching the partition made by efi/boot on the guest, 
with a proof that the modified uefi variables are stored in the NvVars file.


(2.a) On the Guest OS, /boot/efi made a partition of 200MB


[root@localhost <mailto:root@localhost>~]$ lsblk -l

NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda   8:0    0   12G  0 disk

sda1    8:1    0  200M  0 part /boot/efi

sda2    8:2    0    1G  0 part /boot

sda3    8:3    0 10.8G  0 part

cl-root 253:0    0  9.6G  0 lvm  /

cl-swap 253:1    0  1.2G  0 lvm  [SWAP]

sr0  11:0    1 1024M  0 rom


(2.b) Inside the /boot/efi partition, there is the NvVars file. After 
this, the uefi variables were modified / changed.


[root@localhost <mailto:root@localhost>~]$ ls -al /boot/efi

total 36

drwx------. 3 root root 16384 Dec 31  1969 .

dr-xr-xr-x. 5 root root  4096 Oct 23  2019 ..

drwx------. 4 root root  4096 Oct 23  2019 EFI

-rwx------. 1 root root 11019Jun  915:51 NvVars


(2.c) After guest reboot followed by power cycle, the change in uefi 
variables was persistent. And to verify, where the modified variables 
were stored, we could see the date change in the NvVars file -> 
signifying the latest change in UEFI boot manager menu.


[root@localhost <mailto:root@localhost>~]$ ls -la /boot/efi

total 36

drwx------. 3 root root 16384 Dec 31  1969 .

dr-xr-xr-x. 5 root root  4096 Oct 23  2019 ..

drwx------. 4 root root  4096 Oct 23  2019 EFI

-rwx------. 1 root root 11019Jun 1206:56 NvVars

[root@localhost <mailto:root@localhost>~]$ date

Mon Jun 12 06:58:13 EDT 2023


Thanks,
Het Gala


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108417): https://edk2.groups.io/g/devel/message/108417
Mute This Topic: https://groups.io/mt/101223763/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #1.2: Type: text/html, Size: 63499 bytes --]

[-- Attachment #2: Screenshot 2023-07-13 at 2.23.49 AM.png --]
[-- Type: image/png, Size: 67282 bytes --]

Re: [edk2-discuss][edk2-devel] UEFI variables not getting stored in nvram disk

[Laszlo Ersek]

On 9/7/23 22:24, Het Gala wrote:
> 
> 
> 
> -------- Forwarded Message --------
> Subject: 	[edk2-discuss] UEFI variables not getting stored in nvram disk
> Date: 	Mon, 17 Jul 2023 23:24:45 +0530
> From: 	Het Gala <het.gala@nutanix.com>
> To: 	discuss@edk2.groups.io
> CC: 	Kallol Biswas [C] <kallol.biswas@nutanix.com>
> 
> 
> 
> Hi edk2 community,
> 
> 
> We have a scenario - testcase1, with uefi enabled VM having an Empty
> CDROM. PxE boot, EFI internal Shell (already mentioned by default by
> UEFI) and CDROM are the boot options. We also have a pflash / nvram disk
> by default attached if it is an uefi enabled VM. So, we have a nvram
> disk attached to the system.
> 
> 
> In testcase1, (opened the UEFI Boot Manager --> changed Boot Order -->
> saved Boot Order --> continue --> Guest reboot followed by power cycle
> --> again open UEFI Boot Manager) changed Boot Order is not persisted
> and falls back to the default Boot Order. Same observation is seen for
> other uefi variables (ex. autoboot timeout / Next Boot / Display
> resolution changes) too. None of the modified / changed uefi variables
> are persisted after guest reboot followed by power cycle.
> 
> 
> On the other hand, when we have a similar scenario testcase2, but
> instead of an empty CDROM, we have a vdisk (~ 10G) with an guest OS
> image (~ 1.7G) mounted on that disk. We observed that, the modified uefi
> variables (ex. change in Boot order / change in display resolution) are
> persisted after modifying uefi variable value followed by guest reboot
> and power cycle. The modified variables are stored inside NvVars file (~
> 200 MB). This file is inside efi/boot partition, which is made on the
> same vdisk where guest OS image is also mounted, because the vdisk is
> having space left.
> 
> 
> IIUC, if SMM driver enabled while building OVMF binary, and have an
> external pflash drive to save the uefi variables (nvram disk), the
> modified uefi variables are stored inside the nvram disk, otherwise in
> absence of SMM driver stack, the NvVars file gets mounted on the OS disk
> if enough space is available.
> 
> In testcase2, SMM driver option (-D SMM_REQUIRE) is present in the OVMF
> binary file, and also has external nvram disk attached to the VM, even
> then the uefi variables are stored on the vdisk instead of nvram disk.
> 
> 
> Question is : How can we make Boot Order (and other modified uefi
> variables) persistent when a OS vdisk is not mounted to the uefi enabled
> VM ?

There are too many disparate things going on in your setup:

- controlling the boot order from within the guest as opposed to via fw_cfg

- using pflash vs. not using pflash

- building with SMM_REQUIRE or not.

Short suggestion:

- always use pflash; if you see an NvVars file, your setup is broken (we
can safely say this in 2023). In fact use *two* pflash chips, one for
code, one for varstore.

- if your QEMU command line includes the "bootorder" property for any
device, then OVMF BDS will filter and reorder the UEFI boot options,
most likely overriding or otherwise masking your earlier in-guest
settings. This is intentional.

- SMM_REQUIRE or not is not relevant for the Boot#### and BootOrder
variables.

Please provide your QEMU and edk2 versions, your edk2 build command, and
the QEMU command line.

Laszlo

> 
> 
> ---------------------------------------------------------------------------------------------------------------------------------------------------
> 
> (Attaching references for testcase1 and testcase2 below)
> 
> 
> For testcase1 : attaching some debug statements here of the default Boot
> order (1.a), the changed boot order (1.b), and the boot order followed
> by guest reboot and power cycle (1.c).
> 
> (1.a) Here it shows the default initial Boot order
> 
> 
>  [Bds]OsIndication: 0000000000000000^M
>  [Bds]=============Begin Load Options Dumping ...=============^M
>    Driver Options:^M
>    SysPrep Options:^M
>    Boot Options:^M
>      Boot0000: UiApp              0x0109^M
>      Boot0001: UEFI QEMU DVD-ROM QM00005                  0x0001^M
>      Boot0002: UEFI PXEv4 (MAC:506B8D83F4DB)              0x0001^M
>      Boot0003: EFI Internal Shell                 0x0001^M
>    PlatformRecovery Options:^M
>      PlatformRecovery0000: Default PlatformRecovery               0x0001^M
>  [Bds]=============End Load Options Dumping=============^M
>  [Bds]BdsWait ...Zzzzzzzzzzzz...^M
>  [Bds]Exit the waiting!^M
>  ValidateSetVariable - Variable
> (8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootCurrent) returning Success.^M
> 
> 
> (1.b) Changed the order from 1->2->3 to 1->3->2 from the UEFI Boot
> Manager Menu. To verify whether the Boot order has actually changed or
> not after saving the Boot order from uefi GUI, added some debug
> statments
> after https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L614 <https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L614>.
> 
> 
>   DEBUG((EFI_D_INFO, "Printing the boot Order here.\n"));
> 
>   for (Index = 0; Index < BootOrderSize / sizeof (UINT16); Index++) {
> 
>     DEBUG ((
> 
>       EFI_D_INFO, "  BootOption %u: %04x\n",
> 
>       Index,
> 
>       BootOrder[Index]
> 
>       ));
> 
>   }
> 
> 
> And the log files printed the changed Boot order, below and that
> confirmed that the modified Boot Order has been
> set https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L624 <https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L624>.
> 
>  Printing the boot Order here.^M
>    BootOption 0: 0001^M
>    BootOption 1: 0003^M
>    BootOption 2: 0002^M
>    BootOption 3: 0000^M
> 
> 
> (1.c) On Guest reboot followed by power cycle, on reopening the UEFI
> Boot Maintainance Manager GUI, found the Boot Order to fall back to the
> default order. (Attaching a screenshot of the Boot Order as attachment).
> 
> 
> -------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> For testcase2 : attaching the partition made by efi/boot on the guest,
> with a proof that the modified uefi variables are stored in the NvVars file.
> 
> 
> (2.a) On the Guest OS, /boot/efi made a partition of 200MB
> 
> 
> [root@localhost <mailto:root@localhost> ~]$ lsblk -l
> 
> NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> 
> sda       8:0    0   12G  0 disk
> 
> sda1      8:1    0  200M  0 part /boot/efi
> 
> sda2      8:2    0    1G  0 part /boot
> 
> sda3      8:3    0 10.8G  0 part
> 
> cl-root 253:0    0  9.6G  0 lvm  /
> 
> cl-swap 253:1    0  1.2G  0 lvm  [SWAP]
> 
> sr0      11:0    1 1024M  0 rom 
> 
> 
> (2.b) Inside the /boot/efi partition, there is the NvVars file. After
> this, the uefi variables were modified / changed.
> 
> 
> [root@localhost <mailto:root@localhost> ~]$ ls -al /boot/efi
> 
> total 36
> 
> drwx------. 3 root root 16384 Dec 31  1969 .
> 
> dr-xr-xr-x. 5 root root  4096 Oct 23  2019 ..
> 
> drwx------. 4 root root  4096 Oct 23  2019 EFI
> 
> -rwx------. 1 root root 11019 Jun  9 15:51 NvVars 
> 
> 
> (2.c) After guest reboot followed by power cycle, the change in uefi
> variables was persistent. And to verify, where the modified variables
> were stored, we could see the date change in the NvVars file ->
> signifying the latest change in UEFI boot manager menu.
> 
> 
> [root@localhost <mailto:root@localhost> ~]$ ls -la /boot/efi
> 
> total 36
> 
> drwx------. 3 root root 16384 Dec 31  1969 .
> 
> dr-xr-xr-x. 5 root root  4096 Oct 23  2019 ..
> 
> drwx------. 4 root root  4096 Oct 23  2019 EFI
> 
> -rwx------. 1 root root 11019 Jun 12 06:56 NvVars
> 
>  
> 
> [root@localhost <mailto:root@localhost> ~]$ date
> 
> Mon Jun 12 06:58:13 EDT 2023 
> 
> 
> Thanks,
> Het Gala
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108419): https://edk2.groups.io/g/devel/message/108419
Mute This Topic: https://groups.io/mt/101223763/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-