linux-kernel - Re: [Patch 1/4][kernel][slimdump] Add new elf-note of type NT

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: <20111005162520.GC18592@gere.osrc.amd.com>
Date:	Wed, 5 Oct 2011 18:25:20 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>,
	"K.Prasad" <prasad@...ux.vnet.ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"crash-utility@...hat.com" <crash-utility@...hat.com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"anderson@...hat.com" <anderson@...hat.com>,
	"tachibana@....nes.nec.co.jp" <tachibana@....nes.nec.co.jp>,
	"oomichi@....nes.nec.co.jp" <oomichi@....nes.nec.co.jp>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [Patch 1/4][kernel][slimdump] Add new elf-note of type
 NT_NOCOREDUMP to capture slimdump

On Wed, Oct 05, 2011 at 08:58:53AM -0700, Luck, Tony wrote:
> > > The plan is to pass-down the list of poisoned memory pages to the second
> > > kernel using an elf-note so that these pages are left untouched during
> > > dump capture. I'm working on an implementation of the same and should
> > > have patches soon.
> >
> > I would say let us first figure out what happens while reading a poisoned
> > page and is this a problem before working on a solution.
> 
> If the page is poisoned because of a real uncorrectable error in memory
> (reported as SRAO machine check today, or by SRAR real-soon-now). Then
> accessing the page from the processor while taking a memory dump will
> result in a machine check.
> 
> Note that a large memory system that had been running for a long time
> may have built up a small stash of these land-mine pages - and we need
> to worry about them even in the case where the panic is not machine
> check related (in fact especially in this case ... we are in a case
> where we actually do want the dump to diagnose the cause of the panic,
> and we don't want to risk losing the crash dump because we aborted when
> touching a page that the OS had safely avoided for days/weeks/months).
> 
> So passing a list of poisoned pages from the old kernel to the new kernel
> is a good idea - and is independent of the cause of the crash (except that
> in the fatal machine check case due to memory error the list is guaranteed
> to be non-empty).
> 
> Passing some crash signature data - so the new kernel/dump-tools can make
> a choice whether to even try to take a full dump is also interesting (but
> independent from the bad page list).

Good point,

this would probably advocate for the solution of disabling of detection
of at least certain MCEs like DRAM UCs and then, even if you manage
to dump core successfully, how can you be sure that the memory image
doesn't contain some corrupted data? So yes, some sort of error
and corresponding address collection is needed for later image
"preparation".

Hmm, this just got interesting.

-- 
Regards/Gruss,
Boris.
--
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/