From: Pavel Machek <pavel@ucw.cz>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Mark Seaborn <mseaborn@chromium.org>,
kernel list <linux-kernel@vger.kernel.org>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Subject: Re: DRAM unreliable under specific access patern
Date: Mon, 9 Mar 2015 22:17:51 +0100 [thread overview]
Message-ID: <20150309211751.GA3991@amd> (raw)
In-Reply-To: <CALCETrVpNdkVH9wFrQbEdZFSP=oBbppBAp=vYdwnh2fycZwJ7g@mail.gmail.com>
On Mon 2015-03-09 09:30:50, Andy Lutomirski wrote:
> On Mon, Mar 9, 2015 at 9:03 AM, Mark Seaborn <mseaborn@chromium.org> wrote:
> > On 6 January 2015 at 15:20, Pavel Machek <pavel@ucw.cz> wrote:
> >> On Mon 2015-01-05 19:23:29, One Thousand Gnomes wrote:
> >> > > In the meantime, I created test that actually uses physical memory,
> >> > > 8MB apart, as described in some footnote. It is attached. It should
> >> > > work, but it needs boot with specific config options and specific
> >> > > kernel parameters.
> >> >
> >> > Why not just use hugepages. You know the alignment guarantees for 1GB
> >> > pages and that means you don't even need to be root
> >> >
> >> > In fact - should we be disabling 1GB huge page support by default at this
> >> > point, at least on non ECC boxes ?
> >>
> >> Actually, I could not get my test code to run; and as code from
> >>
> >> https://github.com/mseaborn/rowhammer-test
> >>
> >> reproduces issue for me, I stopped trying. I could not get it to
> >> damage memory of other process than itself (but that should be
> >> possible), I guess that's next thing to try.
> >
> > FYI, rowhammer-induced bit flips do turn out to be exploitable. Here
> > are the results of my research on this:
> > http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
> >
>
> IIRC non-temporal writes will force cachelines out to main memory
> *and* invalidate them. (I wouldn't be shocked if Skylake changes
> this, but I'm reasonably confident that it's true on all currently
> available Intel chips.)
>
> Have you checked whether read; read; nt store; nt store works?
>
> (I can't test myself easily right now -- I think my laptop is too old
> for this issue.)
Well, if you had laptop with that issue, it would still be tricky to
test this. It takes a while to reproduce...
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:[~2015-03-09 21:20 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 [this message]
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
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=20150309211751.GA3991@amd \
--to=pavel@ucw.cz \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mseaborn@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.