Hi, author here. Thanks for posting this! I gave a talk yesterday at the 39th Chaos Communication Congress in Hamburg that goes into detail about how the vulnerability works [1]. Short summary, on affected CPUs, all of host physical memory can be read, despite commonly applied software mitigations. On Google Cloud, we were able to leak from all of the physical memory from other tenants as well, without having to interact with the victim virtual machine.
While I was sure they'd note that Nitro doesn't have this vulnerability due to its design, it seems weird not to talk about Firecracker and Lambda and so on. Maybe those are always on Cascadelake+ hardware? (I also haven't followed this space for 5 years, so maybe I'm asking the wrong question)
thijsr•1mo ago
We've only verified EC2 during our research, but you do make a good point here. Nitro wasn't vulnerable. Firecracker might have been, considering that it is also built on top of KVM. Firecracker was not specifically designed to also defend against hardware vulnerabilities [1], so I don't see an immediate reason why it wouldn't have worked.
We had to limit the scope of the project somewhere unfortunately, but it would have been nice to check Firecracker and Lambda as well.
thijsr•1mo ago
[1] https://media.ccc.de/v/39c3-spectre-in-the-real-world-leakin...
boulos•1mo ago
Nice write up and very clever work. I'm surprised by the AWS response that you linked to though (https://aws.amazon.com/blogs/security/ec2-defenses-against-l...).
While I was sure they'd note that Nitro doesn't have this vulnerability due to its design, it seems weird not to talk about Firecracker and Lambda and so on. Maybe those are always on Cascadelake+ hardware? (I also haven't followed this space for 5 years, so maybe I'm asking the wrong question)
thijsr•1mo ago
We had to limit the scope of the project somewhere unfortunately, but it would have been nice to check Firecracker and Lambda as well.
[1] https://github.com/firecracker-microvm/firecracker/blob/main...
Fnoord•1mo ago