On Wed, Mar 11, 2015 at 01:11:25AM -0700, Julian Elischer
wrote:> 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.
I just made somewhat dirty port of the double_sided program, available at
https://github.com/kostikbel/rowhammer-test/tree/freebsd
>From what I see, the fetched physical addresses of the mappings look
reasonable, e.g. they are continous for the promoted pages. Curiously,
my test haswell box does not trip the failure.
There is some weirdness either in the c++ code, or bug in the port, you
might need to use MALLOC_CONF=junk:false setting on head.