Hacker News
points by spwa4 1 day ago | 0 comments
One thing I don't understand about security issues. If you look at the physics the rowhammer "bug" is not a cpu flaw, and not really a memory flaw either. This was known when capacitor based memory was invented, and was put forward as a disadvantage in the very first designs. It's physics. If you do any kind of DDR ram (including, I think, HBM), there is no way to avoid rowhammer-style bit flips. And fixed systems ... aren't fixed. Not even fixed systems currently being built.

Capacitor based memory will be, and will remain, vulnerable to this. Capacitors being charged and discharged will generate radio waves and radio waves will change the state of other capacitors. There is no avoiding this, there is only minimizing it, and at the scales we're talking about, there's only minimizing it somewhat.

There are probably a lot of patterns we haven't seen yet. Like memory write patterns that change other memory by having the waves interfere.

You can only make it more difficult by thinking better about memory layout, and change it a bit by thinking about the physical layout of memory cells. But you're only changing the patterns. It's not possible to prevent it. You cannot fix this. Not now, not yesterday, not in 100 years.

It's currently too difficult for human to think about (even though people are slowly publishing about yet another system being vulnerable to rowhammer style attacks that work a little different from the existing ones)

So why isn't it "game over", at least for the web, for phones and apps, for ...? That bug isn't solved an nothing short of switching everything to SRAM, at incredible cost, will fix it, not just in legacy systems, but new systems too, now and in the future.

[–] bcrl 1 day ago
Rowhammer is most certainly a hardware flaw. DRAM manufacturers have pushed cells too close together to meet the specifications claimed on their datasheets. Increasing cell sizes would be the correct hardware fix for the issue. Engineering is accepting the reality of physics to build things that are useful.

Unfortunately, we live in a world where the few percentage points on the production cost of DRAM needed to completely mitigate rowhammer is sufficient to ensure that defective DRAM continues to be sold well after the industry became aware of the problem. This is one of the instances where a class action lawsuit might actually do some good.

[–] spwa4 1 day ago
> Increasing cell sizes would be the correct hardware fix for the issue. Engineering is accepting the reality of physics to build things that are useful.

Which they're not doing, in fact they're doing the opposite since what you're suggesting is both expensive and makes things (a lot slower). Oh and while I'm complaining: thousands of people are investigating how to place DDR much closer to other logic that also emits radio waves.

Oh ... and even if you did move the capacitors apart, that would make it more difficult. But by using more cells to hammer you can still make it fail. That would even be counterbalanced because the frequency needed for triggering rowhammer would go down as well, so it'd be a more forgiving environment for exploits.

[–] bcrl 1 day ago
Recent generations of DRAM have barely shrunk feature sizes. DRAM hit the scaling wall before logic exactly because you cannot physically make capacitors much smaller without losing the charge faster and driving up the amount of time spent [wasted] on refresh. The only reason newer DDR standards are "faster" is that they have:

    1. increased the frequency of the interface (mostly in the phy / logic part of a DRAM)
    2. increased the number of banks within a single die
    3. split the 64 bit channel on a single DIMM into 2 x independent 32 bit channels
Of those, (1) benefits somewhat from a die shrink. (2) doesn't need smaller features, and (3) is completely orthogonal to die shrinks since it's entirely contained in the PCB design.

(1) is the biggest problem for DRAM performance scaling, and that's because the legacy of DIMMs is awful from a signal integrity perspective. As signals go above 10Gbps/pin, the length of stubs begin to impact signal integrity, and traditional DIMM sockets have pins going all the way through a motherboard. This is why LPCAMM and LPCAMM2 exist: to improve signal integrity, but LPCAMM2 is not yet widely adopted on desktops and servers.

FYI: DDR5 wasted logic on DRAM for latency increasing crappy on-die ECC (Error Checking and Correcting) because DRAM vendors are unwilling to make the correct engineering trade-offs to build reliable DRAM. As DRAM processes are not exactly great for logic, this makes little sense to me as I am a firm believer that DRAM should stick to being memory and let the memory controller and CPU / GPU vendor implement ECC instead of allowing DRAM to lie about how reliable it is.

If you really want to improve DRAM performance, do what the Chinese fabs are doing: build layers. Making use of the third dimension reduces wire length, lets DRAM manufacturers use larger capacitors resulting in higher reliability and reduced refresh frequency. Layers have been used in flash production for more than a decade now, and due to trade restrictions on EUV fabs, China has been pursuing 3D scaling aggressively. There is no reason that DRAM stacking should be limited to HBM attached to specialty SKUs of FPGAs and GPUs.

Speaking of HBM, HBM takes the approach of using a very wide bus (1024+ bits) at a much lower clock speed tp achieve high bandwidths (which makes maintaining signal integrity a lot easier). With LPCAMM style DRAM modules, increasing the width of DRAM busses becomes much less daunting compared to DIMM style PCB modules.

So, no, I don't think that increasing cell sizes in DRAM is a major pain for DRAM manufacturers. I think it's time that the customers speak up and refuse to accept marginal failure prone DRAM chips from vendors that value profit over a solidly engineered product.

[Side note: several papers have mentioned that not all DRAM manufacturers are vulnerable to rowhammer attacks.]

[–] GuB-42 1 day ago
Security works by layers.

The physics makes the rowhammer impossible to fix in practice, but you can add various mitigations: scrambling, ECC, detection and response, etc... On the application level, you can also make it so that it is not possible to do a rowhammer in the first place. Fix everything that can be fixed and mitigate what can't be fixed.

And there is another security issue that can't be fixed, and is much worse than rowhammer: people. But we can't remove people, just like we can't remove DRAM for the performance level we need, so we mitigate the risk. It is not game over because we have other layers of security.

[–] spwa4 1 day ago
How do you decide what risks you can just leave open? Because that's what you're doing. The only thing that protects us from targeted rowhammer exploits for your hardware is our ability to research and write exploits ...
[–] GuB-42 1 day ago
I don't decide, doing anything involve some risks, some of them can't be eliminated. Or, I guess I can decide to not do anything, but it won't get me anywhere.

To go back with the human analogy. I have a server in a datacenter, there is a weakness in that someone can go to the machine physically and do nasty stuff, including hitting it with a literal hammer. This is a risk, but I can't do anything about it. Someone has to do the maintenance. But it can be mitigated with access control to the datacenter, among other things.

If the door to the server room can be opened with a toothpick, that's a vulnerability and it has to be fixed, because to "real" solution of not letting anyone in is not viable. I didn't chose to let people in the server room, it is just impossible not to.

[–] Veserv 1 day ago
Because software defects are more common, easier to exploit, faster to exploit, cheaper to find, and massively more consistent to leverage.

If software improved to the degree that hardware and physics-level exploits were the easier, we would be in a world 100x more secure than what we have now.

The real question you should be asking is why is it not “game over” right now given that most people would only hope in their wildest dreams that they would be so lucky that worrying about Rowhammer and the like would be a good use of time compared to the other much larger gaping software holes.