| 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: <m1vds0bj2j.fsf@fess.ebiederm.org> Date: Tue, 27 Jan 2009 12:16:52 -0800 From: ebiederm@...ssion.com (Eric W. Biederman) To: "Chris Friesen" <cfriesen@...tel.com> Cc: Arjan van de Ven <arjan@...radead.org>, linux-kernel@...r.kernel.org, Doug Thompson <norsk5@...oo.com>, <linux-mm@...ck.org>, <bluesmoke-devel@...ts.sourceforge.net> Subject: Re: marching through all physical memory in software "Chris Friesen" <cfriesen@...tel.com> writes: > Arjan van de Ven wrote: >> On Mon, 26 Jan 2009 09:38:13 -0600 >> "Chris Friesen" <cfriesen@...tel.com> wrote: >> >>> Someone is asking me about the feasability of "scrubbing" system >>> memory by accessing each page and handling the ECC faults. >>> >> >> Hi, >> >> I would suggest that you look at the "edac" subsystem, which tries to >> do exactly this.... > edac appears to currently be able to scrub the specific page where the fault > occurred. This is a useful building block, but doesn't provide the ability to > march through all of physical memory. Well that is the tricky part. The rest is simply finding which physical addresses are valid. Either by querying the memory controller or looking at the range the BIOS gave us. That part should not be too hard. I think it simply has not been implemented yet as most ECC chipsets implement this in hardware today. Eric -- 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