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.
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.
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
(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. 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.]
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.
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.
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.
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. But you cannot fix this.
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.