Message-ID: <20141224222700.GA19513@amd>
Date:	Wed, 24 Dec 2014 23:27:00 +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

On Wed 2014-12-24 11:47:50, Mark Seaborn wrote:
> Hi Pavel,
> 
> 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.
> 
> [Replying off-list just because I'm not subscribed to lkml and only saw
> this thread via the web, but feel free to reply on the list. :-) ]

Ok, so I thought my machine is too old to be affected. Apparently, it
is not :-(. (With rowhammer-test).

Iteration 140 (after 328.76s)
  48.805 nanosec per iteration: 2.1084 sec for 43200000 iterations
  check
  error at 0x890f1118: got 0xfeffffffffffffff
    (check took 0.244179s)
    ** exited with status 256 (0x100)

processor     : 1
vendor_id     : GenuineIntel
cpu family    : 6
model	      	: 23
model name	: Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
stepping	: 10
microcode	: 0xa07
cpu MHz		  : 1596.000
cache size	  : 3072 KB

								Pavel

> Cheers,
> Mark
> 
> Pavel Machek <pavel <at> ucw.cz> wrote:
> > On Wed 2014-12-24 09:13:32, Andy Lutomirski wrote:
> > > On Wed, Dec 24, 2014 at 8:38 AM, Pavel Machek <pavel <at> ucw.cz> wrote:
> > > > Hi!
> > > >
> > > > It seems that it is easy to induce DRAM bit errors by doing repeated
> > > > reads from adjacent memory cells on common hw. Details are at
> > > >
> > > > https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf
> > > >
> > > > . Older memory modules seem to work better, and ECC should detect
> > > > this. Paper has inner loop that should trigger this.
> > > >
> > > > Workarounds seem to be at hardware level, and tricky, too.
> > >
> > > One mostly-effective solution would be to stop buying computers
> > > without ECC.  Unfortunately, no one seems to sell non-server chips
> > > that can do ECC.
> >
> > Or keep using old computers .
> >
> > > > Does anyone have implementation of detector? Any ideas how to work
> > > > around it in software?
> > > >
> > >
> > > Platform-dependent page coloring with very strict, and impossible to
> > > implement fully correctly, page allocation constraints?
> >
> > This seems to be at cacheline level, not at page level, if I
> > understand it correctly.
> >
> > So the problem would is: I have something mapped read-only, and I can
> > still cause bitflips in it.
> >
> > Hmm. So it is pretty obviously a security problem, no need for
> > java. Just do some bit flips in binary root is going to run, and it
> > will crash for him. You can map binaries read-only, so you have enough
> > access.
> >
> > As far as I understand it, attached program could reproduce it on
> > affected machines?

-- 
(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