Large memory Row hammer defense?

[cubem...@gmail.com]

Just a thought that might have been considered before, in the absence of ECC RAM (now available with Xeon mobile processors, but which isn't 100% effective against RH anyhow) what about RAM pinning or spreading for VM's in prevention of Row hammer attacks? Consider a 32 GB computer, spreading VM's across the physical memory space (e.g. onto four DIMM's) would seem to mitigate the problem. Maybe there's something obvious I'm missing here.

A side question is how feasble row hammer is on Qubes anyhow, since it seems to depend on privilege escalation.

[Radoslaw Szkodzinski]

On Thu, Nov 12, 2015 at 6:53 PM, <cubem...@gmail.com> wrote:
> A side question is how feasble row hammer is on Qubes anyhow, since it seems
> to depend on privilege escalation.

No it doesn't. A valid attack proof of concept has been implemented in
Javascript in Firefox recently. [1] That said, this kind of attack
cannot escape the targeted VM easily, as Xen generally attempts to
provide contiguous memory mappings to the VM for performance reasons.

Frontcache (part of tmem), which is currently not used in Qubes, would
make an attack easier by deduplicating pages - you could damage a
deduplicated page, attacking multiple VMs simultaneously, maybe even
dom0. Another possible attack is on the ballooning interface, which
should be very hard to pull off if not impossible if memory scrubbing
is enabled - it is in Qubes dom0 kernel.

Theoretically, an attempt could be made to make dom0 execute
operations in a way that triggers row hammering. Quite hard but not
impossible - you'd need to somehow break the Xen grant table with it,
paravirt backends and/or one of the Qubes communication daemons.

Generally DoS is much easier to trigger than actual privilege
escalation, which makes the latter additionally tricky.

Ivy Bridge and newer memory controllers have hardware mitigation of
this kind of attack with newer DDR3 chips which support pseudo-Target
Row Refresh - and DDR4 is proof against it as it requires Target Row
Refresh instruction when used properly by the memory controller, but
it's still very new - available in Haswell-EX and Skylake. Best
recommendation will be to test if the problem exists and update your
firmware or hardware if it's broken - memtest has a test specifically
for it now.

[1] "Rowhammer.js: A Remote Software-Induced Fault Attack in
JavaScript", http://arxiv.org/pdf/1507.06955v1.pdf

--
Radosław Szkodziński