From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 21:38:36 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1DE727F for ; Mon, 9 Mar 2015 21:38:36 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D83919B for ; Mon, 9 Mar 2015 21:38:35 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 13FF416A407; Mon, 9 Mar 2015 22:38:32 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsILcy1WiAnh; Mon, 9 Mar 2015 22:38:21 +0100 (CET) Received: from [192.168.10.211] (unknown [192.168.10.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 4B69A16A402; Mon, 9 Mar 2015 22:38:21 +0100 (CET) Message-ID: <54FE12CE.1000401@digiware.nl> Date: Mon, 09 Mar 2015 22:38:22 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dmitry Morozovsky , freebsd-security@FreeBSD.org Subject: Re: DRAM Rowhammer exploits References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Mon, 09 Mar 2015 21:38:36 -0000 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