Comment 70 for bug 1851311

I run into this intermittently from time to time with my loopback USB stick maintenance scripts [1] - including the `ls` "out of memory" test (comment #6, #66) that triggers for files larger than about 100 MB.

I have found a workaround, which is to pass `--no-uefi-secure-boot` and to allow insecure boot from your BIOS. This is possible whilst still using EFI and a GPT partition table, and thankfully so as it seems newer laptops are ditching support for legacy boot from MS-DOS partition tables.

Using the grubx64.efi from older versions of grub (#34, #49, #50) is not a proper sustainable workaround, this file contains a lot of the core logic of grub, and what you are doing is effectively mixing old core logic with newer modules. It may work "by accident" but likely you will (and I did) get extremely strange (undefined) behaviour such as:

- boot loops
- not automatically loading /grub/grub.cfg
- errors about trying to load non-existent /EFI/grub/grubenv instead of /grub/grubenv
- "probe" command not found
- colours looking not how they should look

[1] https://github.com/infinity0/uberimg

The problem with `ls` (I did not have time to test `loopback`) arises directly or indirectly from verifiers logic - if I `set debug=all` then succeeding cases look like:

~~~~
[..]
kern/verifiers.c:??? trying verifier pgp
kern/verifiers.c:??? trying verifier tpm
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
[..]
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
commands/efi/tpm.c:???: log_event, pcr = 9, size = 0x???, <FILE BEING LSed>
kern/disk.c:???: Closing `hd0'.
disk/efi/efidisk.c:???: closing `hd0'.
<OUTPUT OF LS>
~~~~

whereas the failing cases with the big files look like:

~~~~
[..]
kern/verifiers.c:??? trying verifier pgp
kern/verifiers.c:??? trying verifier tpm
kern/disk.c:???: Closing `hd0'.
disk/efi/efidisk.c:???: closing `hd0'.
kern/disk.c:???: Closing `hd0'.
disk/efi/efidisk.c:???: closing `hd0'.
out of memory
~~~~

Unfortunately I'm unable to test further, because booting with an unsigned grub (as per --no-uefi-secure-boot) makes the problem go away, and I don't have the keys to boot with a signed grub.

The whole concept of "UEFI secure boot" seems to have spawned a cancerous mass of overengineered crap around it, the only use case it's good for is against a remote attacker that already has the ability to tell your device to reboot, otherwise a local attacker can just disable it through BIOS. It should be OFF BY DEFAULT, and only users/admins who understand and care about that attack mode can enable it, instead of causing headaches for the rest of us.