linux-kernel - Re: [git pull request] ACPI patches for 2.6.34-rc6

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, 7 May 2010 14:06:53 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
cc:	Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull request] ACPI patches for 2.6.34-rc6

On Fri, 7 May 2010, Matthew Garrett wrote:
> 
> The spec says we can't. I've posted a patch to do so if it's still not 
> set after we've tried doing it the right way, but I'm not keen on 
> pushing it into a release at this point.

I'm ok with the "release at this point".

But the "spec says we can't" is utter GARBAGE. We _know_ the ACPI spec is 
broken, and almost no BIOSes really follow it. So "spec says" is not a 
game we play. 

The ACPI spec is toilet paper compared to "real world". And anybody who 
looks at the current DMI tables for "oh, do this" realizes that this is 
_not_ an uncommon thing, and should damn well realize that this means that 
clearly Windows doesn't honor the spec _either_.

At that point, the spec isn't just toilet paper, it's toilet paper that MS 
has wiped their butt on. So f*ck "spec says". 

> > There is _no_ reason not to force it. If the BIOS set it, it's a no-op. If 
> > the BIOS didn't set it, it's a bug that _must_ be fixed.
> 
> Kind of. The "correct" way to do it is to write to an ioport, and doing 
> that usually triggers an SMI.

The "correct" way to do it is to basically do what works, and that in turn 
generally means "do what Winddows does, because that's the only thing 
that ever got tested".

I'm perfectly happy with "try to do it the right way, and check the end 
result: and if SCI_EN still isn't set, do it by hand".

So I don't think we need to do the write _unconditionally_, but it sure as 
hell shouldn't be conditional on some DMI table. Because all the DMI table 
tells is is that we do it _wrong_ right now, since clearly Windows doesn't 
have this issue.

		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/