On Mon 2015-03-09 09:03:18, Mark Seaborn wrote:
> On 6 January 2015 at 15:20, Pavel Machek wrote:
> > On Mon 2015-01-05 19:23:29, One Thousand Gnomes wrote:
> > Actually, I could not get my test code to run; and as code from
> >
> > https://github.com/mseaborn/rowhammer-test
> >
> > reproduces iss
On 9 March 2015 at 14:17, Pavel Machek wrote:
> On Mon 2015-03-09 09:30:50, Andy Lutomirski wrote:
>> On Mon, Mar 9, 2015 at 9:03 AM, Mark Seaborn wrote:
>> > On 6 January 2015 at 15:20, Pavel Machek wrote:
>> >> Actually, I could not get my test code to run; and as code from
>> >>
>> >> https:/
On Mon 2015-03-09 09:30:50, Andy Lutomirski wrote:
> On Mon, Mar 9, 2015 at 9:03 AM, Mark Seaborn wrote:
> > On 6 January 2015 at 15:20, Pavel Machek wrote:
> >> On Mon 2015-01-05 19:23:29, One Thousand Gnomes wrote:
> >> > > In the meantime, I created test that actually uses physical memory,
> >
On Mon, Mar 9, 2015 at 9:03 AM, Mark Seaborn wrote:
> On 6 January 2015 at 15:20, Pavel Machek 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 attache
On 6 January 2015 at 15:20, Pavel Machek 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 c
Hi!
> Then it's also quite trivial to induce cache misses without clflush, using
> just
> few addresses that map to the same cache set, without having to cycle throuh
> more memory than the cache size is.
Hmm. If you can do "clflush" without "clflush", and result is no more
then 10 times slower
On 01/08/2015 02:03 PM, One Thousand Gnomes wrote:
> On Mon, 5 Jan 2015 18:26:07 -0800
> Andy Lutomirski wrote:
>
> 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
On Thu 2015-01-08 13:03:25, One Thousand Gnomes wrote:
> On Mon, 5 Jan 2015 18:26:07 -0800
> Andy Lutomirski wrote:
> > > 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
On Mon, 5 Jan 2015 18:26:07 -0800
Andy Lutomirski wrote:
> On Mon, Jan 5, 2015 at 6:18 PM, Kirill A. Shutemov
> 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
> >> wrote:
> >> > On Mon, Jan 05, 2015 at 11:50:
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.
>
> Wh
On Mon, Jan 5, 2015 at 6:18 PM, Kirill A. Shutemov 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
>> wrote:
>> > On Mon, Jan 05, 2015 at 11:50:04AM -0800, Andy Lutomirski wrote:
>> >> On Mon, Jan 5, 2015 at 11:23 AM
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
> 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
> >> wrote:
> >> >> In the meantime, I cre
On Mon, Jan 5, 2015 at 5:47 PM, Kirill A. Shutemov 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
>> wrote:
>> >> In the meantime, I created test that actually uses physical memory,
>> >> 8MB apart, as described in
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
> 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
On Mon, Jan 5, 2015 at 11:23 AM, 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.
>
> W
> 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
On Mon 2014-12-29 13:13:17, Jiri Kosina wrote:
> On Wed, 24 Dec 2014, Pavel Machek wrote:
>
> > Well... We could periodically scrub (every few miliseconds) pages
> > mapped to userspace.
>
> I.e. implement ECC in software. Would be extremely slow though.
No, not really. If you read the cells th
On Wed, 24 Dec 2014, Pavel Machek wrote:
> Well... We could periodically scrub (every few miliseconds) pages
> mapped to userspace.
I.e. implement ECC in software. Would be extremely slow though.
> We might be able to do some magic and disallow cache flushes to
> userspace programs.
My under
On 24 December 2014 at 15:41, Pavel Machek wrote:
> > Try this test program: https://github.com/mseaborn/rowhammer-test
> >
> > It has reproduced bit flips on various machines.
...
> So we have a program that corrupts basically random memory on many
> machines. That is not good. That means that un
Hi Pavel,
On Wed, Dec 24, 2014 at 05:38:23PM +0100, Pavel Machek 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
Extremely interesting st
On Thu 2014-12-25 09:26:41, Bastien ROUCARIES wrote:
> Le 25 déc. 2014 00:42, "Pavel Machek" 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 effecti
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 b
On Wed 2014-12-24 11:47:50, Mark Seaborn wrote:
> Hi Pavel,
>
> 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 typi
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.
Yep, I found out I wa
On Wed 2014-12-24 09:38:22, Andy Lutomirski wrote:
> On Wed, Dec 24, 2014 at 9:25 AM, Pavel Machek wrote:
> > On Wed 2014-12-24 09:13:32, Andy Lutomirski wrote:
> >> On Wed, Dec 24, 2014 at 8:38 AM, Pavel Machek wrote:
> >> > Hi!
> >> >
> >> > It seems that it is easy to induce DRAM bit errors by
On Wed, Dec 24, 2014 at 9:25 AM, Pavel Machek wrote:
> On Wed 2014-12-24 09:13:32, Andy Lutomirski wrote:
>> On Wed, Dec 24, 2014 at 8:38 AM, Pavel Machek wrote:
>> > Hi!
>> >
>> > It seems that it is easy to induce DRAM bit errors by doing repeated
>> > reads from adjacent memory cells on common
On Wed 2014-12-24 09:13:32, Andy Lutomirski wrote:
> On Wed, Dec 24, 2014 at 8:38 AM, Pavel Machek 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/p
On Wed, Dec 24, 2014 at 8:38 AM, Pavel Machek 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
Hi!
(I added original researches to the list).
I see you have FPGA-based detector, and probably PC based detector,
too. Would it be possible to share sources of the PC based one?
Thanks,
Pavel
On Wed 2014-12-24 17:38:23, Pavel Mach
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 trig
30 matches
Mail list logo
