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. > 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. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
