linux-kernel - Re: [PATCH RFC] x86: check for and defend against BIOS memory corruption

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, 29 Aug 2008 07:18:06 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Yinghai Lu <yhlu.kernel@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Rafa? Mi?ecki <zajec5@...il.com>,
	Alan Jenkins <alan-jenkins@...fmail.co.uk>,
	Hugh Dickens <hugh@...itas.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] x86: check for and defend against BIOS memory corruption

Alan Cox wrote:
>>>>  - Clears the reserved memory so we can observe changes to it.
>>>>         
>
> You ought to pick different values on different runs 0x00, 0xFF, 0xAA,
> 0x55 etc...
>   

Yes, that wouldn't be a bad idea.  The corruption we've seen so far is
0->non 0, but we haven't looked for zeroing.

>> Yeah, OK, but I think it should default to ON for now.  The problem is
>> that we had two very different systems (Sony Vaio and Intel desktop)
>>     
>
> So a zillion people should lose a chunk of RAM because of what is
> probably an obscure bug in a single version of a piece of SMM code on two
> systems total ?
>   

Well, we just don't know.  We have two systems which started reporting
problems when I made a small change to how the initial pagetables are
allocated.  Before that they appeared to work fine, though in reality it
was just some other part of the address space being corrupted.  Who
knows how many systems are out there "working fine", except that some
obscure address in the user address space now allows you to write into
kernel memory?

The two systems are *completely different*.  One has a Phoenix BIOS, the
other is AMI.  One is a Sony Vaio, the other is an OEM Intel desktop. 
One corrupts memory on unplugging a HDMI cable, the other corrupts on
suspend/resume.  I don't think this is reassuring, or indicates the
problem has limited scope.

> That appears to be totally out of proportion - plus the defaults are
> *irrelevant* for mass user coverage. If you want large scale coverage ask
> the Fedora, OpenSuSE and Ubuntu people to turn it on for a testing kernel
> release and report back.

The idea is to leave it on by default for a while - maybe a couple of
-rc releases - and see what turns up.  We can turn it off for a release
kernel if people really object, though I'd hope something like Fedora
Rawhide would leave it on.

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