The VUSec group at Vrije Universiteit Amsterdam publishes research on hardware security, including Rowhammer, Spectre variants, and side-channel attacks.
HN links it for details on CPU and memory attacks like CrossTalk, Rain, and Training Solo, and commenters praise VU Amsterdam's security program and courses.
This reminds me of timing side channel attacks in general. With VUSEC (VU University Amsterdam) we did flush/reload side channel attacks. I don't remember the specifics, I did this in 2018.
But yea, basically if a cache hit versus a memory roundtrip will result in different time values, then you can iterate over all 256 bytes (assuming ASCII) and when you have a cache hit for a specific value, the time should be much lower.
However, this also assumes you understand cache internals of the specific CPU and it means you need to know when caches fill up, why they fill up and how to do cache eviction. Knowing how to do cache eviction means that you need to know how many elements can be cached, and if I recall correctly that means you need to reverse engineer the cache size of the CPU. But once you can reliable evict values from the cache set and reliably fill them up, then the rough outline I mentioned above is possible.
Again, this is like 50% accurate since it has been a long while and I currently work in marketing as a data analyst (I like a mix of fluffy marketing/psychology talk and being deeply technical - if you feel the same way, feel free to reach out. My email is on my profile). There's some of what I described on this website (and a whole bunch more) [1]. I think the reverse engineering of cache lines was specifically in the accompanied paper.
[1] https://www.vusec.net/projects/glitch/
Thanks for the interesting historical reference!
As you state, this type of problem is not new, and as noted at [1] e.g. Intel have taken this seriously on their Xeon lineup for a while.
It's a shame (LP)DDR4 standards did not make Target Row Refresh mandatory.
From the FAQ at [2]:
I have a phone with LPDDR4 memory. Am I safe against Drammer attacks?
Again, we don’t know. Chances are that your DRAM comes with the Target Row Refresh (TRR) mitigation, which makes it harder – but still not impossible, in theory – to induce bit flips. Moreover, TRR for LPDDR4 is optional, so your DRAM manufacturer may have decided to drop this technique and leave you vulnerable.
[1] https://en.wikipedia.org/wiki/Row_hammer#Mitigation
[2] https://www.vusec.net/projects/drammer/
There are GLSL exploits.
"Vulnerability analysis of GPU computing"
https://lib.dr.iastate.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=4122&context=etd
"Grand Pwning Unit: Accelerating Microarchitectural
Attacks with the GPU"
https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf
Just two random papers, there are quite a few others.
Ah, and as usual when discussing 3D APIs, games console also use their own flavours, XBox is not the exception.
I saw this article linked later. https://www.vusec.net/projects/eccploit/
It's interesting! It seems fixable, based on information later on in the article ("Can I get DDR3 DIMMs that are Rowhammer-free?"), and ECC only seems to be part of a solution, and not a complete solution.
But you're still right, and I was still wrong: ECC alone isn't good enough.
As someone who followed a course on all of this, this is indeed how we started out.
1. Read Flush + Reload
2. Then reproduce it in C
3. Then read Meltdown
4. Reproduce it in C
5. Read Spectre
6. Reproduce it in C
After that we had to implement a VUSEC paper. I chose GLitch [1].
[1] https://www.vusec.net/projects/glitch/
No. Trivially bypassed without a leak. Two of many examples:
https://dl.acm.org/doi/10.5555/3195638.3195686
https://www.vusec.net/projects/anc/
New timing attacks that break ASLR come out ~annually. These are hardware mechanisms that cannot be mitigated by software. ASLR is broken. (Nevermind ROP gadget compilers, etc.)