| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CALCETrW8nrKSZ800C+WaHMK4DCuWnD9TG3dYo7cZwm5j4CpNJQ@mail.gmail.com> Date: Wed, 24 Dec 2014 09:13:32 -0800 From: Andy Lutomirski <luto@...capital.net> To: Pavel Machek <pavel@....cz> Cc: kernel list <linux-kernel@...r.kernel.org> Subject: Re: DRAM unreliable under specific access patern On Wed, Dec 24, 2014 at 8:38 AM, Pavel Machek <pavel@....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. > > 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? --Andy > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- Andy Lutomirski AMA Capital Management, LLC -- 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