Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Mar 2015 01:11:25 -0700
From:      Julian Elischer <julian@freebsd.org>
To:        freebsd-security@freebsd.org
Subject:   Re: DRAM Rowhammer exploits
Message-ID:  <54FFF8AD.90507@freebsd.org>
In-Reply-To: <alpine.BSF.2.00.1503092248580.38285@woozle.rinet.ru>
References:  <alpine.BSF.2.00.1503092248580.38285@woozle.rinet.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54FFF8AD.90507>