linux-kernel - Re: Intel BIOS - Corrupted low memory at ffff880000004200

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:	Fri, 10 Jul 2009 13:52:38 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Matthew Garrett <mjg59@...f.ucam.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...radead.org>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alexey Fisher <bug-track@...her-privat.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	"Richard A. Holden III" <aciddeath@...il.com>
Subject: Re: Intel BIOS - Corrupted low memory at ffff880000004200


* Matthew Garrett <mjg59@...f.ucam.org> wrote:

> On Mon, Jul 06, 2009 at 06:24:47PM +0200, Alexey Fisher wrote:
> > Hallo Ingo, Richard.
> >
> > I'm getting "Corrupted low memory" trace with my Intel DG45ID 
> > board after resume. This board has different dmi-bios-vendor... 
> > so probably it will be nice to have it in your patch.
> 
> I'm beginning to think that we should be doing this on all 
> hardware, perhaps with a kernel option to disable it for embedded 
> devices that really need that 64K. The low-memory corruption issue 
> seems to be very widespread.

The problem is that the BIOS corrupted memory that it also marked as 
'usable' in its E820 map it gave to the kernel. If that memory is 
not usable, it should not have been marked as such. Also, some of 
the reports showed corruption beyond this range so the workaround is 
not universal.

So i'd really like to know what is happening there, instead of just 
zapping support for 64K of RAM on the majority of Linux systems.

We might end up doing the same thing in the end (i.e. disable that 
64k of RAM) - but it should be an informed decision, not a wild stab 
in the dark.

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