This whole line of reasoning seems wrong. If there is malware running on the system when it is hibernated then the malware will be written to the hibernate volume and restored with it so the system is no more or less compromised, it all seems like a no-op. If the system does not have malware and uses some signing system with a public key in firmware generated on boot and a private key in the kernel which is not written to the hibernate volume then I don't see how one could modify the hibernate volume without being detected.
Even in the case where there is malware running on a system you should still be able to perform a clean boot with verification up to the point where your trust chain stops. Then the problem is post-boot (re)compromise and you can use many tools to combat that, if you can get them into your trusted base.