Manufacturers aren’t held liable for negligence like this. It’s a classic case of economic externality.

> manufacturers and customers deciding they don't want to pay

It's more of a tragedy-of-the-commons problem. Consumers don't know what they don't know and manufacturers need to be competitive with respect to each other. Without some kind of oversight (industry standards bodies or goverment regulation), or a level of shaming that breaks through to consumers (or e.g. class action lawsuits that impact manufacturers), no individual has any incentive to change.

We don't want "mitigation", we want true correctness --- or at least the level of perfection achievable before manufacturers thought they could operate with negative data integrity margins and convinced others that it was fine (one popular memory testing utility made RH tests optional and hidden by default, under the reasoning that "too many DIMMs would fail"!) All DRAM generations before DDR2 and early DDR3 didn't have this problem.

RAM that doesn't behave like RAM is not RAM. It's defective. ECC is merely an attempt at fixing something that shouldn't've made it to the market in the first place. AFAIK there is a RH variant that manages to flip bits undetectably even with ECC RAM.

The manufacturers chose this. Most customers were not offered a choice.

It should be considered unethical to sell machines with non-ECC memory in any real volume.

I'm coming back to note: die shrinks, density increase, and frequency increases- while keeping costs from going out of control all work together to make rowhammer inevitable. I maintain they knew about it, dismissed it as impractical, tested if it was a concern in normal usage... and were surprised + hobbled by their pants, when a PoC hit the public.

I'm not versed in silicon fabrication to know if theres ameliorations involved past what hit the press near 20 years ago now. But, while deep diving modern DRAM for an idea, its shocking how small a change is needed to corrupt a Bit in DRAM.

Rowhammer allows you to corrupt/alter memory physically adjacent to memory you have access to. It doesn't let you read the memory you're attacking.

There's PoC's of corrupting memory _that the kernel uses to decide what that process can access_ but the process can't read that memory. It only knows that the kernel says yes where it used to say no. (Assuming it doesn't crash the whole machine first)

This is for customers. AWS can use virtualization to slice their GPUs across multiple workloads (in their K8s), but AWS itself doesn't share GPUs.

That is partly due to artificial reasons and partly due to technical reasons. The artificial reasons would be that the 8200 MT/sec UDIMMs are overclocked. Notice how they run much slower if you do not enable XMP/EXPO, which simultaneously over volts and overclocks them. These exist because a large number of people liked overclocking their memory modules to get better performance. This was unreliable and memory manufacturers noticed that there was a market for a premium product where the overclocking results were guaranteed. Early pre-overclocked modules required people to manually enter the manufacturer provided voltage, frequency and timings into the BIOS, but XMP and later EXPO were made to simplify this process. This idea only took off for non-ECC modules, since the market for ECC UDIMMs wants reliability above all else, so there never was quite the same market opportunity to sell ECC DIMMs that were guaranteed to overclock to a certain level outside of the memory IC maker’s specifications.

There is no technical reason why ECC UDIMMs cannot be overclocked to the same extent and ECC actually makes them better for overclocking since they can detect when overclocking is starting to cause problems. You might notice that the non-ECC UDIMMs have pads and traces for an additional IC that is present on ECC UDIMMs. This should be because the ECC DIMMs and non-ECC DIMMs are made out of the same things. They use the same PCBs and the same chips. The main differences would be whether the extra chips to store ECC are on the module, what the SPD says it is and what the sticker says. There might also be some minor differences in what resistors are populated. Getting back to the topic of overclocking, if you are willing to go back to the days before the premium pre-overclocked kits existed, you will likely find a number of ECC UDIMMs can and will overclock with similar parameters. There is just no guarantee of that.

As for RDIMMs having higher transfer rates, let us consider the differences between a UDIMM, a CUDIMM and a RDIMM. The UDIMM connects directly to the CPU memory controller for the clock, address, control and data signals, while the RDIMM has a register chip that buffers the clock, address and control signals, although the data signals still connect to the memory controller directly. This improves signal integrity and lets more memory ICs be attached to the memory controller. A recent development is the CUDIMM, which is a hybrid of the two. In the CUDIMM, the clock signal is buffered by a Client Clock Driver, which does exactly what the register chip does to the clock signal in RDIMMs. CUDIMM are able to reach higher transfer rates than UDIMMs without overclocking because of the Client Clock Driver, and since RDIMMs also do what CUDIMMs do, they similarly can reach higher transfer rates.

You assume that the ECC is not already calculated when the data is in the cache (and the cache line is marked dirty). Caches in CPUs are often ECC protected, regardless of whether the memory has ECC pritection. The cache should already have the ECC computation done. Writes to ECC memory can simply reuse the existing ECC bytes from the cache, so no additional calculation time is needed on writes. Reads are where additional time is needed in the form of one cycle and if your cache is doing its job, you won’t notice this. If you do notice it, your cache hit rate is close to 0 and your CPU is effectively running around 50MHz due to pipeline stalls.

That said, this is tangential to whether the ECC DIMMs themselves run at lower MT/sec ratings with higher latencies, which was the original discussion. The ECC DIMM is simply memory. It has an extra IC and a wider data bus to accommodate that IC in parallel. The chips run at the same MT/sec as the non-ECC DIMM in parallel. The signals reach the CPU at the same in both ECC DIMMs and non-ECC DIMMs, such that latencies are the same (the ECC verification does use an extra cycle in the CPU, but cache hides this). There are simply more data lanes with ECC DIMMs due to the additional parallelism. This means that there is more memory bandwidth in the ECC DIMM, but that additional memory bandwidth is being used by the ECC bytes, so you never see it in benchmarks.

The kind of ECC that’s used for register file and memory protection is trivial to compute and completely in the noise in terms of area. It is essentially free.

The reason people say ECC is not free is because it added area for every storage location, not because of the ECC related logic.

(1) go for the root page table protection/ownership bits? These are often predictably located(but don't have to be). But getting access near them probably seems difficult.

If a task has been granted native GPU access then it's already on the inside of the security boundary. Conversely, if you don't trust a task then don't let it access the GPU (aside from passing the entire device through to a virtual machine). This attack doesn't change that reality.

Fine-grained machine code is likely to build more efficient/successful exploit.

But the goal I guess is to run that in one of the whatng cartel web engines (aka "sneaky" javascript), which are by themselves a security flaw already...