Rowhammer on Rp4
Posted: Sun Aug 09, 2020 5:55 pm
Hi Everyone,
Is Rp4 affected by Rowhammer ? and is there someone working on it ?
Thank You.
Is Rp4 affected by Rowhammer ? and is there someone working on it ?
Thank You.
A small, affordable computer with free resources to help people learn, make things, and have fun
https://www.raspberrypi.org/forums/
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=282326
I did it, but there are few posts which fosused on older Rp.davidcoton wrote: ↑Sun Aug 09, 2020 9:02 pmSearch "Rowhammer" on the Forum.It will tell you all that anyone here knows.
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.frederick00 wrote: ↑Mon Aug 10, 2020 10:16 amI did it, but there are few posts which fosused on older Rp.davidcoton wrote: ↑Sun Aug 09, 2020 9:02 pmSearch "Rowhammer" on the Forum.It will tell you all that anyone here knows.
Given that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?frederick00 wrote: ↑Mon Aug 10, 2020 10:16 amI did it, but there are few posts which fosused on older Rp.davidcoton wrote: ↑Sun Aug 09, 2020 9:02 pmSearch "Rowhammer" on the Forum.It will tell you all that anyone here knows.
That's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.davidcoton wrote: ↑Mon Aug 10, 2020 1:35 pmGiven that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?
I agree with you. I'd like to talk to someone who is working on it.hippy wrote: ↑Mon Aug 10, 2020 2:42 pmThat's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.davidcoton wrote: ↑Mon Aug 10, 2020 1:35 pmGiven that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?
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.DougieLawson wrote: ↑Mon Aug 10, 2020 11:44 amI 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.frederick00 wrote: ↑Mon Aug 10, 2020 10:16 amI did it, but there are few posts which fosused on older Rp.davidcoton wrote: ↑Sun Aug 09, 2020 9:02 pmSearch "Rowhammer" on the Forum.It will tell you all that anyone here knows.
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.hippy wrote: ↑Mon Aug 10, 2020 2:42 pmThat's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.davidcoton wrote: ↑Mon Aug 10, 2020 1:35 pmGiven that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?
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.moriartynz wrote: ↑Tue Aug 11, 2020 2:53 amMost 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:
- The current ARM-v8 test exploit requires root privileges to obtain physical-to-DRAM address mapping.
- The ARM-v8 exploit also requires root privileges to find appropriate aggressor rows.
- 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.
- 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.
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.moriartynz wrote: ↑Tue Aug 11, 2020 2:53 am
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.
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.ejolson wrote: ↑Tue Aug 11, 2020 3:31 am
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.
More fallacy and I'm not convinced the scientific world would agree with you.davidcoton wrote: ↑Mon Aug 10, 2020 10:46 pmWhile 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.hippy wrote: ↑Mon Aug 10, 2020 2:42 pmThat's a classic 'logical fallacy'. Absence of evidence is not evidence of absence.davidcoton wrote: ↑Mon Aug 10, 2020 1:35 pmGiven that there are millions of Pi "out there", does the lack of posts not suggest a lack of a problem?
Indeed.davidcoton wrote: ↑Mon Aug 10, 2020 10:46 pmAll anyone can tell you is "We don't know of a Rowhammer problem on the RPi4". That doesn't guarantee there really isn't.
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.....|
That sounds like a plan. Now to find some students interested in computer hardware to give it a try.
jdb wrote: ↑Tue Aug 11, 2020 7:38 amThere'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.moriartynz wrote: ↑Tue Aug 11, 2020 2:53 am
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.
How can i do that ?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.ejolson wrote: ↑Tue Aug 11, 2020 3:31 am
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.