Comment 12 for bug 1878541

I did a bit of digging on this, and it seems to happen because the grub verifier module reads in to memory the entire contents of any file that is opened via grub_file_open without the GRUB_FILE_TYPE_SKIP_SIGNATURE flag or any file which doesn't have a type of GRUB_FILE_TYPE_SIGNATURE or GRUB_FILE_TYPE_VERIFY_SIGNATURE, so that it can provide the file contents to the registered verifier modules and provide the verified contents to the grub file API from memory without having to load it from disk again (which would obviously be vulnerable to TOCTOU type bugs).

Configuring a loopback device via the loopback command opens the underlying disk image, which results in grub's verifier code reading the entire image in to memory. In the case of booting a UC20 recovery system, the loopback image is the kernel snap squashfs. This doesn't happen with the UC18 version of grub because it doesn't ship the verifier module (which is pulled in in UC20 because of the TPM verifier module. The TPM verifier just calculates a hash of the file contents and measures it to PCR9).

I'm not sure that passing loopback image files through the verifier module is a sensible default. The loopback device is just another disk backend, and grub doesn't pass entire physical disk images through the verifier. It seems weird that loopback images would be treated differently, particularly because files opened from the filesystem within the loopback image will be passed through the verifier.

I tested a local build of grub with the attached patch, and was able to boot a UC20 recovery kernel via a loop mounted kernel snap squashfs in a VM with 512MB of RAM. I'm not sure if it's the correct fix for this though.