bios – Where does UEFI find the names for each entry in the boot options list?

To my understanding, the motherboard/bios keeps a list in NVRAM of EFI boot options. These can be edited with programs like efibootmgr. But those must be being populated from some data in the EFI partition, right?

No. The list is not actually populated from the EFI partition at all. Instead, the OS installer program has added the entry “manually”, specifying its name and .efi file path – the same way that efibootmgr adds it.

(From what I remember, installing Fedora literally runs efibootmgr to add the entry. You can repeat it using grub-install, or in the Windows case, using bcdboot.exe.)

If the entry were to be removed, then the firmware wouldn’t know anything about which file is correct or how it’s named.

Indeed the fact that the list is kept in NVRAM – the ‘NV’ means non-volatile storage – already suggests that it can’t be populated from the EFI partition, because if that were the case, there wouldn’t be a need to store the list itself in NVRAM (as it could be re-populated on boot).

There are two exceptions to this:

For removable media, it is unrealistic to expect a predefined boot entry, so the firmware looks for a single specific .efi file instead: \EFI\Boot\Bootx64.efi on x64 PCs. When you have entries named like “UEFI: Kingston USB” or such – i.e. named after the disk itself – they represent the boot64.efi entry. This method cannot determine the OS name, and allows only one OS per disk.

Most firmwares also do this for internal disks too, as a “fallback” method in case all NVRAM entries are missing. (Latest UEFI specification has codified this.)
Some manufacturers’ firmwares actually have special cases for Windows specifically – they were programmed to look for \EFI\Microsoft\Bootmgfw.efi and “know” that it should be titled ‘Windows Boot Manager’.

This is not part of the UEFI specification; they’re just trying to be “smart”.

I’ve also heard that some PCs similarly give special treatment to Ubuntu and/or Fedora/RHEL, i.e. the “big” Linux distributions. In all cases, the specific file paths and their respective names are embedded in the firmware itself.

So when you bring an internal disk from another PC, what happens is that 1) all existing NVRAM entries are skipped as they reference non-existent partitions, and 2) the firmware either detects that the disk contains Windows, or it detects an unnamed OS from the generic bootx64.efi file.

When you clone a disk from the same PC, it depends on how accurate the clone procedure is.

With a true 1:1 clone, the new disk will actually have the same partition UUIDs as the original, and therefore the same old NVRAM entries will still apply to the new disk as well.
On the other hand, if the cloning procedure generates new partition UUIDs (i.e. it creates a fresh partition table and clones just the filesystems individually) – see the “disk from another PC” explanation.

And when you boot a removable disk, normally what should happen is that the firmware would look only for the bootx64.efi file and give it a generic entry named after the disk.

(It is possible that the firmware specifically detects a Windows installer on a USB stick, but I’ve never seen that happen – and there is less need for it, given that bootable EFI USB sticks always have the bootx64.efi file so the special case is not nearly as useful. With internal disks, the special treatment is excusable as not all system disks have the fallback file; some rely entirely on the NVRAM entry.)

Is the BIOS actually executing these .efi files somehow to get the name to display for them, without actually triggering the boot process, or is there some header or something in them? Or is there some other hidden place where the names come from?

No, the .efi files do not have any such metadata. They’re just standard .exe files.

While the file format would allow them to contain machine-readable metadata, the UEFI specification doesn’t define any such thing. The only source for boot entries is manual addition, either by the user or by the OS installer.

(Although for example, systemd-boot – a secondary boot manager used by some Linux distributions – has defined its own metadata format for this purpose, and is able to automatically populate its own list of bootable ‘vmlinuz’ kernel images in certain situations.)