From: Pavel Machek <pavel@ucw.cz>
To: Bastien ROUCARIES <roucaries.bastien@gmail.com>, secure@intel.com
Cc: luto@amacapital.net, Mark Seaborn <mseaborn@chromium.org>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: DRAM unreliable under specific access patern
Date: Thu, 25 Dec 2014 10:23:14 +0100 [thread overview]
Message-ID: <20141225092314.GA20822@amd> (raw)
In-Reply-To: <CAE2SPAa-tBFk0gnOhEZiriQA7bv6MmL9HGqAMSceUKKqujBDPQ@mail.gmail.com>
On Thu 2014-12-25 09:26:41, Bastien ROUCARIES wrote:
> Le 25 déc. 2014 00:42, "Pavel Machek" <pavel@ucw.cz> a écrit :
> >
> > 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.
> >
>
> Ask a microcode update asking clflush to be penalized in userspace.
Indeed. Optionally making clflush priviledged intstruction, or
artifically make that instruction slower could do the trick.
Alternatively, lowering memory refresh intervals would reliably do the
same, but with bigger overhead. I guess documenting that controls for
common chipsets would do the trick, so kernel can adjust values before
starting userspace.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2014-12-25 9:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAL82V5NN8U4PyiSjLxgpTrgsgkbM7rRCbVF5P-HHyEqphLOy+g@mail.gmail.com>
2014-12-24 22:08 ` DRAM unreliable under specific access patern Pavel Machek
2015-01-05 19:23 ` One Thousand Gnomes
2015-01-05 19:50 ` Andy Lutomirski
2015-01-06 1:47 ` Kirill A. Shutemov
2015-01-06 1:57 ` Andy Lutomirski
2015-01-06 2:18 ` Kirill A. Shutemov
2015-01-06 2:26 ` Andy Lutomirski
2015-01-08 13:03 ` One Thousand Gnomes
2015-01-08 16:52 ` Pavel Machek
2015-01-09 15:50 ` Vlastimil Babka
2015-01-09 16:31 ` Pavel Machek
2015-01-06 23:20 ` Pavel Machek
2015-03-09 16:03 ` Mark Seaborn
2015-03-09 16:30 ` Andy Lutomirski
2015-03-09 21:17 ` Pavel Machek
2015-03-09 21:37 ` Mark Seaborn
2015-03-10 11:33 ` DRAM bug exploitable on 50% machines without ECC (was Re: DRAM unreliable under specific access patern) Pavel Machek
2014-12-24 22:27 ` DRAM unreliable under specific access patern Pavel Machek
2014-12-24 23:41 ` Pavel Machek
[not found] ` <CAE2SPAa-tBFk0gnOhEZiriQA7bv6MmL9HGqAMSceUKKqujBDPQ@mail.gmail.com>
2014-12-25 9:23 ` Pavel Machek [this message]
2014-12-28 22:48 ` Mark Seaborn
2014-12-24 16:38 Pavel Machek
2014-12-24 16:46 ` Pavel Machek
2014-12-24 17:13 ` Andy Lutomirski
2014-12-24 17:25 ` Pavel Machek
2014-12-24 17:38 ` Andy Lutomirski
2014-12-24 17:50 ` Pavel Machek
2014-12-29 12:13 ` Jiri Kosina
2014-12-29 17:09 ` Pavel Machek
2014-12-28 9:18 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141225092314.GA20822@amd \
--to=pavel@ucw.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mseaborn@chromium.org \
--cc=roucaries.bastien@gmail.com \
--cc=secure@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).