linux-kernel - 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>] [day] [month] [year] [list]

Message-ID: <476A9FEB.2090508@iitiantech.com>
Date:	Thu, 20 Dec 2007 09:01:31 -0800
From:	Siva Prasad <siva@...iantech.com>
To:	matthew@...emark.co.uk
CC:	linux-kernel@...r.kernel.org
Subject: Testing RAM from userspace / question about memmap= arguments

Hi Matthew,

I worked on some thing similar. For one of our customer product that 
goes to defense and security markets, we had to support maximum possible 
memory test. We implemented a mechanism of pre-test to test the memory 
with walking 1's and 0's just before Linux kernel starts allocating 
serious memory for its use. That way, coverage was almost 99%. Once 
Linux boots, we do a very through test using various algorithms, however 
as you said coverage of memory is little less when we test the system 
after Linux boots up completely.

memtest86+ started as a very good alternative, until customer's customer 
started complaining about memory issues. Then we had no choice but to 
take this route and implement it ourselves from the scratch.

If you want 100% coverage, it may not be possible unless you do it in 
BIOS early on. If you take the route of implementing some simple memory 
test in Linux kernel before it starts allocating memory, you get very 
good % of coverage. Good Luck.

- Siva

Date: Thu, 20 Dec 2007 14:17:10 +0000

From: Matthew Bloch <matthew@...emark.co.uk>

Subject: Re: Testing RAM from userspace / question about memmap=

      arguments

To: linux-kernel@...r.kernel.org

Message-ID: <fkdth6$d7g$1@....gmane.org>

Content-Type: text/plain; charset=ISO-8859-1

Jon Masters wrote:

 > On Tue, 2007-12-18 at 17:06 +0000, Matthew Bloch wrote:

 >

 >> I can see a few potential problems, but since my understanding of the

 >> low-level memory mapping is muddy at best, I won't speculate; I'd just

 >> appreciate any more expert views on whether this does work, or could be

 >> made to work.

 >

 > Yo,

 >

 > I don't think your testing approach is thorough enough. Clearly (knowing

 > your line of business - as a virtual machine provider), you want to do

 > pre-production testing as part of your provisioning. I would suggest

 > instead of using mlock() from userspace of simply writing a kernel

 > module that does this for every page of available memory.

Yes this is to improve the efficiency of server burn-ins.  I would

consider a kernel module, but I still wouldn't be able to test the

memory in which the kernel is sitting, which is my problem.  I'm not

sure even a kernel module could reliably test the memory in which it is

residing (memtest86+ relocates itself to do this).  Also I don't see how

  userspace testing is any less thorough than doing it in the kernel; I

just need a creative way of accessing every single page of memory.

I may do some experiments with the memmap args, some bad RAM and

shuffling it between DIMM sockets when I have the time :)

-- 

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