linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Andy Lutomirski <luto@amacapital.net>
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: DRAM unreliable under specific access patern
Date: Wed, 24 Dec 2014 18:25:06 +0100	[thread overview]
Message-ID: <20141224172506.GA23683@amd> (raw)
In-Reply-To: <CALCETrW8nrKSZ800C+WaHMK4DCuWnD9TG3dYo7cZwm5j4CpNJQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

On Wed 2014-12-24 09:13:32, Andy Lutomirski wrote:
> On Wed, Dec 24, 2014 at 8:38 AM, Pavel Machek <pavel@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?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: disturb.c --]
[-- Type: text/x-csrc, Size: 803 bytes --]

/* -*- linux-c -*-
 * 
 * Try to trigger DRAM disturbance errors, as described in
 *
 * https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf
 *
 * Copyright 2014 Pavel Machek <pavel@ucw.cz>, GPLv2+.
 */

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void disturb(char *where)
{
	unsigned int i;
	for (i=0; i<0x1000000; i++) {
		__asm__ __volatile__(
			"movl 0(%0), %%eax 		\n"	\
			"movl 64(%0), %%eax		\n"	\
			"clflush 0(%0)			\n"	\
			"clflush 64(%0)			\n"	\
			"mfence"
			:: "r" (where)
			: "eax"
			);
	}
}

int main(int argc, char *argv[])
{
	long size = 1*1024*1024;
	long i;
	unsigned char *mem;
	
	mem = malloc(size);
	memset(mem, 0xff, size);

	for (i=0; i<128; i+=4)
		disturb(mem+i);

	for (i=0; i<size; i++)
		if (mem[i] != 0xff)
			printf("At %lx, got %x\n", i, mem[i]);
}

  reply	other threads:[~2014-12-24 17:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-24 16:38 DRAM unreliable under specific access patern Pavel Machek
2014-12-24 16:46 ` Pavel Machek
2014-12-24 17:13 ` Andy Lutomirski
2014-12-24 17:25   ` Pavel Machek [this message]
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
     [not found] <CAL82V5NN8U4PyiSjLxgpTrgsgkbM7rRCbVF5P-HHyEqphLOy+g@mail.gmail.com>
2014-12-24 22:08 ` 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
2014-12-24 22:27 ` 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

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=20141224172506.GA23683@amd \
    --to=pavel@ucw.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /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).