Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimum sizes an OS can expect from the firmware #77

Open
lool opened this issue Mar 15, 2021 · 7 comments
Open

Minimum sizes an OS can expect from the firmware #77

lool opened this issue Mar 15, 2021 · 7 comments

Comments

@lool
Copy link

lool commented Mar 15, 2021

Hi,

The OS might want to add/alter EFI variables and the firmware needs to reserve a reasonable amount of space for this. Typically, EFI variables might be used to store path names of boot assets or fingerprints. At worst, an OS might want to store a full key, but that's not a current scenario.

There might also need to be a minimum reserved space for a capsule update or to add certificates/keys to the PKI.

@lool
Copy link
Author

lool commented Mar 15, 2021

Discussed at EBBR meeting on 2021-03-15; Heinrich provided following excepts from UEFI spec:
config EFI_VAR_BUF_SIZE
int "Memory size of the UEFI variable store"
default 16384
range 4096 2147483647
help
This defines the size in bytes of the memory area reserved for keeping
UEFI variables.

When using StandAloneMM (CONFIG_EFI_MM_COMM_TEE=y) this value should
match the value of PcdFlashNvStorageVariableSize used to compile the
StandAloneMM module.

Minimum 4096, default 16384.

@vstehle
Copy link
Collaborator

vstehle commented Jan 16, 2023

After call of Jan 16: this is configurable in U-Boot for example. Query variable info allows to retrieve the actual value at runtime. Adding a useful requirement in EBBR seems difficult. Can we close?

@lool
Copy link
Author

lool commented Jan 17, 2023

So EBBR wont guarantee or recommend a minimum size? I guess if it can be queried, proper error handling can be implemented, fine with me.

@xypron
Copy link
Contributor

xypron commented Aug 29, 2023

https://uefi.org/sites/default/files/resources/UEFI_Plugfest_Security_Microsoft_Fall_2016.pdf has this statement:

"A total of at least 120 KB of non-volatile NVRAM storage memory must be available for NV UEFI variables (authenticated and unauthenticated, BS and RT) used by UEFI Secure Boot and Windows. The maximum supported variable size must be at least 64kB and there is no maximum NVRAM storage limit."

@xypron
Copy link
Contributor

xypron commented Aug 29, 2023

This is the current Windows requirement:

Windows Hardware Compatibility Specifications for Windows 11, version 22H2– Systems
(File systems.pdf in https://go.microsoft.com/fwlink/?linkid=2196181)

31. Reserved Memory for Windows Secure Boot UEFI Variables. A total of at least 128 KB of non-volatile NVRAM storage memory must be available for NV UEFI variables (authenticated and unauthenticated, BS and RT) used by UEFI Secure Boot and Windows, and the maximum supported variable size must be at least 64 KB. There is no maximum NVRAM storage limit. Note that this is an increase from Windows 10, version 1703 requirements of 64 KB total and 32 KB variable size."

@xypron
Copy link
Contributor

xypron commented Aug 29, 2023

[PATCH] efi_loader: Increase default variable store size to 32K indicates that with 16 KiB booting Debian via shim is not possible and suggests 32 KiB as default.

@xypron
Copy link
Contributor

xypron commented Aug 29, 2023

These are the sizes of dbx files downloaded form uefi.org:

  • 4610 arm64_DBXUpdate.bin
  • 8642 arm_DBXUpdate.bin
  • 21170 x64_DBXUpdate.bin

Looking at these sizes the 16 KiB default with StandAloneMM in U-Boot seems inadequate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants