On 9/25/25 22:33, Jacob Bachmeyer wrote: > On 9/25/25 14:38, Demi Marie Obenour wrote: >> On 9/24/25 23:51, Jacob Bachmeyer wrote: >>> On 9/24/25 06:45, Peter Gutmann wrote: >>>> Jacob Bachmeyer<[email protected]> writes: >>>> >>>>> The critical issue for exploiting Rowhammer to corrupt spilled register >>>>> values seems to be how long those spilled values remain live in DRAM >>>>> before >>>>> they are reloaded into the register file and ultimately used. >>>> It also depends on whether they're ever actually read back from RAM or just >>>> end up sitting in cache for a microsecond or two before they're re-fetched >>>> from there. There are some attacks that exploit the difference between >>>> (glitched) data in RAM and data in cache, but in this case it'd mitigate >>>> Rowhammer by having the corrupted data in RAM ignored if it's still in >>>> cache. >>> Indeed, if the spilled value is never evicted from cache, then it is >>> never live in DRAM and Rowhammer cannot be used to corrupt it. However, >>> if I understand correctly, modern systems aggressively flush caches on >>> process context switches in order to close cache-related side channels. >>> >>> This seems to suggest that the solution to "Rowhammer Mayhem" may lie in >>> improvements to kernel scheduler and VM management subsystems. >> What about hardware fixes? Those will take a long time >> to roll out but hopefully they can be 100% effective. > > First, that does absolutely nothing for current hardware. Declaring all > (or almost all) current hardware e-waste is severely environmentally > irresponsible if it can possibly be avoided.
I don't know that it can be. > Second, I had expected ECC to "kill Rowhammer dead" only to find that it > can be possible to cause enough bit flips to get all the way from one > valid ECC word to another valid ECC word before ECC scrub reaches the > location. I suspect that the DDR5 built-in ECC is supposed to resolve > Rowhammer, but we will have to wait and see if it actually achieves that > goal. > > It seems highly likely that Rowhammer is an inherent consequence of DRAM > density beyond a certain limit and highly *unlikely* that reducing DRAM > density below the "Rowhammer threshold" will prove to be an acceptable > solution. See https://arxiv.org/pdf/2407.09995 for the proper solution: store a per-row activation counter alongside the row itself, and when any row in a bank exceeds the threshold, take action. >>> Perhaps a yield primitive that yields the rest of the current timeslice >>> but guarantees a full unpreemptable timeslice upon resume? That would >>> allow a brief sensitive computation to be effectively made >>> uninterruptible but would not permit monopolization of the processor. >>> >>> Perhaps more randomization in assigning physical page frames to prevent >>> the kernel from reliably using "bait" pages? The attack in the paper >>> seems to depend on predictable page frame allocation. >>> >>> The latter could also be implemented in user processes: allocate a >>> randomly-sized pad on the stack to shift "inner" stack variables away >>> from their predictable locations. Making the pad multiple pages plus a >>> fraction of a page could also counter predictable kernel page frame >>> allocations by shifting the sequence of pages allocated. >> One idea I had is to add physical guard pages >> between uses of memory for different purposes. > > That depends on assumptions about physical layout that may not hold. > (What if the DRAM is interleaved such that the guard pages end up in a > different bank or chip?) Apparently the researchers already had to hit > areas at some logical distance from the target; I doubt that the exact > physical DRAM layout in the chips they used is published. > > Worse, skipping page frames like this may work for one DRAM density and > silently fail for another, or even between two different chips with the > same density but different internal layouts, or even between identical > hardware that has different memory controller configurations for some > reason. > > > The stack is intrinsically aligned on much finer than page granularity; > introducing additional "jitter" to the locations of stack variables (and > spilled registers) is a solution available today with minimal cost. All > you need is "size_t slide_size=random_stack_slide_size(); void * > slide=alloca(slide_size); memset(slide,0,slide_size);" near the top of > main (and possibly other functions to "mix it up" more) and a function > random_stack_slide_size() that gives an appropriate unpredictable value. > > The key is to avoid trying to prevent bits from being flipped (that > proverbial ship has sailed on current hardware) but instead prevent an > attacker from being able to predict accomplishing something useful with > those bit-flips. I suspect that in general this is provably impossible. My hope is that EU regulations like CRA and PLD will force hardware recalls when defects like Rowhammer are detected. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
