3 ms·
Lots of people have tested these systems. Here's work we did to exploit Firecracker. We had a known, promising vulnerability, and still failed to break out. h
by insanitybit 3y ago
Lots of people have tested these systems.
Here's work we did to exploit Firecracker. We had a known, promising vulnerability, and still failed to break out.
https://web.archive.org/web/20220927150915/https://www.graplsecurity.com/post/attacking-firecracker https://web.archive.org/web/20220927150915/https://www.grapl...
Exploitation is extremely hard. No one has ever exploited RowHammer in the wild, to my knowledge, and there are a lot of reasons why - but even still, RowHammer isn't magic, you can mitigate against it by increasing your refresh rate, or by limiting the attacker's execution time. Not to mention that vendors have deployed numerous methods of reducing the likelihood of an attack and it is quite complex to pull off these days.
- Borealid 3y agoI think transparent memory encryption effectively defeats RowHammer attacks. The CPU has a key it uses to decrypt memory on access - and that key is never known by the operating system or any software running within it. If you use RowHammer to access the "wrong" memory location, the decrypted values would be random garbage. Pure hardware protection, no changes to memory chips, almost no runtime performance cost, effective security.
- insanitybit 3y agoAFAIK RowHammer is already a non issue on the latest hardware since the module will speculatively refresh rows that may be vulnerable. ie: If a ton of writes happen to row B then rows A and C will have a refresh triggered too.