I don't think your points actually disagree with my points, I think we are actually in agreement on the technical issues.
- Hibernate images are outside the trust boundary because they contain arbitrary code
- The fix is to not restore hibernate images
- The proposed signature checking on hibernate images could protect an un-compromised system on disk from being modified before being restored
- There is no security added for a system booted in a VM
- There is no attestation in Secure Boot, a running system can't tell if it's been compromised or not
I don't think Secure Boot attempts or claims to solve the problems of running arbitrary code it only allows you to build a beachhead, ideally an execution chain all the way until user space starts that can't be modified without throwing alarms. That means that re-compromise of a system needs to happen via the normal startup sequence and tools started before the malware can run can potentially block the malware. Once the malware runs it's Blue Pill all the way, you can't trust anything on the system after that.