Dear colleagues, any thoughts we're vulnerable to this? http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------
-------- In message <alpine.BSF.2.00.1503092248580.38285 at woozle.rinet.ru>, Dmitry Morozo vsky writes:>Dear colleagues, > >any thoughts we're vulnerable to this?It's a hardware problem, *everybody* are vulnerable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
On 09/03/2015 20:49, Dmitry Morozovsky wrote:> Dear colleagues, > > any thoughts we're vulnerable to this? > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html >As pointed out is this a hardware originated problem, not really fixable by software. Only EEC should be able to catch this. Which is mostly used on hardware for servers. And luckily that is probably also the most likely platforms on which "unidentified third parties" can run this. As no sensible PAAS/Hardware provider would forgo the use of ECC. :) I would expect this type of test to appear in tools like memtest86. Giving you in indication in advance of the the possible problem. Next to that I see a few points where we could possibly mitigate this. As I read the article, the problem is not present if the refresh frequency is doubled. This sort of indicates that manufacturers are (a bit) to optimistic about the required RAM refresh cycles. 1) If possible reprogram the RAM referesh cycle time as it is setup by the BIOS. It will reduce the available memory by an unmeasurable fraction. 2) It would be possible to build a RAM refresh thread in the kernel reading every RAM memory within a certain time frame. Thus forgoing the refresh recycle time set by the BIOS. This will require some cycles in the kernel, costing some CPU and some memory bandwidth. Big disadvantage could be that it will cause some serious thrashing of the cache content if these writes go thru the cache flowed by a cacheflush. --WjW
On Mon, Mar 9, 2015 at 8:49 PM, Dmitry Morozovsky <marck at rinet.ru> wrote:> Dear colleagues, > > any thoughts we're vulnerable to this?In memtest86 exists a rowhammer test - http://www.passmark.com/forum/showthread.php?4836-MemTest86-v6-0-Beta-%282015-02-13-Update-Beta-testing-is-now-closed%29 .> > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck at FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > freebsd-security at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
On 3/9/15 12:49 PM, Dmitry Morozovsky wrote:> Dear colleagues, > > any thoughts we're vulnerable to this? > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html >one important part of this exploit is the following part: ---quote--- How can we pick pairs of addresses that satisfy the ?different row, same bank? requirements? One possibility is to use knowledge of how the CPU?s memory controller maps physical addresses to DRAM?s row, column and bank numbers, along with knowledge of either: * The absolute physical addresses of memory we have access to. Linux allows this via /proc//PID//pagemap. * The relative physical addresses of memory we have access to. Linux can allow this via its support for ?huge pages?, which cover 2MB of contiguous physical address space per page. Whereas a normal 4k page is smaller than a typical DRAM row, a 2MB page will typically cover multiple rows, some of which will be in the same bank. ---end quote--- I don't know of a similar source of that information in FreeBSD, though near the start of operation one might be able to make a good guess about memory allocation, until ram got too scrambled.. the "superpages" point would be true in freeBSD as well, tough I 'm not sure how you;d know you had a superpage, but you might be able to do something (file size?) that might make it likely. Of course in their first attack it's the location of the data but the location of the page table entry that's important. that might be more easily worked out if you allocated a large enough chunk of memory while memory is still predictable.