From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 23:00:57 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 041E9CDE for ; Mon, 9 Mar 2015 23:00:57 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 B22B9FB3 for ; Mon, 9 Mar 2015 23:00:56 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 435C216A404; Tue, 10 Mar 2015 00:00:52 +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 9NUoGszHdpAg; Tue, 10 Mar 2015 00:00:24 +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 0EE7E16A406; Tue, 10 Mar 2015 00:00:24 +0100 (CET) Message-ID: <54FE2608.2080202@digiware.nl> Date: Tue, 10 Mar 2015 00:00:24 +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: Bakul Shah , Poul-Henning Kamp Subject: Re: DRAM Rowhammer exploits References: <91440.1425930724@critter.freebsd.dk> <20150309202308.64DFBB82A@mail.bitblocks.com> <70815.1425933979@critter.freebsd.dk> <20150309213702.B07A6B827@mail.bitblocks.com> In-Reply-To: <20150309213702.B07A6B827@mail.bitblocks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org, Dmitry Morozovsky 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 23:00:57 -0000 On 09/03/2015 22:37, Bakul Shah wrote: > On Mon, 09 Mar 2015 20:46:19 -0000 "Poul-Henning Kamp" wrote: >> -------- >> In message <20150309202308.64DFBB82A@mail.bitblocks.com>, Bakul Shah writes: >>> On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" >> wrote: >> >>> Hopefully ECC memory protects against such exploits (at least >>> makes them a lot less vulnerable). >> >> ECC only makes it harder, it doesn't make it impossible. > > According to the small sample in the paper below, the > incidence of 3 bit errors is about 4000 times or more lower > than single bit errors. These are the errors that may not > even get detected by ECC. So not impossible but much better. ECC does not only correct bit errors, it also allows one the detect them. Perhaps a good reason to start watching the reports about them.. And how many bit do I need to change to actually do something usefull? > It also proposes a few solutions. It seems to indicate that > reducing refresh time by a factor of 7 (over 64ms) removes > such errors. Hopefully this can be done via a firmware > upgrade? That was my suggestion 1. Up the refresh frequency. Might require the manufacturer, but could very well be done by the kernel if it knew how,what,where to write this. > I don't know if the physical page pool for kernel data can be > isolated enough from user data to avoid this. [Probably not. > Likely there is no standard way to do map a phys addr to a > specific chip/row and diff. mfrs may use diff geometries. > Though, perhaps this same phenomenon can be used to infer chip > geometry!] Isn't this what the RAM chip info tells us? And RAM does not move around in the physical address space. So creating a mapping where virtual = physical (perhaps even offsetted into an empty block in the vast 2^64 bits address space) would allow the refresh tread to do its work. But creating that mapping while running in kernelmode could be not so easy. --WjW