OVMF: NV Variable Store Layout of Larger Build Targets

OVMF: NV Variable Store Layout of Larger Build Targets

[Devon Bautista]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

Hello All,

I am currently working with the Linuxboot developers to improve testing 
kernel + initramfs pairs in firmware using OVMF.

The current maximum image size of an OVMF image is 4MB, which is 
insufficient for storing even a minimal and compressed kernel and 
initramfs. To get around this, we've been maintaining our own fork of 
EDK2 that adds 8MiB and 16MiB OVMF build targets that have enough room 
in the DXE volume to store a reasonably-sized kernel and initramfs. 
However, it would be convenient if upstream EDK2 supported these larger 
OVMF targets.

In discussing this with the previous OVMF maintainer Laszlo Ersek here 
<https://edk2.groups.io/g/devel/message/75794>, it was brought up that:

  * The trend of the ever-growing DXE-phase warrants a larger firmware
    volume size
  * 8MiB and 16MiB image sizes seem to be justified because of this QEMU
    commit
    <https://github.com/qemu/qemu/commit/0657c657eb37bb48bfd9fe3ae8a323ae3455f47b>

However, as Laszlo mentioned, introducing a larger volume size is 
compatibility breaking, and so seizing the opportunity to come up with a 
larger non-volatile variable store layout is necessary.

That said, I would like to use this thread to discuss among hardware 
vendors an optimal variable store layout for these larger image sizes.

Best,
Devon


[-- Attachment #2: Type: text/html, Size: 2098 bytes --]

Re: [edk2-devel] OVMF: NV Variable Store Layout of Larger Build Targets

[Devon Bautista]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

For reference, here is a summary of which sections increased when the 4MiB build target was added (taken from commit [`b24fca05`](https://github.com/tianocore/edk2/commit/b24fca05751f8222acf264853709012e0ab7bf49)) after the previous 2MiB limit:
```
  Description                Compression type                Size [KB]
  -------------------------  -----------------  ----------------------
  Non-volatile data storage  open-coded binary    128 ->   528 ( +400)
                               data
    Variable store                                 56 ->   256 ( +200)
    Event log                                       4 ->     4 (   +0)
    Working block                                   4 ->     4 (   +0)
    Spare area                                     64 ->   264 ( +200)

  FVMAIN_COMPACT             uncompressed        1712 ->  3360 (+1648)
    FV FFS file              LZMA compressed
      PEIFV                  uncompressed         896 ->   896 (   +0)
        individual PEI       uncompressed
          modules
      DXEFV                  uncompressed       10240 -> 10240 (   +0)
        individual DXE       uncompressed
          modules

  SECFV                      uncompressed         208 ->   208 (   +0)
    SEC driver
    reset vector code
```

[-- Attachment #2: Type: text/html, Size: 1431 bytes --]

Re: OVMF: NV Variable Store Layout of Larger Build Targets

[Ard Biesheuvel]

(+ Gerd)

On Sat, 21 Aug 2021 at 03:10, Devon Bautista
<dbautista@newmexicoconsortium.org> wrote:
>
> Hello All,
>
> I am currently working with the Linuxboot developers to improve testing kernel + initramfs pairs in firmware using OVMF.
>
> The current maximum image size of an OVMF image is 4MB, which is insufficient for storing even a minimal and compressed kernel and initramfs. To get around this, we've been maintaining our own fork of EDK2 that adds 8MiB and 16MiB OVMF build targets that have enough room in the DXE volume to store a reasonably-sized kernel and initramfs. However, it would be convenient if upstream EDK2 supported these larger OVMF targets.
>
> In discussing this with the previous OVMF maintainer Laszlo Ersek here, it was brought up that:
>
> The trend of the ever-growing DXE-phase warrants a larger firmware volume size
> 8MiB and 16MiB image sizes seem to be justified because of this QEMU commit
>
> However, as Laszlo mentioned, introducing a larger volume size is compatibility breaking, and so seizing the opportunity to come up with a larger non-volatile variable store layout is necessary.
>
> That said, I would like to use this thread to discuss among hardware vendors an optimal variable store layout for these larger image sizes.
>
> Best,
> Devon


> For reference, here is a summary of which sections increased when the 4MiB build target was added (taken from commit b24fca05) after the previous 2MiB limit:
>
>   Description                Compression type                Size [KB]
>   -------------------------  -----------------  ----------------------
>   Non-volatile data storage  open-coded binary    128 ->   528 ( +400)
>                                data
>     Variable store                                 56 ->   256 ( +200)
>     Event log                                       4 ->     4 (   +0)
>     Working block                                   4 ->     4 (   +0)
>     Spare area                                     64 ->   264 ( +200)
>
>   FVMAIN_COMPACT             uncompressed        1712 ->  3360 (+1648)
>     FV FFS file              LZMA compressed
>       PEIFV                  uncompressed         896 ->   896 (   +0)
>         individual PEI       uncompressed
>           modules
>       DXEFV                  uncompressed       10240 -> 10240 (   +0)
>         individual DXE       uncompressed
>           modules
>
>   SECFV                      uncompressed         208 ->   208 (   +0)
>     SEC driver
>     reset vector code
>

Re: [edk2-devel] OVMF: NV Variable Store Layout of Larger Build Targets

[Gerd Hoffmann]

  Hi,

> The current maximum image size of an OVMF image is 4MB, which is
> insufficient for storing even a minimal and compressed kernel and initramfs.
> To get around this, we've been maintaining our own fork of EDK2 that adds
> 8MiB and 16MiB OVMF build targets that have enough room in the DXE volume to
> store a reasonably-sized kernel and initramfs. However, it would be
> convenient if upstream EDK2 supported these larger OVMF targets.

I'm wondering whenever it makes sense to have the 8M option.  I think
I'd tend to go straight to 16M (which is the max size we can do on x86).

> However, as Laszlo mentioned, introducing a larger volume size is
> compatibility breaking, and so seizing the opportunity to come up
> with a larger non-volatile variable store layout is necessary.
> 
> That said, I would like to use this thread to discuss among hardware
> vendors an optimal variable store layout for these larger image sizes.

The 2M -> 4M switch happened because the varstore was too small.  It was
Confirm64KilobytesOfUnauthenticatedVariableStorage test of the the
Microsoft Hardware Certification failing.  I guess Microsoft has good
reasons to test for 64k varstore, probably they expect this is big
enough in practice.

The varstore size of the 4M layout is *way* above that (see 2M -> 4M
commit message):

  Variable store      56 ->   256 ( +200)
  Spare area          64 ->   264 ( +200)

Assuming 256k varstore is more than enough:  Sticking to the 4M variable
store layout for the 16M (and maybe 8M) builds looks like the best
option to me.  I think the varstore would be identical for 4M and 16M
builds then, so it should be possible to switch guests from 4M to 16M
while keeping the varstore.

take care,
  Gerd

Re: [edk2-devel] OVMF: NV Variable Store Layout of Larger Build Targets

[Devon Bautista]

[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]

Hi Gerd,

>> The current maximum image size of an OVMF image is 4MB, which is
>> insufficient for storing even a minimal and compressed kernel and initramfs.
>> To get around this, we've been maintaining our own fork of EDK2 that adds
>> 8MiB and 16MiB OVMF build targets that have enough room in the DXE volume to
>> store a reasonably-sized kernel and initramfs. However, it would be
>> convenient if upstream EDK2 supported these larger OVMF targets.
> I'm wondering whenever it makes sense to have the 8M option.  I think
> I'd tend to go straight to 16M (which is the max size we can do on x86).

On the Linuxboot side, we really only need 16MiB. However, I think
Laszlo justified an 8MiB target because the QEMU commit he pointed to
(referenced in my initial post) increased the absolute firmware size
limit to be 16MiB when setting the maximum (`pcms->max_fw_size`) in
`pc_machine_set_max_fw_size()`, but the default maximum if not set is 8MiB.

So I understand why an 8MiB target is justified, but, like you, I am not
sure if it's really needed.

>> However, as Laszlo mentioned, introducing a larger volume size is
>> compatibility breaking, and so seizing the opportunity to come up
>> with a larger non-volatile variable store layout is necessary.
>>
>> That said, I would like to use this thread to discuss among hardware
>> vendors an optimal variable store layout for these larger image sizes.
> The 2M -> 4M switch happened because the varstore was too small.  It was
> Confirm64KilobytesOfUnauthenticatedVariableStorage test of the the
> Microsoft Hardware Certification failing.  I guess Microsoft has good
> reasons to test for 64k varstore, probably they expect this is big
> enough in practice.
>
> The varstore size of the 4M layout is *way* above that (see 2M -> 4M
> commit message):
>
>   Variable store      56 ->   256 ( +200)
>   Spare area          64 ->   264 ( +200)
>
> Assuming 256k varstore is more than enough:  Sticking to the 4M variable
> store layout for the 16M (and maybe 8M) builds looks like the best
> option to me.  I think the varstore would be identical for 4M and 16M
> builds then, so it should be possible to switch guests from 4M to 16M
> while keeping the varstore.

Keeping the 4MiB varstore layout would be the most compatible and
straightforward option and is what I would want to go with.

But I also think that it might make sense when introducing a
considerably larger build target to account for any possible increases
in variable store size that vendors may expect in the future. I for one
dismay any further size increase, but I suppose the more relevant
question is, is 256KiB of varstore enough for vendors?

-- 
Best,
Devon

[-- Attachment #2: Type: text/html, Size: 3793 bytes --]

Re: [edk2-devel] OVMF: NV Variable Store Layout of Larger Build Targets

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]



> On Aug 30, 2021, at 10:52 AM, Devon Bautista <dbautista@newmexicoconsortium.org> wrote:
> 
> Hi Gerd,
> 
>>> The current maximum image size of an OVMF image is 4MB, which is
>>> insufficient for storing even a minimal and compressed kernel and initramfs.
>>> To get around this, we've been maintaining our own fork of EDK2 that adds
>>> 8MiB and 16MiB OVMF build targets that have enough room in the DXE volume to
>>> store a reasonably-sized kernel and initramfs. However, it would be
>>> convenient if upstream EDK2 supported these larger OVMF targets.
>> I'm wondering whenever it makes sense to have the 8M option.  I think
>> I'd tend to go straight to 16M (which is the max size we can do on x86).
> On the Linuxboot side, we really only need 16MiB. However, I think Laszlo justified an 8MiB target because the QEMU commit he pointed to (referenced in my initial post) increased the absolute firmware size limit to be 16MiB when setting the maximum (`pcms->max_fw_size`) in `pc_machine_set_max_fw_size()`, but the default maximum if not set is 8MiB.
> 
> So I understand why an 8MiB target is justified, but, like you, I am not sure if it's really needed.
> 
>>> However, as Laszlo mentioned, introducing a larger volume size is
>>> compatibility breaking, and so seizing the opportunity to come up
>>> with a larger non-volatile variable store layout is necessary.
>>> 
>>> That said, I would like to use this thread to discuss among hardware
>>> vendors an optimal variable store layout for these larger image sizes.
>> The 2M -> 4M switch happened because the varstore was too small.  It was
>> Confirm64KilobytesOfUnauthenticatedVariableStorage test of the the
>> Microsoft Hardware Certification failing.  I guess Microsoft has good
>> reasons to test for 64k varstore, probably they expect this is big
>> enough in practice.
>> 
>> The varstore size of the 4M layout is *way* above that (see 2M -> 4M
>> commit message):
>> 
>>   Variable store      56 ->   256 ( +200)
>>   Spare area          64 ->   264 ( +200)
>> 
>> Assuming 256k varstore is more than enough:  Sticking to the 4M variable
>> store layout for the 16M (and maybe 8M) builds looks like the best
>> option to me.  I think the varstore would be identical for 4M and 16M
>> builds then, so it should be possible to switch guests from 4M to 16M
>> while keeping the varstore.
> Keeping the 4MiB varstore layout would be the most compatible and straightforward option and is what I would want to go with.
> 
> But I also think that it might make sense when introducing a considerably larger build target to account for any possible increases in variable store size that vendors may expect in the future. I for one dismay any further size increase, but I suppose the more relevant question is, is 256KiB of varstore enough for vendors?
> 
I’m also in the 16 MiB camp and I’m OK with the 256KiB varstore. 

Thanks,

Andrew Fish

> -- 
> Best,
> Devon
> 


[-- Attachment #2: Type: text/html, Size: 7403 bytes --]