The aim isn't to prevent modification of the swap image on an existing system (there may be benefits to that, this just isn't what we're concerned about). The aim is to avoid the case where an attacker can drop a malware payload consisting of a legitimately signed Linux bootloader, a legitimately signed Linux kernel and a malware hibernation image that then launches a backdoored OS (not necessarily Linux). If the hibernation key is session-specific then that seems achievable:
1) Shim or grub generates keypair and passes the private key to kernel. The public key is saved in a boot services variable, preventing it being read by the running OS.
2) Kernel encrypts the suspend image.
3) Shim (or grub) generates a new keypair and saves the public key. It passes the new private key and the old public key to the kernel, and then wipes the old public key from the variable store.
4) Kernel verifies that the swap image is appropriately signed and then discards the old public key. The new private key is kept so the user can hibernate again.
Since the key is specific to the combination of the machine and the boot, an attacker shouldn't be able to deploy a pre-packaged attack. Am I missing something?