Rowhammer on Rp4

[frederick00]

Hi Everyone,

Is Rp4 affected by Rowhammer ? and is there someone working on it ?

Thank You.

[davidcoton]

Search "Rowhammer" on the Forum.It will tell you all that anyone here knows.

[frederick00]

Search "Rowhammer" on the Forum.It will tell you all that anyone here knows.

I did it, but there are few posts which fosused on older Rp.

[DougieLawson]

Search "Rowhammer" on the Forum.It will tell you all that anyone here knows.

I did it, but there are few posts which fosused on older Rp.

I think you should consider that the problem was investigated back when it first appeared in 2015 and any changes to RPi hardware will have been built into the RPi4 as it was developed.

[davidcoton]

Search "Rowhammer" on the Forum.It will tell you all that anyone here knows.

I did it, but there are few posts which fosused on older Rp.

Given that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?

[hippy]

Given that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?

That's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.

[Ernst]

I am more worried about Sledgehammer which is much more destructive.

[frederick00]

Given that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?

That's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.

I agree with you. I'd like to talk to someone who is working on it.

[frederick00]

Search "Rowhammer" on the Forum.It will tell you all that anyone here knows.

I did it, but there are few posts which fosused on older Rp.

I think you should consider that the problem was investigated back when it first appeared in 2015 and any changes to RPi hardware will have been built into the RPi4 as it was developed.

Sorry, i got confused about your answer, are you saying that the problem doesn't exist ? i mean, what kind of security defense could be implemented on Rpi4? Target Row Refresh shouldn't be implemented on the board.

[davidcoton]

Given that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?

That's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.

While what you say is true in the legal world, in the scientific world we can be fairly sure that if a well-known problem is not reported on a well-known machine, either it was never present or it has been fixed. Either that or part of "Rowhammer" is to suppress the curiosity of all the so-called "while hat" pen-testers who are out there.

If there is no problem, there will be no-one working on it, so how can you talk to them? All anyone can tell you is "We don't know of a Rowhammer problem on the RPi4". That doesn't guarantee there really isn't.

Possibly, of course, there is a gaping problem but no-one is talking about it because they know there is no fix and talking would lead to many more exploits. How far do you want to take your conspiracy theory?

[ejolson]

All of the big-name vulnerabilities

• Rowhammer
• Meltdown
• Spectre

existed for 5 to 10 years in multiple iterations of hardware design before someone outside the super-secret spy agencies discovered them. The fact that such hardware faults can only be exhibited by someone who looks for them doesn't mean they're not there. On the other hand, such faults are generally interesting only in the context of virtual machines running on multiple tenant hardware in the cloud. Unless you like spying on yourself, they're not very interesting for a single-user Pi.

Having said this, my feeling is that the memory subsystem on the Pi 4B is too bandwidth constrained for rowhammer to have much chance of flipping a bit. Moreover, given how many have overclocked their Pi's, it doesn't seem people are worried much about hardware errors anyway. It would be interesting, though, for someone to run some tests and see what happens. Maybe this could be a good project at the secondary school level and up.

[moriartynz]

Most rowhammer implementations have been made to date on x86/AMD64. There is one test I am aware of for ARM-v8, but it relies on platform-specific bindings to work on the AML-S905X-CC (Le Potato). You can find the code on github: https://github.com/VandySec/rowhammer_armv8

Not only is there no platform-specific rowhammer code for the ARM-v8 RPi4B that I can find, but the test also requires root privileges to achieve the rowhammer exploit by way of a custom-built kernel module. It needs the kernel module to achieve physical-to-DRAM address mapping and find appropriate aggressor rows to set up the attack. To implement an exploit (helpful for the attacker), 32-bit ARM has an equivalent cache-line-flush to x86's CLFLUSH, but (unhelpfully for the attacker) it's not usable from userland processes.

There are several take home messages here:

1. The current ARM-v8 test exploit requires root privileges to obtain physical-to-DRAM address mapping.
2. The ARM-v8 exploit also requires root privileges to find appropriate aggressor rows.
3. The RPi-4B firmware is proprietary and this means there isn't an easily documented path for a would-be attacker to write the necessary assembler code to interface with the RPi4B firmware to decompile the address mapping and identify potential aggressor rows.
4. Once these barriers are overcome then the DRAM itself will be susceptible to rowhammer.

I'm not going to say that there's never going to be a rowhammer exploit for the RPi4B as the DRAM is inherently able to be bit-flipped. However, the barriers to implement this exploit are high and the exploit is not currently realistically feasible except on a root-compromised device, in which case the need for the exploit goes away as you have root access anyway.

[ejolson]

Most rowhammer implementations have been made to date on x86/AMD64. There is one test I am aware of for ARM-v8, but it relies on platform-specific bindings to work on the AML-S905X-CC (Le Potato). You can find the code on github: https://github.com/VandySec/rowhammer_armv8

Not only is there no platform-specific rowhammer code for the ARM-v8 RPi4B that I can find, but the test also requires root privileges to achieve the rowhammer exploit by way of a custom-built kernel module. It needs the kernel module to achieve physical-to-DRAM address mapping and find appropriate aggressor rows to set up the attack. To implement an exploit (helpful for the attacker), 32-bit ARM has an equivalent cache-line-flush to x86's CLFLUSH, but (unhelpfully for the attacker) it's not usable from userland processes.

There are several take home messages here:

1. The current ARM-v8 test exploit requires root privileges to obtain physical-to-DRAM address mapping.
2. The ARM-v8 exploit also requires root privileges to find appropriate aggressor rows.
3. The RPi-4B firmware is proprietary and this means there isn't an easily documented path for a would-be attacker to write the necessary assembler code to interface with the RPi4B firmware to decompile the address mapping and identify potential aggressor rows.
4. Once these barriers are overcome then the DRAM itself will be susceptible to rowhammer.

I'm not going to say that there's never going to be a rowhammer exploit for the RPi4B as the DRAM is inherently able to be bit-flipped. However, the barriers to implement this exploit are high and the exploit is not currently realistically feasible except on a root-compromised device, in which case the need for the exploit goes away as you have root access anyway.

Testing whether a system is vulnerable is different than an aggressor pulling off a successful attack. In the first case, loading a kernel module as root serves as a convenience to help determine whether the system is vulnerable; in the latter case, root access is not necessary because different combinations of virtual memory addresses can be guessed until some bit flips are observed.

I still think the way that memory is connected through the AXI bus and shared by the GPU might completely mitigate Rowhammer. It would be nice for a Raspberry Pi engineer to chime in with details about whether any stress testing was done and what the results were.

[jdb]

The RPi-4B firmware is proprietary and this means there isn't an easily documented path for a would-be attacker to write the necessary assembler code to interface with the RPi4B firmware to decompile the address mapping and identify potential aggressor rows.

There's no need to interface with the firmware to determine what the SDRAM page mapping is (and there isn't a function in there that will tell you anyway). It can be discovered via heuristics.

I still think the way that memory is connected through the AXI bus and shared by the GPU might completely mitigate Rowhammer. It would be nice for a Raspberry Pi engineer to chime in with details about whether any stress testing was done and what the results were.

All that's required for a rowhammer attack is an idle victim row and access to rows either side of it - bus infrastructure causes latency jitter, but doesn't modify the number of accesses to each row.

[hippy]

Given that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?

That's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.

While what you say is true in the legal world, in the scientific world we can be fairly sure that if a well-known problem is not reported on a well-known machine, either it was never present or it has been fixed.

More fallacy and I'm not convinced the scientific world would agree with you.

All anyone can tell you is "We don't know of a Rowhammer problem on the RPi4". That doesn't guarantee there really isn't.

Indeed.

[cleverca22]

some random notes that may help in either direction:

Code: Select all

[root@amd-nixos:~]# hexdump -C /proc/self/pagemap                                                                                                                                                                   
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|                                                                                                                                      
*                                                                                                                                                                                                                   
00002000  e0 cc 57 00 00 00 00 a1  e0 e3 4e 00 00 00 00 a1  |..W.......N.....|                                                                                                                                      
00002010  18 81 47 00 00 00 00 a1  fe b6 3f 00 00 00 00 a1  |..G.......?.....|                                                                                                                                      
00002020  e5 5c 4f 00 00 00 00 a1  30 0a 56 00 00 00 00 a1  |.\O.....0.V.....|                                                                                                                                      

using this file (root required) you can figure out what physical addr any virtual addr maps to
according to jdb, there is no way to map a physical addr to a row in the dram itself
i would assume that the mapping is going to be the same, for a given model/ramchip (check the revision code in /proc/cpuinfo to see who made the ram, how much ram, and board rev)
then you just brute-force to figure out what rows are near eachother, and if you can even rowhammer

but, even after you figure out the addr->row mappings, you need root to do virtual->physical, so your still screwed, if you had root, you dont need to rowhammer

[ejolson]

All that's required for a rowhammer attack is an idle victim row and access to rows either side of it - bus infrastructure causes latency jitter, but doesn't modify the number of accesses to each row.

That sounds like a plan. Now to find some students interested in computer hardware to give it a try.

Is it possible shared memory access by the GPU keeps all rows unusually fresh?

Is it possible memory access itself is so slow that you can't hammer fast enough for the targeted row to start leaking bits?

These are the questions that few people have the time to study or answer.

On a different note, the distance-learning version of defcon not held in Las Vegas this year finished without any spread of viruses either computer or biological. The content seemed meager and nobody spoke about rowhammering the Pi. I suspect like most conferences, the real work gets done outside the talks.

[frederick00]

I run some tests on Rpi4.
First i measured the execution time of the hammering loop because they ( http://www.vuse.vanderbilt.edu/~koutsox ... -zhang.pdf ) said : "if the time between two reactivations of an aggressor row is above 260 ns, it can barely trigger the rowhammer bug on ARM".
The loop is below the threshold so it is ok.
According to that paper, i am using STR + DC CVAC approach beacuse it should be the best way to exploit bit flips.

However the result is 0 bit flips.

[frederick00]

The RPi-4B firmware is proprietary and this means there isn't an easily documented path for a would-be attacker to write the necessary assembler code to interface with the RPi4B firmware to decompile the address mapping and identify potential aggressor rows.

There's no need to interface with the firmware to determine what the SDRAM page mapping is (and there isn't a function in there that will tell you anyway). It can be discovered via heuristics.

How can i do that ?

I still think the way that memory is connected through the AXI bus and shared by the GPU might completely mitigate Rowhammer. It would be nice for a Raspberry Pi engineer to chime in with details about whether any stress testing was done and what the results were.

All that's required for a rowhammer attack is an idle victim row and access to rows either side of it - bus infrastructure causes latency jitter, but doesn't modify the number of accesses to each row.