linux-kernel - Re: AMD Family 10H machine check on vmcore read

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]

Message-ID: <20080711205052.GC3298@redhat.com>
Date:	Fri, 11 Jul 2008 16:50:52 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Bob Montgomery <bob.montgomery@...com>
Cc:	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Yinghai Lu <yhlu.kernel@...il.com>
Subject: Re: AMD Family 10H machine check on vmcore read

On Wed, Jul 09, 2008 at 11:32:40AM -0600, Bob Montgomery wrote:
> On Tue, 2008-07-08 at 13:28 +0000, Vivek Goyal wrote:
> > On Mon, Jul 07, 2008 at 05:08:06PM -0600, Bob Montgomery wrote:
> > > We maintain a 2.6.18 derived kernel.
> > > When testing kdump on a new AMD Family 10h (16) processor, once in the
> > > kdump kernel, a read from either /proc/vmcore or /dev/oldmem that
> > > corresponds to the area of memory identified in the original (crashing)
> > > kernel by these boot messages:
> 
> > >
> > > On a Family 15 AMD64 processor running this kernel and kdump kernel, I
> > > can read the areas identified as being in the aperture from the kdump
> > > kernel and get values, but on the new processor, reads from the kdump
> > > kernel that are within that address range result in the machine check:
> > >
> > > HARDWARE ERROR
> > > CPU 0: Machine Check Exception:                4 Bank 4: be0000010005001b
> > > TSC 141bd974323de ADDR 1c000000 MISC e00c0ffe01000000
> > >
> 
> > Hi Bob,
> > 
> > I am not sure what's happening here. Because in /proc/iomem, GART reserved
> > area is reported as System RAM, kdump kernel will try to read this area
> > and save it. Now I am not sure, what is so special about this area that
> > mapping it and reading it in second kernel would cause a MCE.
> > 
> > CCing it to LKML, hoping people knowing GART will be able to provide some
> > input.
> > 
> > > But I don't see this fix upstream in the kernel.  So I'm wondering if
> > > some other patch protects other kdump kernels from this problem.  In
> > > particular, a recent patch that informed the e820 map about the gart
> > > aperture to prevent a normal kernel and a kexec kernel from putting it
> > > at different addresses.  It didn't mention machine checks from kdump
> > > kernels, but I wonder if it would have prevented access to that memory
> > > area by having it be excluded from the /proc/vmcore list of areas??
> > 
> > Can you provide a link to the patch above? If /proc/iomem, does not report
> > GART area as system ram then it will be excluded from the dump. (IIUC,
> > IOMMU tables are in GART area and ideally one should be capturing it to
> > find out how IOMMU tables looked like at the time of crash).
> 
> The patch that I thought might be related is:
>  x86: disable the GART early, 64-bit
> 
> author     Yinghai Lu <Yinghai.Lu@....COM>
>            Wed, 30 Jan 2008 12:33:09 +0000 (13:33 +0100)
> committer  Ingo Molnar <mingo@...e.hu>
>            Wed, 30 Jan 2008 12:33:09 +0000 (13:33 +0100)
> commit     aaf230424204864e2833dcc1da23e2cb0b9f39cd
> tree       a42042f5135aa63a780964bd053ae174211ab62f
> 
> I thought it might be relevant because of this included comment:
> 
> > hm, i'm wondering, instead of modifying the GART, why dont we simply
> > _detect_ whatever GART settings we have inherited, and propagate that
> > into our e820 maps? I.e. if there's inconsistency, then punch that out
> > from the memory maps and just dont use that memory.
> 
> But this patch doesn't mention machine checks as the symptom that
> initiated the patch.
> 
> And my reason for looking was because I didn't think I could be the
> first person to try reading /proc/vmcore on a Family 10h processor.  So
> I wondered why it hadn't been seen by some other tester, and thought
> some other patch might have "fixed" it a different way on newer kernels
> than mine.
> 

Hi Bob,

So it looks like this patch will mark aperture region as non RAM and kudmp
will not try to dump that memory and will not run into MCE. Have you tried
the kernel with this patch? Does it work for you?

At this point I don't know, why accessing the aperture region of first
kernel causes MCE. May be Andi or Yinghai will know, CCing them.

So backporting the Yinghai's patch to your kernel should help here.

Thanks
Vivek
--
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/