path: root/Lessons_uncategorized/Lesson_NV_storage/README.md

In this lesson we are going to look how non-volatile variables are stored in the flash image.

Let's remember the `[FD.OVMF]` image structure from the [https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf](https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf):
```
[FD.OVMF]
BaseAddress   = $(FW_BASE_ADDRESS)
Size          = $(FW_SIZE)
ErasePolarity = 1
BlockSize     = $(BLOCK_SIZE)
NumBlocks     = $(FW_BLOCKS)

!include VarStore.fdf.inc

$(VARS_SIZE)|$(FVMAIN_SIZE)
FV = FVMAIN_COMPACT

$(SECFV_OFFSET)|$(SECFV_SIZE)
FV = SECFV
```

The variable storage is declared inside the `VarStore.fdf.inc` file, so let's look into it [https://github.com/tianocore/edk2/blob/master/OvmfPkg/VarStore.fdf.inc](https://github.com/tianocore/edk2/blob/master/OvmfPkg/VarStore.fdf.inc).

As in our case the flash size is 4MB, the define `FD_SIZE_IN_KB` is equal to 4096. Therefore the file content can be simplified to:
```
0x00000000|0x00040000

#NV_VARIABLE_STORE
DATA = {
  ## This is the EFI_FIRMWARE_VOLUME_HEADER                             <----- EFI_FIRMWARE_VOLUME_HEADER
  # ZeroVector []
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  # FileSystemGuid: gEfiSystemNvDataFvGuid         =
  #   { 0xFFF12B8D, 0x7696, 0x4C8B,
  #     { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }}
  0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
  0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
  # FvLength: 0x84000							<----- All Content: EFI_FIRMWARE_VOLUME_HEADER + NV_VARIABLE_STORE + NV_EVENT_LOG + NV_FTW_WORKING + NV_FTW_SPARE
  0x00, 0x40, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00,
  # Signature "_FVH"       # Attributes
  0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00,
  # HeaderLength
  0x48, 0x00,
  # CheckSum
  0xAF, 0xB8,
  # ExtHeaderOffset #Reserved #Revision
  0x00, 0x00, 0x00, 0x02,
  # Blockmap[0]: 0x84 Blocks * 0x1000 Bytes / Block			<------ 0x84 Blocks * 0x1000 Bytes / Block
  0x84, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
  # Blockmap[1]: End
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  ## This is the VARIABLE_STORE_HEADER					<------ VARIABLE_STORE_HEADER
  # It is compatible with SECURE_BOOT_ENABLE == FALSE as well.
  # Signature: gEfiAuthenticatedVariableGuid =
  #   { 0xaaf32c78, 0x947b, 0x439a,
  #     { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 }}
  0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
  0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
  # Size: 0x40000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
  #          0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x3ffb8
  # This can speed up the Variable Dispatch a bit.
  0xB8, 0xFF, 0x03, 0x00,
  # FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
  0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}

0x00040000|0x00001000
#NV_EVENT_LOG

0x00041000|0x00001000
#NV_FTW_WORKING
DATA = {
  # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid         =
  #  { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
  0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
  0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95,
  # Crc:UINT32            #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
  0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
  # WriteQueueSize: UINT64
  0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}

0x00042000|0x00042000
#NV_FTW_SPARE
```

On a high level this file declares 4 regions:
```
0x00000000..0x00040000 # NV_VARIABLE_STORE
0x00040000..0x00041000 # NV_EVENT_LOG
0x00041000..0x00042000 # NV_FTW_WORKING
0x00042000..0x00084000 # NV_FTW_SPARE
```

In this lesson we are interested in the first region `NV_VARIABLE_STORE` as this region is used as a variable storage in our image.

But as you can see the `NV_VARIABLE_STORE` region data actually starts not from the variable storage itself. At the beggining there is a Firmware Volume header (`EFI_FIRMWARE_VOLUME_HEADER`) for all 4 regions which is filled manually via the hardcoded `DATA` array.

In case you don't remember here is a description for the `EFI_FIRMWARE_VOLUME_HEADER` [https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h](https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h):
```
typedef struct {
  UINT8                     ZeroVector[16];
  EFI_GUID                  FileSystemGuid;	// Declares the file system with which the firmware volume is formatted
  UINT64                    FvLength;		// Length in bytes of the complete firmware volume, including the header
  UINT32                    Signature;		// [#define EFI_FVH_SIGNATURE  SIGNATURE_32 ('_', 'F', 'V', 'H')]
  EFI_FVB_ATTRIBUTES_2      Attributes;		// Declares capabilities and power-on defaults for the firmware volume
  UINT16                    HeaderLength;	// Length in bytes of the complete firmware volume header
  UINT16                    Checksum;		// A 16-bit checksum of the firmware volume header. A valid header sums to zero
  UINT16                    ExtHeaderOffset;	// Offset to the extended header (EFI_FIRMWARE_VOLUME_EXT_HEADER) or zero if there is no extended header
  UINT8                     Reserved[1];	// This field must always be set to zero
  UINT8                     Revision;		// [#define EFI_FVH_REVISION  0x02]
  EFI_FV_BLOCK_MAP_ENTRY    BlockMap[1];	// An array of run-length encoded FvBlockMapEntry structures. The array is terminated with an entry of {0,0}
} EFI_FIRMWARE_VOLUME_HEADER;
```

We can even check this header with the `VolInfo` utility. As you know the `OVMF_VARS.fd` image is just a `VarStore.fdf.inc` that we are currently discussing:
```
[FD.OVMF_VARS]
BaseAddress   = $(FW_BASE_ADDRESS)
Size          = $(VARS_SIZE)
ErasePolarity = 1
BlockSize     = $(BLOCK_SIZE)
NumBlocks     = $(VARS_BLOCKS)

!include VarStore.fdf.inc
```

So let's use the `VolInfo` on this image.

First rebuild `OVMF` image to clear all the current NV content:
```
$ build --platform=OvmfPkg/OvmfPkgX64.dsc --arch=X64 --buildtarget=RELEASE --tagname=GCC5
```

Now use `VolInfo` on the `OVMF_VARS.fd` file:
```
$ VolInfo Build/OvmfX64/RELEASE_GCC5/FV/OVMF_VARS.fd

VolInfo Version 1.0 Build Developer Build based on Revision: Unknown
Signature:        _FVH (4856465F)
Attributes:       4FEFF
       EFI_FVB2_READ_DISABLED_CAP
       EFI_FVB2_READ_ENABLED_CAP
       EFI_FVB2_READ_STATUS
       EFI_FVB2_WRITE_DISABLED_CAP
       EFI_FVB2_WRITE_ENABLED_CAP
       EFI_FVB2_WRITE_STATUS
       EFI_FVB2_LOCK_CAP
       EFI_FVB2_LOCK_STATUS
       EFI_FVB2_STICKY_WRITE
       EFI_FVB2_MEMORY_MAPPED
       EFI_FVB2_ERASE_POLARITY
       EFI_FVB2_READ_LOCK_CAP
       EFI_FVB2_READ_LOCK_STATUS
       EFI_FVB2_WRITE_LOCK_CAP
       EFI_FVB2_WRITE_LOCK_STATUS
       EFI_FVB2_ALIGNMENT_16
Header Length:         0x00000048
File System ID:        fff12b8d-7696-4c8b-a985-2747075b4f50
Revision:              0x0002
Number of Blocks:      0x00000084
Block Length:          0x00001000
Total Volume Size:     0x00084000
VolInfo: ERROR 0003: error parsing FV image
  cannot find the first file in the FV image
```

Here you can see how `VolInfo` was able to parse the Firmware Volume header. `VolInfo` wasn't able to parse the FV content, as it is not the usual FFS files, but a custom data.

So let's invetigate this data ourself. First there is the `VARIABLE_STORE_HEADER` [https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Guid/VariableFormat.h](https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Guid/VariableFormat.h):
```cpp
typedef struct {
  EFI_GUID    Signature;	// Variable store region signature
  UINT32      Size;		// Size of entire variable store, including size of variable store header but not including the size of FvHeader
  UINT8       Format;		// Variable region format state
  UINT8       State;		// Variable region healthy state
  UINT16      Reserved;
  UINT32      Reserved1;
} VARIABLE_STORE_HEADER;
```

It uses `gEfiAuthenticatedVariableGuid` GUID for the `Signature` field which is declared in the same file:
```cpp
#define EFI_AUTHENTICATED_VARIABLE_GUID \
  { 0xaaf32c78, 0x947b, 0x439a, { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 } }
extern EFI_GUID  gEfiAuthenticatedVariableGuid;
```

Right after the variable storage header there is an array of actual variable records. In our case each record actual variable data is prepended with a `AUTHENTICATED_VARIABLE_HEADER`:
```cpp
///
/// Single Authenticated Variable Data Header Structure.
///
typedef struct {
  UINT16      StartId;			// Variable Data Start Flag
  UINT8       State;			// Variable State defined above
  UINT8       Reserved;
  UINT32      Attributes;		// Attributes of variable defined in UEFI specification
  UINT64      MonotonicCount;		// Associated monotonic count value against replay attack
  EFI_TIME    TimeStamp;		// Associated TimeStamp value against replay attack
  UINT32      PubKeyIndex;		// Index of associated public key in database
  UINT32      NameSize;			// Size of variable null-terminated Unicode string name
  UINT32      DataSize;			// Size of the variable data without this header
  EFI_GUID    VendorGuid;		// A unique identifier for the vendor that produces and consumes this varaible
} AUTHENTICATED_VARIABLE_HEADER;
```

The `StartId` field in this structure contains a marker for the header:
```cpp
///
/// Variable data start flag.
///
#define VARIABLE_DATA  0x55AA
```

So it is easy to see when one variable ends and another one starts. We will need it later.

But if you look at the `OVMF_VARS.fd` right now you wouldn't see any variables:
```
$ hexdump -C Build/OvmfX64/RELEASE_GCC5/FV/OVMF_VARS.fd
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  8d 2b f1 ff 96 76 8b 4c  a9 85 27 47 07 5b 4f 50  |.+...v.L..'G.[OP|
00000020  00 40 08 00 00 00 00 00  5f 46 56 48 ff fe 04 00  |.@......_FVH....|
00000030  48 00 af b8 00 00 00 02  84 00 00 00 00 10 00 00  |H...............|
00000040  00 00 00 00 00 00 00 00  78 2c f3 aa 7b 94 9a 43  |........x,..{..C|
00000050  a1 80 2e 14 4e c3 77 92  b8 ff 03 00 5a fe 00 00  |....N.w.....Z...|
00000060  00 00 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00041000  2b 29 58 9e 68 7c 7d 49  a0 ce 65 00 fd 9f 1b 95  |+)X.h|}I..e.....|
00041010  2c af 2c 64 fe ff ff ff  e0 0f 00 00 00 00 00 00  |,.,d............|
00041020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00084000
```

The same goes to the `OVMF.fd` image if you have any doubts:
```
$ hexdump -C Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd | head -n 12
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  8d 2b f1 ff 96 76 8b 4c  a9 85 27 47 07 5b 4f 50  |.+...v.L..'G.[OP|
00000020  00 40 08 00 00 00 00 00  5f 46 56 48 ff fe 04 00  |.@......_FVH....|
00000030  48 00 af b8 00 00 00 02  84 00 00 00 00 10 00 00  |H...............|
00000040  00 00 00 00 00 00 00 00  78 2c f3 aa 7b 94 9a 43  |........x,..{..C|
00000050  a1 80 2e 14 4e c3 77 92  b8 ff 03 00 5a fe 00 00  |....N.w.....Z...|
00000060  00 00 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00041000  2b 29 58 9e 68 7c 7d 49  a0 ce 65 00 fd 9f 1b 95  |+)X.h|}I..e.....|
00041010  2c af 2c 64 fe ff ff ff  e0 0f 00 00 00 00 00 00  |,.,d............|
00041020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00084000  ...
```

This is because there is no NVRAM variables right after the re-build.

Now let's run QEMU for the first time with `OVMF.fd` image:
```
$ qemu-system-x86_64  \
  -drive if=pflash,format=raw,file=Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd \
  -drive format=raw,file=fat:rw:~/UEFI_disk \
  -net none \
  -nographic
```

You can verify that there are a lot of UEFI Variables in the system via the `dmpstore` command:
```
Shell> dmpstore -all
...
```

All these variables were actually created on the OVMF execution.

And you can actually see the NV storage with `dmem`, as the flash chip is mapped to the `0xffc00000` address (=(4GB-4MB)). See the `DEFINE FW_BASE_ADDRESS = 0xFFC00000` in the [https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgDefines.fdf.inc](https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgDefines.fdf.inc):
```
Shell> dmem 0xffc00000 150
Memory Address 00000000FFC00000 150 Bytes
  FFC00000: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FFC00010: 8D 2B F1 FF 96 76 8B 4C-A9 85 27 47 07 5B 4F 50  *.+...v.L..'G.[OP*
  FFC00020: 00 40 08 00 00 00 00 00-5F 46 56 48 FF FE 04 00  *.@......_FVH....*     <---- _FVH  (EFI_FVH_SIGNATURE)
  FFC00030: 48 00 AF B8 00 00 00 02-84 00 00 00 00 10 00 00  *H...............*
  FFC00040: 00 00 00 00 00 00 00 00-78 2C F3 AA 7B 94 9A 43  *........x,..{..C*
  FFC00050: A1 80 2E 14 4E C3 77 92-B8 FF 03 00 5A FE 00 00  *....N.w.....Z...*
  FFC00060: 00 00 00 00 AA 55 3F 00-07 00 00 00 00 00 00 00  *.....U?.........*
  FFC00070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FFC00080: 00 00 00 00 00 00 00 00-08 00 00 00 04 00 00 00  *................*
  FFC00090: 11 40 70 EB 02 14 D3 11-8E 77 00 A0 C9 69 72 3B  *.@p......w...ir;*
  FFC000A0: 4D 00 54 00 43 00 00 00-01 00 00 00 AA 55 3C 00  *M.T.C........U<.*
  FFC000B0: 03 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FFC000C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FFC000D0: 28 00 00 00 01 00 00 00-16 D6 47 4B D6 A8 52 45  *(.........GK..RE*
  FFC000E0: 9D 44 CC AD 2E 0F 4C F9-49 00 6E 00 69 00 74 00  *.D....L.I.n.i.t.*
  FFC000F0: 69 00 61 00 6C 00 41 00-74 00 74 00 65 00 6D 00  *i.a.l.A.t.t.e.m.*
  FFC00100: 70 00 74 00 4F 00 72 00-64 00 65 00 72 00 00 00  *p.t.O.r.d.e.r...*
  FFC00110: 01 FF FF FF AA 55 3F 00-03 00 00 00 00 00 00 00  *.....U?.........*
  FFC00120: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FFC00130: 00 00 00 00 00 00 00 00-14 00 00 00 19 04 00 00  *................*
  FFC00140: 45 49 32 59 44 EC 0D 4C-B1 CD 9D B1 39 DF 07 0C  *EI2YD..L....9...*
```

Now finish QEMU and look at the `OVMF.fd` content:
```
$ hexdump -C Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd | head -n 30
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  8d 2b f1 ff 96 76 8b 4c  a9 85 27 47 07 5b 4f 50  |.+...v.L..'G.[OP|
00000020  00 40 08 00 00 00 00 00  5f 46 56 48 ff fe 04 00  |.@......_FVH....|
00000030  48 00 af b8 00 00 00 02  84 00 00 00 00 10 00 00  |H...............|
00000040  00 00 00 00 00 00 00 00  78 2c f3 aa 7b 94 9a 43  |........x,..{..C|
00000050  a1 80 2e 14 4e c3 77 92  b8 ff 03 00 5a fe 00 00  |....N.w.....Z...|
00000060  00 00 00 00 aa 55 3f 00  07 00 00 00 00 00 00 00  |.....U?.........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  08 00 00 00 04 00 00 00  |................|
00000090  11 40 70 eb 02 14 d3 11  8e 77 00 a0 c9 69 72 3b  |.@p......w...ir;|
000000a0  4d 00 54 00 43 00 00 00  01 00 00 00 aa 55 3c 00  |M.T.C........U<.|
000000b0  03 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  28 00 00 00 01 00 00 00  16 d6 47 4b d6 a8 52 45  |(.........GK..RE|
000000e0  9d 44 cc ad 2e 0f 4c f9  49 00 6e 00 69 00 74 00  |.D....L.I.n.i.t.|
000000f0  69 00 61 00 6c 00 41 00  74 00 74 00 65 00 6d 00  |i.a.l.A.t.t.e.m.|
00000100  70 00 74 00 4f 00 72 00  64 00 65 00 72 00 00 00  |p.t.O.r.d.e.r...|
00000110  01 ff ff ff aa 55 3f 00  03 00 00 00 00 00 00 00  |.....U?.........|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  14 00 00 00 19 04 00 00  |................|
00000140  45 49 32 59 44 ec 0d 4c  b1 cd 9d b1 39 df 07 0c  |EI2YD..L....9...|
00000150  41 00 74 00 74 00 65 00  6d 00 70 00 74 00 20 00  |A.t.t.e.m.p.t. .|
00000160  31 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |1...............|
00000170  00 00 00 00 00 01 00 00  00 00 00 00 00 00 41 74  |..............At|
00000180  74 65 6d 70 74 20 31 00  00 00 00 00 00 00 00 00  |tempt 1.........|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000210  00 00 00 00 00 00 00 00  00 00 bc 0c 00 00 00 00  |................|
00000220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
```

You can see that is has changed. Now the variable storage contains NV variables.

`UEFITool` utility is able to parse NV storages [https://github.com/LongSoft/UEFITool](https://github.com/LongSoft/UEFITool). Load the `OVMF.fd` file to the `UEFITool` program. Here you can see that firmware indeed starts from the Firmware Volume with the `gEfiSystemNvDataFvGuid`:
![1](1.png?raw=true "1")

If you unravel the variable storage, you could see that the storage is filled with `Invalid` entries:
![2](2.png?raw=true "2")

What is that?

Let's re-launch QEMU for the second time. This would update `OVMF.fd` image. If you load the updated image to the tool you could see that now `EfiMtcGuid` that was in the first variable record now changed to `Invalid`:
![3](3.png?raw=true "3")

Although you can find it in the end of the storage:
![4](4.png?raw=true "4")

So what is happening here? If you execute `hexdump` on the start of the `OVMF.fd` image again there wouldn't be any much difference. It looks like the record for `MTC` variable is present:
```
$ hexdump -C Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd | head -n 30
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  8d 2b f1 ff 96 76 8b 4c  a9 85 27 47 07 5b 4f 50  |.+...v.L..'G.[OP|
00000020  00 40 08 00 00 00 00 00  5f 46 56 48 ff fe 04 00  |.@......_FVH....|
00000030  48 00 af b8 00 00 00 02  84 00 00 00 00 10 00 00  |H...............|
00000040  00 00 00 00 00 00 00 00  78 2c f3 aa 7b 94 9a 43  |........x,..{..C|
00000050  a1 80 2e 14 4e c3 77 92  b8 ff 03 00 5a fe 00 00  |....N.w.....Z...|
00000060  00 00 00 00 aa 55 3c 00  07 00 00 00 00 00 00 00  |.....U<.........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  08 00 00 00 04 00 00 00  |................|
00000090  11 40 70 eb 02 14 d3 11  8e 77 00 a0 c9 69 72 3b  |.@p......w...ir;|
000000a0  4d 00 54 00 43 00 00 00  01 00 00 00 aa 55 3c 00  |M.T.C........U<.|           <----- MTC
000000b0  03 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  28 00 00 00 01 00 00 00  16 d6 47 4b d6 a8 52 45  |(.........GK..RE|
000000e0  9d 44 cc ad 2e 0f 4c f9  49 00 6e 00 69 00 74 00  |.D....L.I.n.i.t.|
000000f0  69 00 61 00 6c 00 41 00  74 00 74 00 65 00 6d 00  |i.a.l.A.t.t.e.m.|
00000100  70 00 74 00 4f 00 72 00  64 00 65 00 72 00 00 00  |p.t.O.r.d.e.r...|
00000110  01 ff ff ff aa 55 3f 00  03 00 00 00 00 00 00 00  |.....U?.........|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  14 00 00 00 19 04 00 00  |................|
00000140  45 49 32 59 44 ec 0d 4c  b1 cd 9d b1 39 df 07 0c  |EI2YD..L....9...|
00000150  41 00 74 00 74 00 65 00  6d 00 70 00 74 00 20 00  |A.t.t.e.m.p.t. .|
00000160  31 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |1...............|
00000170  00 00 00 00 00 01 00 00  00 00 00 00 00 00 41 74  |..............At|
00000180  74 65 6d 70 74 20 31 00  00 00 00 00 00 00 00 00  |tempt 1.........|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000210  00 00 00 00 00 00 00 00  00 00 bc 0c 00 00 00 00  |................|
00000220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
```

Although one bit was changed. Let's see it. As we already know, the variable records start with the `0x55AA` (`VARIABLE_DATA`) marker. So let's cut data for this first record in the NV storage, the record which once was `MTC` variable.

Before (working):
```
00000060              aa 55 3f 00  07 00 00 00 00 00 00 00  |.....U?.........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  08 00 00 00 04 00 00 00  |................|
00000090  11 40 70 eb 02 14 d3 11  8e 77 00 a0 c9 69 72 3b  |.@p......w...ir;|
000000a0  4d 00 54 00 43 00 00 00  01 00 00 00              |M.T.C.......    |
```
After (invalid):
```
00000060              aa 55 3c 00  07 00 00 00 00 00 00 00  |.....U<.........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  08 00 00 00 04 00 00 00  |................|
00000090  11 40 70 eb 02 14 d3 11  8e 77 00 a0 c9 69 72 3b  |.@p......w...ir;|
000000a0  4d 00 54 00 43 00 00 00  01 00 00 00              |M.T.C........U<.|
```

The only difference is a change for the `AUTHENTICATED_VARIABLE_HEADER.State` field from `0x3f` to `0x3c`.

In the [https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Guid/VariableFormat.h](https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Guid/VariableFormat.h) file there are some descriptions for the State field flags:
```cpp
//
/// Variable State flags.
///
#define VAR_IN_DELETED_TRANSITION  0xfe     ///< Variable is in obsolete transition.
#define VAR_DELETED                0xfd     ///< Variable is obsolete.
#define VAR_HEADER_VALID_ONLY      0x7f     ///< Variable header has been valid.
#define VAR_ADDED                  0x3f     ///< Variable has been completely added.
```

With this terminology the `0x3f` value is (`VAR_ADDED`) and the `0x3c` value is (`VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED)`. So our `MTC` variable was deleted and then created in another record at the end of the table.

Why?

In the real scenario the NV variables are stored in a physical flash chip. And this puts some limitations for the NV variable driver. For example it is not possible to erase random bytes of data, as you are only able to erase data in blocks for a flash chip (and a block can be pretty big, for example 1024 bytes). So to change one variable record you would have to delete and recreate a bunch of data.

Also there is a wear-leveling issue. Flash chips have a limited count of block erase operations. Around that time (or even earlier) the block erase wouldn't be completed successfully, so you can't use this block for your data no more. So if some variable changes often, modifying it in-place would wear-level flash chip pretty quickly.

Important conclusion is that it is better to append new records to the end of a storage, than change current records. And this is what we've observed.

Also after the block erase operation in a flash chip all bytes in that block are set to 0xFF (all 1's). The write operation is able to set bits from 1's to 0's (and not in the opposite way!). This is why it is possible to change `0x3f` value (`VAR_ADDED`) to `0x3c` value (`VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED)` without any block erase operation.

# `SetVariableExample` test

For another test let's use our `SetVariableExample` application that we've created earlier.

As a control method let's use `UEFIExtract` utility from the same UEFITool repo [https://github.com/LongSoft/UEFITool](https://github.com/LongSoft/UEFITool). The `UEFIExtract` is a command-line utility, therefore it is easier to use it from CLI:
```
$ ./UEFIExtract
UEFIExtract NE alpha 60 (Aug 27 2022)

Usage: UEFIExtract imagefile        - generate report and dump only leaf tree items into .dump folder.
       UEFIExtract imagefile all    - generate report and dump all tree items.
       UEFIExtract imagefile unpack - generate report and dump all tree items in one dir.
       UEFIExtract imagefile dump   - only generate dump, no report needed.
       UEFIExtract imagefile report - only generate report, no dump needed.
       UEFIExtract imagefile GUID_1 ... [ -o FILE_1 ... ] [ -m MODE_1 ... ] [ -t TYPE_1 ... ] -
         Dump only FFS file(s) with specific GUID(s), without report.
         Type is section type or FF to ignore. Mode is one of: all, body, header, info, file.
Return value is a bit mask where 0 at position N means that file with GUID_N was found and unpacked, 1 otherwise.
```

In our test we would be checking `report` command output. Copy current `OVMF.fd` image, generate report for it and check the result. In the output below I've included only the NV storage part of the output:
```
$ cp <...>/edk2/Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd ./
$ ./UEFIExtract OVMF.fd report
$ cat OVMF.fd.report.txt
      Type       |        Subtype        |   Base   |   Size   |  CRC32   |   Name
 Image           | UEFI                  | 00000000 | 00400000 | 90EAAFFF |  UEFI image
 Volume          | NVRAM                 | 00000000 | 00084000 | 393BD56A | - FFF12B8D-7696-4C8B-A985-2747075B4F50
 VSS2 store      |                       | 00000048 | 0003FFB8 | E9A424DE | -- VSS2 store
 VSS entry       | Invalid               | 00000064 | 00000048 | 0B1B3B2A | --- Invalid
 VSS entry       | Invalid               | 000000AC | 00000065 | 43FDF85A | --- Invalid
 VSS entry       | Auth                  | 00000114 | 00000469 | 0E8A7CD5 | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 1
 VSS entry       | Invalid               | 00000580 | 00000066 | B6ACED62 | --- Invalid
 VSS entry       | Auth                  | 000005E8 | 00000469 | 002D804B | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 2
 VSS entry       | Invalid               | 00000A54 | 00000067 | B8B27872 | --- Invalid
 VSS entry       | Auth                  | 00000ABC | 00000469 | B36029FE | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 3
 VSS entry       | Invalid               | 00000F28 | 00000068 | 70B54595 | --- Invalid
 VSS entry       | Auth                  | 00000F90 | 00000469 | 1D627977 | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 4
 VSS entry       | Invalid               | 000013FC | 00000069 | A2979B6A | --- Invalid
 VSS entry       | Auth                  | 00001468 | 00000469 | AE2FD0C2 | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 5
 VSS entry       | Invalid               | 000018D4 | 0000006A | 4C9EA244 | --- Invalid
 VSS entry       | Auth                  | 00001940 | 00000469 | A0882C5C | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 6
 VSS entry       | Invalid               | 00001DAC | 0000006B | B0DA855D | --- Invalid
 VSS entry       | Auth                  | 00001E18 | 00000469 | 13C585E9 | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 7
 VSS entry       | Auth                  | 00002284 | 0000006C | 27A057BF | --- 4B47D616-A8D6-4552-9D44-CCAD2E0F4CF9 | InitialAttemptOrder
 VSS entry       | Auth                  | 000022F0 | 00000469 | 27FD8B0F | --- 59324945-EC44-4C0D-B1CD-9DB139DF070C | Attempt 8
 VSS entry       | Invalid               | 0000275C | 00000052 | D508D27E | --- Invalid
 VSS entry       | Auth                  | 000027B0 | 0000008C | 3D8F8004 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Boot0000
 VSS entry       | Auth                  | 0000283C | 0000004E | C451514A | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Timeout
 VSS entry       | Auth                  | 0000288C | 00000059 | A16D4B75 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | PlatformLang
 VSS entry       | Auth                  | 000028E8 | 0000004A | A8279A0B | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Lang
 VSS entry       | Auth                  | 00002934 | 00000057 | 66192BDE | --- 04B37FE8-F6AE-480B-BDD5-37D98C5E89AA | VarErrorFlag
 VSS entry       | Invalid               | 0000298C | 0000006A | BEDF0159 | --- Invalid
 VSS entry       | Invalid               | 000029F8 | 00000093 | 133B4E89 | --- Invalid
 VSS entry       | Invalid               | 00002A8C | 000000B3 | 2770C13D | --- Invalid
 VSS entry       | Invalid               | 00002B40 | 00000093 | C5BEF246 | --- Invalid
 VSS entry       | Invalid               | 00002BD4 | 000000DC | 94308B4F | --- Invalid
 VSS entry       | Invalid               | 00002CB0 | 000000FC | 62B4896C | --- Invalid
 VSS entry       | Invalid               | 00002DAC | 000000DC | A2F145DC | --- Invalid
 VSS entry       | Invalid               | 00002E88 | 000000FA | 87389AFC | --- Invalid
 VSS entry       | Invalid               | 00002F84 | 0000013B | 3039AE62 | --- Invalid
 VSS entry       | Invalid               | 000030C0 | 00000139 | 76E1A61F | --- Invalid
 VSS entry       | Invalid               | 000031FC | 0000011B | 82C266DE | --- Invalid
 VSS entry       | Invalid               | 00003318 | 0000014A | FDC1C84F | --- Invalid
 VSS entry       | Invalid               | 00003464 | 00000159 | 5B9AE227 | --- Invalid
 VSS entry       | Auth                  | 000035C0 | 0000005A | 7DB8CD95 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Key0000
 VSS entry       | Auth                  | 0000361C | 0000005A | 15F2ABEA | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Key0001
 VSS entry       | Invalid               | 00003678 | 00000110 | 1C10333C | --- Invalid
 VSS entry       | Invalid               | 00003788 | 000000D1 | 40EA30C6 | --- Invalid
 VSS entry       | Invalid               | 0000385C | 000000B1 | 1C806E85 | --- Invalid
 VSS entry       | Invalid               | 00003910 | 00000101 | 7CAC293B | --- Invalid
 VSS entry       | Invalid               | 00003A14 | 000000C2 | B7FD38BC | --- Invalid
 VSS entry       | Invalid               | 00003AD8 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Invalid               | 00003BAC | 00000093 | C5BEF246 | --- Invalid
 VSS entry       | Invalid               | 00003C40 | 00000054 | 7D53807A | --- Invalid
 VSS entry       | Auth                  | 00003C94 | 000000B8 | 7F33223C | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Boot0001
 VSS entry       | Invalid               | 00003D4C | 00000056 | B4142854 | --- Invalid
 VSS entry       | Auth                  | 00003DA4 | 000000BA | 9C2980E3 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Boot0002
 VSS entry       | Auth                  | 00003E60 | 00000058 | 4E619F14 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | BootOrder
 VSS entry       | Auth                  | 00003EB8 | 000000A6 | C30DAC1A | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | Boot0003
 VSS entry       | Auth                  | 00003F60 | 00000098 | 0B4D15F8 | --- 4C19049F-4137-4DD3-9C10-8B97A83FFDFA | MemoryTypeInformation
 VSS entry       | Auth                  | 00003FF8 | 00000048 | F204DC79 | --- EB704011-1402-11D3-8E77-00A0C969723B | MTC
 VSS entry       | Invalid               | 00004040 | 000000FA | 7B7FE195 | --- Invalid
 VSS entry       | Invalid               | 0000413C | 0000010B | 44135AC8 | --- Invalid
 VSS entry       | Invalid               | 00004248 | 000000DC | A2F145DC | --- Invalid
 VSS entry       | Invalid               | 00004324 | 0000014A | 5F63563F | --- Invalid
 VSS entry       | Invalid               | 00004470 | 00000139 | 33BCF69E | --- Invalid
 VSS entry       | Invalid               | 000045AC | 0000011B | 82C266DE | --- Invalid
 VSS entry       | Invalid               | 000046C8 | 00000159 | 7E8D1B57 | --- Invalid
 VSS entry       | Invalid               | 00004824 | 00000110 | 1C10333C | --- Invalid
 VSS entry       | Invalid               | 00004934 | 000000D1 | 40EA30C6 | --- Invalid
 VSS entry       | Auth                  | 00004A08 | 000000B1 | 3E31A587 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConOut
 VSS entry       | Invalid               | 00004ABC | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Auth                  | 00004BC0 | 000000C2 | 5C48AE3F | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConIn
 VSS entry       | Invalid               | 00004C84 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Auth                  | 00004D58 | 00000093 | 2D6DFF61 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ErrOut
 Free space      |                       | 00004DEC | 0003B214 | 8BE00E0B | --- Free space
 Padding         | Empty (0xFF)          | 00040000 | 00001000 | F154670A | -- Padding
 FTW store       |                       | 00041000 | 00001000 | FE3E7280 | -- FTW store
 Free space      |                       | 00042000 | 00042000 | 4BC9AB8D | -- Free space
 Padding         | Non-empty             | 00084000 | 00001000 | 306E7D61 | - Padding
<...>
```

Now let's boot `OVMF.fd` and use our `SetVariableExample.efi` program:
```
FS0:\> SetVariableExample.efi
Delete variable
   SetVariableExample <variable name>

Set variable
   SetVariableExample <variable name> <attributes> <value>

<attributes> can be <n|b|r>
n - NON_VOLATILE
b - BOOTSERVICE_ACCESS
r - RUNTIME_ACCESS
```

Create new non-volatile variable with it:
```
FS0:\> SetVariableExample.efi TestVariable nbr "Test string 1"
Variable TestVariable was successfully changed
```

Not closing QEMU, copy the updated `OVMF.fd` file to the `UEFIExtract` folder and check it for the `TestVariable` string like this:
```
$ cp <...>/edk2/Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd ./ && ./UEFIExtract ./OVMF.fd report && grep TestVariable OVMF.fd.report.txt -A 3 -B 8
 VSS entry       | Invalid               | 000054BC | 00000159 | 7E8D1B57 | --- Invalid
 VSS entry       | Invalid               | 00005618 | 00000110 | 1C10333C | --- Invalid
 VSS entry       | Invalid               | 00005728 | 000000D1 | 40EA30C6 | --- Invalid
 VSS entry       | Auth                  | 000057FC | 000000B1 | 3E31A587 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConOut
 VSS entry       | Invalid               | 000058B0 | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Auth                  | 000059B4 | 000000C2 | 5C48AE3F | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConIn
 VSS entry       | Invalid               | 00005A78 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Auth                  | 00005B4C | 00000093 | 2D6DFF61 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ErrOut
 VSS entry       | Auth                  | 00005BE0 | 00000072 | 8B20882D | --- BB2A829F-7943-4691-A03A-F1F48519D7E6 | TestVariable
 Free space      |                       | 00005C54 | 0003A3AC | D7ACFF21 | --- Free space
 Padding         | Empty (0xFF)          | 00040000 | 00001000 | F154670A | -- Padding
 FTW store       |                       | 00041000 | 00001000 | FE3E7280 | -- FTW store
```

So our variable `TestVariable` was created right at the end of the NV storage.

Now modify variable content with `SetVariableExample` application. In case you don't remember, for that our application simply uses the same `gRT->SetVariable` call:
```
FS0:\> SetVariableExample.efi TestVariable nbr "Test string 2"
Variable TestVariable was successfully changed
```

Look at the NV storage again:
```
$ cp <...>/edk2/Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd ./ && ./UEFIExtract ./OVMF.fd report && grep TestVariable OVMF.fd.report.txt -A 3 -B 8
 VSS entry       | Invalid               | 00005618 | 00000110 | 1C10333C | --- Invalid
 VSS entry       | Invalid               | 00005728 | 000000D1 | 40EA30C6 | --- Invalid
 VSS entry       | Auth                  | 000057FC | 000000B1 | 3E31A587 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConOut
 VSS entry       | Invalid               | 000058B0 | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Auth                  | 000059B4 | 000000C2 | 5C48AE3F | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConIn
 VSS entry       | Invalid               | 00005A78 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Auth                  | 00005B4C | 00000093 | 2D6DFF61 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ErrOut
 VSS entry       | Invalid               | 00005BE0 | 00000072 | D928D86C | --- Invalid
 VSS entry       | Auth                  | 00005C54 | 00000072 | 999527C3 | --- BB2A829F-7943-4691-A03A-F1F48519D7E6 | TestVariable
 Free space      |                       | 00005CC8 | 0003A338 | FF1116DF | --- Free space
 Padding         | Empty (0xFF)          | 00040000 | 00001000 | F154670A | -- Padding
 FTW store       |                       | 00041000 | 00001000 | FE3E7280 | -- FTW store
```

The record before was invalidated, and the new `TestVariable` record was created after it.

You can repeat the process:
```
FS0:\> SetVariableExample.efi TestVariable nbr "Test string 3"
Variable TestVariable was successfully changed
FS0:\> SetVariableExample.efi TestVariable nbr "Test string 4"
Variable TestVariable was successfully changed
FS0:\> SetVariableExample.efi TestVariable nbr "Test string 5"
Variable TestVariable was successfully changed
```

The behaviour would be the same:
```
$ cp <...>/edk2/Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd ./ && ./UEFIExtract ./OVMF.fd report && grep TestVariable OVMF.fd.report.txt -A 3 -B 8
 VSS entry       | Invalid               | 000058B0 | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Auth                  | 000059B4 | 000000C2 | 5C48AE3F | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConIn
 VSS entry       | Invalid               | 00005A78 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Auth                  | 00005B4C | 00000093 | 2D6DFF61 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ErrOut
 VSS entry       | Invalid               | 00005BE0 | 00000072 | D928D86C | --- Invalid
 VSS entry       | Invalid               | 00005C54 | 00000072 | CB9D7782 | --- Invalid
 VSS entry       | Invalid               | 00005CC8 | 00000072 | 732110E7 | --- Invalid
 VSS entry       | Invalid               | 00005D3C | 00000072 | EEF6285E | --- Invalid
 VSS entry       | Auth                  | 00005DB0 | 00000072 | 04421F7A | --- BB2A829F-7943-4691-A03A-F1F48519D7E6 | TestVariable
 Free space      |                       | 00005E24 | 0003A1DC | B9B6D883 | --- Free space
 Padding         | Empty (0xFF)          | 00040000 | 00001000 | F154670A | -- Padding
 FTW store       |                       | 00041000 | 00001000 | FE3E7280 | -- FTW store
```

Now re-launch QEMU and check the report for the updated `OVMF.fd` file:
```
$ cp ~/tiano/2021/edk2/Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd ./ && ./UEFIExtract ./OVMF.fd report && grep TestVariable OVMF.fd.report.txt -A 20 -B 8
 VSS entry       | Invalid               | 000058B0 | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Invalid               | 000059B4 | 000000C2 | B7FD38BC | --- Invalid
 VSS entry       | Invalid               | 00005A78 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Invalid               | 00005B4C | 00000093 | C5BEF246 | --- Invalid
 VSS entry       | Invalid               | 00005BE0 | 00000072 | D928D86C | --- Invalid
 VSS entry       | Invalid               | 00005C54 | 00000072 | CB9D7782 | --- Invalid
 VSS entry       | Invalid               | 00005CC8 | 00000072 | 732110E7 | --- Invalid
 VSS entry       | Invalid               | 00005D3C | 00000072 | EEF6285E | --- Invalid
 VSS entry       | Auth                  | 00005DB0 | 00000072 | 04421F7A | --- BB2A829F-7943-4691-A03A-F1F48519D7E6 | TestVariable
 VSS entry       | Auth                  | 00005E24 | 00000048 | D76F83A5 | --- EB704011-1402-11D3-8E77-00A0C969723B | MTC
 VSS entry       | Invalid               | 00005E6C | 000000FA | 7B7FE195 | --- Invalid
 VSS entry       | Invalid               | 00005F68 | 0000010B | 44135AC8 | --- Invalid
 VSS entry       | Invalid               | 00006074 | 000000DC | A2F145DC | --- Invalid
 VSS entry       | Invalid               | 00006150 | 0000014A | 5F63563F | --- Invalid
 VSS entry       | Invalid               | 0000629C | 00000139 | 33BCF69E | --- Invalid
 VSS entry       | Invalid               | 000063D8 | 0000011B | 82C266DE | --- Invalid
 VSS entry       | Invalid               | 000064F4 | 00000159 | 7E8D1B57 | --- Invalid
 VSS entry       | Invalid               | 00006650 | 00000110 | 1C10333C | --- Invalid
 VSS entry       | Invalid               | 00006760 | 000000D1 | 40EA30C6 | --- Invalid
 VSS entry       | Auth                  | 00006834 | 000000B1 | 3E31A587 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConOut
 VSS entry       | Invalid               | 000068E8 | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Auth                  | 000069EC | 000000C2 | 5C48AE3F | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConIn
 VSS entry       | Invalid               | 00006AB0 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Auth                  | 00006B84 | 00000093 | 2D6DFF61 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ErrOut
 Free space      |                       | 00006C18 | 000393E8 | 1B524AFE | --- Free space
 Padding         | Empty (0xFF)          | 00040000 | 00001000 | F154670A | -- Padding
 FTW store       |                       | 00041000 | 00001000 | FE3E7280 | -- FTW store
 Free space      |                       | 00042000 | 00042000 | 4BC9AB8D | -- Free space
 Padding         | Non-empty             | 00084000 | 00001000 | 306E7D61 | - Padding
```
From this output you can see that `MTC`/`ConOut`/`ConIn`/`ErrOut` variables are updated on every boot. You can see that new records for them were added to the database. As for the new `Invalid` records they can be:
- some new variables, that were later deleted on boot
- the same `ConOut`/`ConIn`/`ErrOut` variables that were later updated on boot

As `UEFIExtract` tool prints start addresses for the records, we can easily check the `Invalid` records content.

For example to check this record:
```
VSS entry       | Invalid               | 00005E6C | 000000FA | 7B7FE195 | --- Invalid
```
You can use:
```
$ hexdump Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd -s 0x5E6C -n 250 -C
```
(it is not possible to use hex values with the `-n` argument, so I had to convert 0x000000FA to decimal number)

This output would look like this:
```
$ hexdump Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd -s 0x5E6C -n 250 -C
00005e6c  aa 55 3c 00 07 00 00 00  00 00 00 00 00 00 00 00  |.U<.............|
00005e7c  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00005e8c  00 00 00 00 0e 00 00 00  b0 00 00 00 61 df e4 8b  |............a...|
00005e9c  ca 93 d2 11 aa 0d 00 e0  98 03 2b 8c 43 00 6f 00  |..........+.C.o.|         <---- ConOut
00005eac  6e 00 4f 00 75 00 74 00  00 00 02 01 0c 00 d0 41  |n.O.u.t........A|
00005ebc  03 0a 00 00 00 00 01 01  06 00 00 01 02 01 0c 00  |................|
00005ecc  d0 41 01 05 00 00 00 00  03 0e 13 00 00 00 00 00  |.A..............|
00005edc  00 c2 01 00 00 00 00 00  08 01 01 03 0a 14 00 53  |...............S|
00005eec  47 c1 e0 be f9 d2 11 9a  0c 00 90 27 3f c1 4d 7f  |G..........'?.M.|
00005efc  01 04 00 02 01 0c 00 d0  41 03 0a 00 00 00 00 01  |........A.......|
00005f0c  01 06 00 00 02 02 03 08  00 00 01 01 80 7f 01 04  |................|
00005f1c  00 02 01 0c 00 d0 41 03  0a 00 00 00 00 01 01 06  |......A.........|
00005f2c  00 00 01 02 01 0c 00 d0  41 01 05 01 00 00 00 03  |........A.......|
00005f3c  0e 13 00 00 00 00 00 00  c2 01 00 00 00 00 00 08  |................|
00005f4c  01 01 03 0a 14 00 53 47  c1 e0 be f9 d2 11 9a 0c  |......SG........|
00005f5c  00 90 27 3f c1 4d 7f ff  04 00                    |..'?.M....|
00005f66
```
As you can see this record was for the `ConOut` variable.

You can repeat the process for the rest of the `Invalid` records

In my case the situation looked like this:
```
 VSS entry       | Auth                  | 00005DB0 | 00000072 | 04421F7A | --- BB2A829F-7943-4691-A03A-F1F48519D7E6 | TestVariable
 VSS entry       | Auth                  | 00005E24 | 00000048 | D76F83A5 | --- EB704011-1402-11D3-8E77-00A0C969723B | MTC
 VSS entry       | Invalid               | 00005E6C | 000000FA | 7B7FE195 | --- Invalid   <--- ConOut
 VSS entry       | Invalid               | 00005F68 | 0000010B | 44135AC8 | --- Invalid   <--- ConIn
 VSS entry       | Invalid               | 00006074 | 000000DC | A2F145DC | --- Invalid   <--- ErrOut
 VSS entry       | Invalid               | 00006150 | 0000014A | 5F63563F | --- Invalid   <--- ConIn
 VSS entry       | Invalid               | 0000629C | 00000139 | 33BCF69E | --- Invalid   <--- ConOut
 VSS entry       | Invalid               | 000063D8 | 0000011B | 82C266DE | --- Invalid   <--- ErrOut
 VSS entry       | Invalid               | 000064F4 | 00000159 | 7E8D1B57 | --- Invalid   <--- ConOut
 VSS entry       | Invalid               | 00006650 | 00000110 | 1C10333C | --- Invalid   <--- ConOut
 VSS entry       | Invalid               | 00006760 | 000000D1 | 40EA30C6 | --- Invalid   <--- ConOut
 VSS entry       | Auth                  | 00006834 | 000000B1 | 3E31A587 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConOut
 VSS entry       | Invalid               | 000068E8 | 00000101 | 3EF9B03F | --- Invalid   <--- ConIn
 VSS entry       | Auth                  | 000069EC | 000000C2 | 5C48AE3F | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConIn
 VSS entry       | Invalid               | 00006AB0 | 000000D2 | B03D07E3 | --- Invalid   <--- ErrOut
 VSS entry       | Auth                  | 00006B84 | 00000093 | 2D6DFF61 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ErrOut
 Free space      |                       | 00006C18 | 000393E8 | 1B524AFE | --- Free space
 Padding         | Empty (0xFF)          | 00040000 | 00001000 | F154670A | -- Padding
 FTW store       |                       | 00041000 | 00001000 | FE3E7280 | -- FTW store
 Free space      |                       | 00042000 | 00042000 | 4BC9AB8D | -- Free space
 Padding         | Non-empty             | 00084000 | 00001000 | 306E7D61 | - Padding
```

So as you see all these `Invalid` records come from 3 variables: `ConIn`/`ConOut`/`ErrOut`. Now think about how many times the NV driver would have to erase the same flash block on every boot if these variables would be modified in-place.

For the final test let's delete our variable
```
FS0:\> SetVariableExample.efi TestVariable
Variable TestVariable was successfully deleted
```

As you can guess this operation simply would mark the variable record as invalid:
```
 VSS entry       | Invalid               | 000058B0 | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Invalid               | 000059B4 | 000000C2 | B7FD38BC | --- Invalid
 VSS entry       | Invalid               | 00005A78 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Invalid               | 00005B4C | 00000093 | C5BEF246 | --- Invalid
 VSS entry       | Invalid               | 00005BE0 | 00000072 | D928D86C | --- Invalid
 VSS entry       | Invalid               | 00005C54 | 00000072 | CB9D7782 | --- Invalid
 VSS entry       | Invalid               | 00005CC8 | 00000072 | 732110E7 | --- Invalid
 VSS entry       | Invalid               | 00005D3C | 00000072 | EEF6285E | --- Invalid
 VSS entry       | Invalid               | 00005DB0 | 00000072 | 67B27F04 | --- Invalid                                          <------
 VSS entry       | Auth                  | 00005E24 | 00000048 | D76F83A5 | --- EB704011-1402-11D3-8E77-00A0C969723B | MTC
 VSS entry       | Invalid               | 00005E6C | 000000FA | 7B7FE195 | --- Invalid
 VSS entry       | Invalid               | 00005F68 | 0000010B | 44135AC8 | --- Invalid
 VSS entry       | Invalid               | 00006074 | 000000DC | A2F145DC | --- Invalid
 VSS entry       | Invalid               | 00006150 | 0000014A | 5F63563F | --- Invalid
 VSS entry       | Invalid               | 0000629C | 00000139 | 33BCF69E | --- Invalid
 VSS entry       | Invalid               | 000063D8 | 0000011B | 82C266DE | --- Invalid
 VSS entry       | Invalid               | 000064F4 | 00000159 | 7E8D1B57 | --- Invalid
 VSS entry       | Invalid               | 00006650 | 00000110 | 1C10333C | --- Invalid
 VSS entry       | Invalid               | 00006760 | 000000D1 | 40EA30C6 | --- Invalid
 VSS entry       | Auth                  | 00006834 | 000000B1 | 3E31A587 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConOut
 VSS entry       | Invalid               | 000068E8 | 00000101 | 3EF9B03F | --- Invalid
 VSS entry       | Auth                  | 000069EC | 000000C2 | 5C48AE3F | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ConIn
 VSS entry       | Invalid               | 00006AB0 | 000000D2 | B03D07E3 | --- Invalid
 VSS entry       | Auth                  | 00006B84 | 00000093 | 2D6DFF61 | --- 8BE4DF61-93CA-11D2-AA0D-00E098032B8C | ErrOut
 Free space      |                       | 00006C18 | 000393E8 | 1B524AFE | --- Free space
 Padding         | Empty (0xFF)          | 00040000 | 00001000 | F154670A | -- Padding
 FTW store       |                       | 00041000 | 00001000 | FE3E7280 | -- FTW store
 Free space      |                       | 00042000 | 00042000 | 4BC9AB8D | -- Free space
 Padding         | Non-empty             | 00084000 | 00001000 | 306E7D61 | - Padding
```