The problem here is that mkfs.vcat will create a partition spanning from offset 1 MB to the end of the image. However, this is not valid for GPT based disk, because there is a reserved section at the end of the disk for the secondary/backup GPT header.
This doesn't initially cause any issues, because the blocks at the beginning of the filesystem will be used first, and the blocks at the end will just be considered unused free blocks. However, if the images are mounted, then adding and deleting files will start cycling through the free blocks and will eventually clobber the GPT secondary header. I ran into this issue while trying to locally modify the images to code sign them for secure boot.
To reproduce this issue, you can use the following commands, which mounts an image and fills the remaining space with random data, causing corruption:
$ sudo mkdir -p /mnt/image
$ curl -L https://github.com/Drive-Trust-Alliance/exec/blob/1.20.0/UEFI64.img.gz?raw=true | gunzip -c > UEFI64.img
$ sudo mount -t vfat -o loop,rw,uid=$(id -u),gid=$(id -g),offset=1048576 UEFI64.img /mnt/image/
$ dd if=/dev/urandom of=/mnt/image/dummy.bin bs=512
dd: error writing '/mnt/image/dummy.bin': No space left on device
22037+0 records in
22036+0 records out
11282432 bytes (11 MB, 11 MiB) copied, 0.306709 s, 36.8 MB/s
$ sudo umount /mnt/image/
$ sgdisk --verify UEFI64.img
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.
Identified 1 problems!
The fix should be pretty simple. Just need to limit the size of the LOOPDEV to (DISK_SIZE - 1048576 - 33*512). I would normally submit a PR, but I’m not sure yet if my employer will let me sign the contributor agreement, so perhaps someone else can fix this.
I found an issue with the way that the FAT partition is created for GPT based images. The relevant shell code is in
buildUEFI64andbuildrescue:The problem here is that
mkfs.vcatwill create a partition spanning from offset 1 MB to the end of the image. However, this is not valid for GPT based disk, because there is a reserved section at the end of the disk for the secondary/backup GPT header.This doesn't initially cause any issues, because the blocks at the beginning of the filesystem will be used first, and the blocks at the end will just be considered unused free blocks. However, if the images are mounted, then adding and deleting files will start cycling through the free blocks and will eventually clobber the GPT secondary header. I ran into this issue while trying to locally modify the images to code sign them for secure boot.
To reproduce this issue, you can use the following commands, which mounts an image and fills the remaining space with random data, causing corruption:
The fix should be pretty simple. Just need to limit the size of the LOOPDEV to
(DISK_SIZE - 1048576 - 33*512). I would normally submit a PR, but I’m not sure yet if my employer will let me sign the contributor agreement, so perhaps someone else can fix this.