linux-kernel - Re: Testing RAM from userspace / question about memmap= arguments

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 22 Dec 2007 12:09:59 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Matthew Bloch <matthew@...emark.co.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Testing RAM from userspace / question about memmap= arguments

On Tue, 18 Dec 2007 17:06:24 +0000
Matthew Bloch <matthew@...emark.co.uk> wrote:

> Hi - I'm trying to come up with a way of thoroughly testing every byte
> of RAM from within Linux on amd64 (so that it can be automated better
> than using memtest86+), and came up with an idea which I'm not sure is
> supported or practical.
> 
> The obvious problem with testing memory from user space is that you
> can't mlock all of it, so the best you can do is about three quarters,
> and hope that the rest of the memory is okay.

well... to be honest the more obvious problem will be that you won't be testing the RAM, you'll be testing the CPU's cache.. over and over again.

memtest86+ does various magic to basically bypass the caches (by disabling them ;-)...
Doing that in a live kernel situation, and from userspace to boot...... that's... and issue.
--
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/