Has anyone tested if the L5 is susceptible to any known Rowhammer bugs? For instance against the TRRespass? https://github.com/vusec/trrespass
If I understand this “Rowhammer” thing correctly, it is about tricks that a malicious program can use to gain access to parts of computer memory that it is not supposed to have access to. So for example, some program running in a sandbox that is supposed to be locked in there, can using such tricks reach outside of its sandbox.
Then, I would think that as a Librem 5 user I don’t need to worry too much about that, because the idea with the Librem 5 is to run only free software on it. That is my main line of defense here, I aim to not have any malicious programs running on my CPU. Android users might be more worried, if they have all kinds of unknown proprietary code running and they are relying on sandboxing to keep some things safe.
Does the above make sense, or have I misunderstood some part of this?
You’re not going to be limited to running Free Software only if you ever browse the web. The memory module on the L5 offers some self-refresh boost thingy to protect against rowhamer, at least on the data sheet. I don’t think its efficacy was tested.
6 Likes
There are variants of RH that work with JS in the browser. Basically everyone runs untrusted code while surfing the web. Hence I would not generally rule out that RH can be applied to the L5.
Edit: maybe @dcz’s answer can rule it out. I can’t judge.
1 Like
Yes the risk is that a remote hacker will gain full access to your L5. Like the other answers point out, there are many cases where open-source does not protect you. For instance, you read an email in your favorite open-source email reader that exploits your email process, and then from there the attacker runs a Rowhammer on the L5 and gains full access.
Ah, I forgot about that. So it is this issue again:
https://www.fsf.org/campaigns/freejs/
When looking to ensure that our computers are running free software, we usually turn our attention to the operating system and programs we install. Increasingly, we also need to look at the Web sites we visit. Simply visiting many sites loads software onto your computer, primarily JavaScript, that carry proprietary licenses. If we want to be able to browse the Web without running nonfree software, we need to work together to call for change.
1 Like
Please explain how that would work. I think I understand the javascript issue, but this is something else? How would my email reader (like Geary) get exploited?
Any data that you receive may exploit your computer or phone. It could be an email, a web-site, a video, an image, a text message, a phone call, really any data. How it works is quite difficult to explain in detail, but I’ll try a simple explanation using Geary.
You receive an email from a friend that contains an image. You open the email, and either Geary or you open the image to see it. To display it the computer needs to read the image and parse it. If there are bugs in the code or parser known by the attacker then the attacker can create (or craft like it is called in this context) an image that exploits this bug. This will give the attacker the same privileges as the exploited process. From there the attacker can use other bugs to escalate their privileges if they like.
Here is just one example. There are at least millions of these exploits out there, publicly know, privately known (undisclosed), or unknown.
Thanks for explaining what you meant, but this is no longer about Rowhammer but just the fact that attackers can exploit bugs, that is of course true but it is nothing new and not related to Rowhammer?
Suppose there are no exploitable bugs in Geary (or libraries etc that Geary uses) that the attacker knows about. Then I can read my emails safely?
1 Like
Yes, but the assumption should be that there are many of these bugs in Geary or in one of it’s dependencies, like png-parser, etc. Formal verification is the only thing that could fix the bug-problem.
The example is not about Rowhammer, but it could be. A correctly crafted image together with a certain type of bug could probably run a Rowhammer exploit. The easiest example though is the one already given, the browser and web-sites.
The point is that RH triggers physical effects to switch bit values in your devices memory. With this the attacker might overcome ordinary boundaries of protection.
To trigger this phyisical effect the attacker needs to write memory fast. This is done by some program code from the attacker.
If the attacker manages to run his malicious code, he triggers the effect, overcome the boundary and has more control over the system than he should.
1 Like
Maybe, but I am still interested in the perhaps unlikely scenario that we have a 100% bug-free and 100% FOSS software stack running on our computer/phone. From what I understand so far, in this scenario, it is safe to read emails but it is not safe to use a web browser unless we disable javascript. Did I get that right?
A doubtfully implemented email client might allow Javascript in HTML parts of the message (or even more weirdly an email client that directly allowed a message part that is Javascript).
There are many many exploits involving specially-crafted, usually malformed files targeting bugs in parsers or other file processing code. That affects web browsers as well as email clients.
Just about every file type (maybe excluding ASCII plain text 
) has had an exploit at some time or other on some platform. Everything from business cards to fonts.
1 Like
If the code is 100% bug-free then you may be safe, if the hardware is also bug-free. I wouldn’t call this assumption unlikely, I would call it very extremely unlikely 
At least for the following decades. It does not really have with open-source to do in this case, since you could have bug-free proprietary software. It is even possible to be able to verify that some properties hold for proprietary software by only inspecting the binary code. The open-source seL4 project has done that, verifying the binary implementation of a small OS.
1 Like
It really is the same case. Both scenarios deal with unknown (and possibly crafted) data being processed by some process.
In the case with a 100% bug-free software, together with the RH hardware bug, your computer can still be exploited with the RH bug. Either via javascript (like mentioned above), or any other thing you download that executes code. Could be a Word or Excel document for instance, and probably loads of other data formats.
Quoting from this paper: https://arxiv.org/pdf/1507.06955v1.pdf
Although our eviction-strategy-finding algorithm (pre-sented in Section III) works on different Intel CPUs, it isnecessary to evaluate how it performs on non-Intel platforms,e.g., AMD x86 or ARM CPUs. Modern smartphones havefast DRAM modules integrated and should be examined forpotential security risks.
Also:
While we implemented a successful attack in JavaScript in Firefox 39, the problem is bigger than that. First, we expect the attack to work in other browsers as well, if the JavaScript just-in-time compilation is as efficient. More general, the presented approach can be applied to any programming language and any runtime environment. If the memory is accessed in the same pattern and the frequency is high enough it will cause bit flips as well. We chose JavaScript because it can easily be executed by a remote attacker. However, other languages like ActionScript or server-side scripting languages could also be interesting targets for an attacker if they are translated to a native instruction stream by a compiler or JIT-compiler.
Speculating about possible solutions: To protect against such things, probably it would be a good idea to change those kinds of code execution to make it less efficient and generally further away from native code execution. For example they describe in that paper how they make use of that some Javascript memory allocations are known to end up at certain aligned memory addresses. That could probably be changed in the Javascript runtime implementation so that an attacker can no longer know how memory is aligned. Another thing would be to simply make Javascript code execution slower, basically saying that if you want high performance then you need to run native code.
Either that or fixing the problem with the hardware. The main question is still not answered, though, does the L5 suffer from this Rowhammer bug? Please post the results here if you try it. I may try it if I get some time.
1 Like
Interesting project. Please document your procedure as well as the results.
You should look if prior work on ARM systems has been done meanwhile. Maybe even something near the L5’s HW. Maybe you can take existing PoCs and adapt them.
Also keep in mind:
Maybe you can find out more.
edit: maybe it’s worth to read the papers of RH & Co.
Does ECC memory help mitigate rowhammer attacks?