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: <20080413105348.22e55ea5@laptopd505.fenrus.org>
Date:	Sun, 13 Apr 2008 10:53:48 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Yinghai Lu <yinghai.lu@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Anvin" <hpa@...or.com>, Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [rfc] hw resource debugging checks

On Sun, 13 Apr 2008 11:39:10 +0200
Andi Kleen <andi@...stfloor.org> wrote:

> Ingo Molnar <mingo@...e.hu> writes:
> 
> This whole problem just shows that it was a mistake in the first place
> to try to redo the BIOS work in Linux. If BIOS doesn't supply MCFG
> Linux trying to create one (or in general having generalized resource
> allocation) is just a big mess and will cause endless problems.  The
> standard resource code is just not up to the task and it needs very
> intimate knowledge of the hardware that the kernel shouldn't have.
> 
> Again the real fix I think is to just drop all that code in git-x86
> again and finally fix LinuxBIOS to do its job properly and pass a
> proper MCFG (or just forget about using mmconfig with LinuxBIOS - it
> is not that Type1 suddently doesn't work anymore). Then this code
> wouldn't be needed at all

I totally agree with this. MCFG has been EXTREMELY fragile for the last years,
and I don't see that changing anytime soon.
The only thing that works for Linux so far is "if it even smells funny, don't use it".
Smelling funny is things like
1a) Bios table and e820 not matching up, or
1b) Bios table and hardware data not matching up
2) The content not matching content gotten via the traditional method
3) ... (bunch of other sanity checks)

I guess we really need to have
0) If it's not present in the BIOS do not touch
as rule as well.


-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ