linux-kernel - Re: [PATCH] x86: split e820 reserved entries record to late

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Aug 2008 13:05:13 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: split e820 reserved entries record to late

On Thu, 28 Aug 2008, Yinghai Lu wrote:
>
> so could let BAR res register at first, or even pnp?

Well, I'm not sure whether PnP or e820 should be first, as long as any 
"real hardware" probing takes precedence over either. I _suspect_ that 
e820 is more trustworthy, which implies that PnP should probably be added 
last. It would be good to have some idea what Windows does, since usually 
all the firmware bugs are essentially hidden by whatever that other OS 
happens to do.

The basic rule really should be: "What do we trust most?" and probe things 
in that order. 

So e820 is fairly trustworthy, but we know that it will have various 
random things marked as reserved because they are special in some way (but 
we don't know _how_ they are special - they may well be real BAR's that 
just have a fixed meaning to ACPI or whatever).

But we obviously trust _part_ of it (the RAM stuff) more than we trust 
other parts. So it does make sense to consider that separately.

PnP I personally wouldn't trust at all, except as a way to keep dynamic 
resources away from those things, which is why I'd put it last. But that's 
just my personal gut feeling.

Hardware we generally trust more than any firmware, but even hardware can 
have bugs. And some classes of hardware tends to be less buggy than others 
(ie I'd trust some on-die APIC base pointer before I would trust a Cardbus 
controller BAR, for example).

But yes, I think your patch looks like it is definitely moving in the 
right direction. If this means that we can now do PCI probing without 
having the BAR's move around because they also happened to be covered by 
an e820 map, then that sounds like a good thing.

Of course, I bet there will be cases where this causes problems. It feels 
like we have _never_ worked around some PCI BAR allocation problem without 
hitting another unexpected one..

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