Message-ID: <20150108130325.0592b18b@lxorguk.ukuu.org.uk>
Date:	Thu, 8 Jan 2015 13:03:25 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"Kirill A. Shutemov" <kirill@...temov.name>,
	Pavel Machek <pavel@....cz>,
	Mark Seaborn <mseaborn@...omium.org>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: DRAM unreliable under specific access patern

On Mon, 5 Jan 2015 18:26:07 -0800
Andy Lutomirski <luto@...capital.net> wrote:

> On Mon, Jan 5, 2015 at 6:18 PM, Kirill A. Shutemov <kirill@...temov.name> wrote:
> > On Mon, Jan 05, 2015 at 05:57:24PM -0800, Andy Lutomirski wrote:
> >> On Mon, Jan 5, 2015 at 5:47 PM, Kirill A. Shutemov <kirill@...temov.name> wrote:
> >> > On Mon, Jan 05, 2015 at 11:50:04AM -0800, Andy Lutomirski wrote:
> >> >> On Mon, Jan 5, 2015 at 11:23 AM, One Thousand Gnomes
> >> >> <gnomes@...rguk.ukuu.org.uk> 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 ?
> >> >>
> >> >> Can you actually damage anyone else's data using a 1 GB hugepage?
> >> >
> >> > hugetlbfs is a filesystem: the answer is yes. Although I don't see the
> >> > issue as a big attach vector.
> >>
> >> What I mean is: if I map a 1 GB hugepage and rowhammer it, is it
> >> likely that the corruption will be confined to the same 1 GB?
> >
> > I don't know for sure, but it looks likely to me according to claim in the
> > paper (8MB). But it still can be sombody else's data: 644 file on
> > hugetlbfs mmap()ed r/o by anyone.

Thats less of a concern I think. As far as I can tell it would depend how
the memory is wired what actually gets hit. I'm not clear if its within
the range or not.

> > When I read the paper I thought that vdso would be interesting target for
> > the attack, but having all these constrains in place, it's hard aim the
> > attack anything widely used.
> >
> 
> The vdso and the vvar page are both at probably-well-known physical
> addresses, so you can at least target the kernel a little bit.  I
> *think* that kASLR helps a little bit here.

SMEP likewise if you were able to use 1GB to corrupt matching lines
elsewhere in RAM (eg the syscall table), but that would I think depend
how the RAM is physically configured.

Thats why the large TLB case worries me. With 4K pages and to an extent
with 2MB pages its actually quite hard to line up an attack if you know
something about the target. With 1GB hugepages you control the lower bits
of the physical address precisely. The question is whether that merely
enables you to decide where to shoot yourself or it goes beyond that ?

(Outside HPC anyway: for HPC cases it bites both ways I suspect - you've
got the ability to ensure you don't hit those access patterns while using
1GB pages, but also nothing to randomise stuff to make them unlikely if
you happen to have worst case aligned data).

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