linux-kernel - Re: [PATCH] resource/x86: add sticky resource type

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: <alpine.LFD.1.10.0808281015440.3300@nehalem.linux-foundation.org>
Date:	Thu, 28 Aug 2008 10:20:12 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH] resource/x86: add sticky resource type

On Thu, 28 Aug 2008, Ingo Molnar wrote:
>
> Does anyone have any suggestions of how to improve this some more? (or 
> do it differently)

As far as I can see, THIS IS TOTALLY BROKEN.

There's a reason why we add the broken resources LATE. There's a reason we 
_have_ to add them late.

Trying to come up with these braindamaged schemes to avoid doing it right 
is wrong. Don't do it.

The reason? Those bogus resources that the BIOS reports are simply NOT 
TRUSTWORTHY. They may actually be in all the wrong places, including 
covering a resource half-way, or crossing two real resources.

Yes, it's rare. But it happens. Which is why we should not do these broken 
things that _incorrectly_ assume that the BIOS resources will only ever be 
totally contained within a BAR, or will totally contain one. Think about 
the partial overlap case.

Guys, until you learn that the BIOS resources are _crap_ and at most 
random guesses, you shouldn't touch this code! And it has nothing to do 
with writing "clean" code, or making things "simple", because quite 
frankly, things simply ARE NOT simple!

The fact is, the only reliable way to handle these things has _always_ 
been to ask the hardware first. Add the broken resources from ACPI and 
other BIOS tables _later_. If they conflict, it is the ACPI/BIOS tables 
that should be removed.

Why do I have to tell this to people over and over again?

		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/