lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 25 Dec 2014 00:41:44 +0100
From:	Pavel Machek <pavel@....cz>
To:	Mark Seaborn <mseaborn@...omium.org>,
	kernel list <linux-kernel@...r.kernel.org>
Cc:	luto@...capital.net
Subject: Re: DRAM unreliable under specific access patern

Hi!
> 
> Try this test program: https://github.com/mseaborn/rowhammer-test
> 
> It has reproduced bit flips on various machines.
> 
> Your program won't be an effective test because you're just hammering
> addresses x and x+64, which will typically be in the same row of DRAM.
> 
> For the test to be effective, you have to pick addresses that are in
> different rows but in the same bank.  A good way of doing that is just to
> pick random pairs of addresses (as the test program above does).  If the
> machine has 16 banks of DRAM (as many of the machines I've tested on do),
> there will be a 1/16 chance that the two addresses are in the same
> bank.

Ok. Row size is something like 8MB, right?

So we have a program that corrupts basically random memory on many
machines. That is not good. That means that unpriviledged user can
crash processes of other users. 

I relies on hammering DRAM rows so fast that refresh is unable to keep
data consistent in adjacent rows. It relies on clflush: without that,
it would likely not be possible to force fast enough row switches.

Unfortunately, clflush is not a priviledged instruction. Bad Intel.

Flushing cache seems to be priviledged on ARM (mcr p15). That means it
is probably impossible to exploit on ARM based machines.

We could make DRAM refresh faster. That will incur performance
penalty (<10%?), and is probably chipset-specific...?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists