linux-kernel - Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+

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:	Tue, 7 Oct 2008 02:35:01 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Len Brown <lenb@...nel.org>,
	Jason Vas Dias <jason.vas.dias@...il.com>
Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes
 (Re: 2.6.27-rc8+ - first impressions)

On Tue, 7 Oct 2008, Andi Kleen wrote:

> >  Hmm, working around Linux problems in the BIOS is a new and truly odd 
> > concept to me. 
> 
> Except perhaps for the cheapest consumer parts and many laptops Linux is 
> definitely on the radar now for many BIOS developers.

 That's not my point.

> > It's not that we are unresponsive or do not take 
> > responsibility for our bugs, is it?
> 
> These workarounds are not for mainline kernels but for specific
> distribution releases (as in "fixes SLES/RHEL x.y" instead of 
> "fixes 2.6.xy")

 I am happy to fix any bugs I introduced myself (as much as one can be 
happy about mistakes once they have discovered they made them that is) and 
certainly have a look into other Linux bugs by request of any vendor of a 
Linux distribution made on behalf of a hardware manufacturer.

 OTOH I do not feel responsible even a little bit for someone else's bugs 
like those of BIOS developers.  Though I will certainly consider providing 
them with any assistance needed to get things related to Linux resolved in 
a best possible way if they ask nicely.

> Even when the distributors update their kernels the old releases
> do not go away are still used and the workarounds get in.

 It is not unreasonable to require a version of a distribution that is 
current at the time a piece of hardware has been released.  Hardware 
vendors only support certain versions of certain operating systems if any 
at all and Linux makes no difference here.  Except from the bureaucracy 
needed, or actually the lack of, to get something we have done wrong 
rectified.  The community may support anything beyond that of course, like 
running Linux 1.2.13 on that brand new server.

> >  Well, perhaps, but the thermal trip point phenomenon seems unique to this 
> > family of systems.  The other aspects of the problem do not really matter 
> > anymore as we seem to have addressed them robustly enough now.
> 
> When you need DMI entries you clearly haven't.

 You can't just break a piece of hardware randomly (setting the thermal 
trip points based on an interrupt mask of an I/O APIC input is certainly 
beyond the ACPI spec), hide its documentation and still demand it to be 
supported correctly, possibly hurting all the other good equipment.  
Sorry -- you have to draw a line somewhere.  Others seem to agree as 
otherwise we wouldn't have DMI matching in the first place.  The same 
applies to PCI quirks.  And command line arguments to activate workarounds 
are worse yet, but we do have them too.  We wouldn't need any of these if 
all the hardware was built to the relevant specs.

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