From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 18:13:58 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0282C18E for ; Wed, 11 Mar 2015 18:13:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E37F6E2 for ; Wed, 11 Mar 2015 18:13:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2BIDk4R082326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Mar 2015 20:13:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2BIDk4R082326 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2BIDkr1082325 for freebsd-security@freebsd.org; Wed, 11 Mar 2015 20:13:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Mar 2015 20:13:46 +0200 From: Konstantin Belousov To: freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits Message-ID: <20150311181346.GH2379@kib.kiev.ua> References: <54FFF8AD.90507@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FFF8AD.90507@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:13:58 -0000 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.