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]);
}
next prev parent 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).