The AAVMF_CODE*.fd files provide UEFI firmware for a QEMU guest that is
intended to be read-only. The AAVMF_VARS*.fd files provide UEFI variable
template images which are intended to be read-write, and therefore each
guest should be given its own copy. Here's an overview of each of them:

AAVMF_CODE.no-secboot.fd
  Use this for booting guests in non-Secure Boot mode. This image contains
  a built-in UEFI shell which makes it insecure for use in Secureoot mode.
  Use the AAVMF_VARS.fd template with this.

AAVMF_CODE.fd
  This is a compatibility symlink to facilitate smooth upgrades from before
  the secboot/no-secboot split. Users should migrate away from this and
  expect it to be removed in a future release.

AAVMF_CODE.ms.fd
  This is a symlink to AAVMF_CODE.secboot.fd. It is useful in the context of
  libvirt because the included JSON firmware descriptors will tell libvirt
  to pair AAVMF_VARS.ms.fd with it, which has Secure Boot pre-enabled.

AAVMF_CODE.secboot.fd
  This image is recommended for guests in Secure Boot mode. It does not
  contain a built-in UEFI shell because it could be used to bypass Secure
  Boot. Be aware that the included JSON firmware descriptors associate
  this with OVMF_CODE_4M.fd. Which means, if you specify this image in
  libvirt, you'll get a guest that is Secure Boot-*capable*, but has
  Secure Boot disabled. To enable it, you'll need to manually import
  PK/KEK/DB keys and activate Secure Boot from the UEFI setup menu. If
  you want Secure Boot active from the start, consider using
  OVMF_CODE.ms.fd instead.

AAVMF_CODE.secboot.strictnx.fd
  This is the same as the AAVMF_CODE.secboot.fd, except that it has
  the EFI_MEMORY_ATTRIBUTE_PROTOCOL enabled. This provides additional
  security, but will result in crashes with many old guest operating
  system versions that do not observe proper memory access semantics.
  This security feature will be enabled by default in the
  AAVMF_CODE.secboot.fd image in a future release.

AAVMF_VARS.fd
  This is an empty variable store template, which means it has no
  built-in Secure Boot keys and Secure Boot is disabled. You can use
  it with any AAVMF_CODE image, but keep in mind that if you want to
  boot in Secure Boot mode, you will have to enable it manually.

AAVMF_VARS.ms.fd
  This template has distribution-specific PK and KEK1 keys, and
  the default Microsoft keys in KEK/DB. It also has Secure Boot
  already activated. Using this with AAVMF_CODE.ms.fd will boot a
  guest directly in Secure Boot mode.

AAVMF_CODE.snakeoil.fd
AAVMF_VARS.snakeoil.fd
  This image is **for testing purposes only**. It includes an insecure
  "snakeoil" key in PK, KEK & DB. The private key and cert are also
  shipped in this package as well, so that testers can easily sign
  binaries that will be considered valid.

PkKek-1-snakeoil.key
PkKek-1-snakeoil.pem
  The private key and certificate for the snakeoil key. Use these
  to sign binaries that can be verified by the key in the
  AAVMF_VARS.snakeoil.fd template. The password for the key is
  'snakeoil'.

 -- dann frazier <dannf@debian.org>, Mon, 12 May 2025 18:35:35 -0600