To find out
what row hammering is please read this projectzero (http://googleprojectzero.blogspot.de/)blog
from Google. Unfortunately I’m extremely busy at the moment so I’ll have to
follow up on this post later with code. My initial thought where that not
only the clflush instruction would be
able to trigger this problem but also the non-temporal mov instructions and
unlike clflush these instructions are very useful in user mode. Say if you’re
decoding 4k video or running video filtering as you go these are instructions
you’ll find quite useful in optimizing your code. Also the clflush instruction
can only be banned in good sandboxes as google did for theirs. Unfortunately
bad sandboxes and real computers remain vulnerable.
The fix I’d
like to propose is to use the performance counters in the intel cpu.
Essentially they allow ring 0 code to trigger an interrupt on performance events
by setting a model specific register in the CPU. Row hammer is essentially
hammering away on the memory and this is bound to generate performance events. In
fact it’ll light up performance counting like a Christmas tree. Such events are
counted internally and are made so that an interrupt can be generated once this
counter overflows. This provides a defense strategy on two levels. One the
performance counting in and interrupt generation is costly time wise lowering
the frequency with which the ram is being hammered. Second and most importantly
it’ll give a direct pointer to the code that generated the event which can then
be checked for offending instruction and behavior. Obviously the down side is
that there will be a performance penalty for using performance counting to this
method.
I’ve still
got lots of work to do on this:
-
Write
proof of concept code.
-
Figure
out which performance counter is best
-
And
estimate the performance cost
Performance
counters are described in Intel Architecture Software Developer’s Manual,
Volume 3, chapter 15.
No comments:
Post a Comment