linux-kernel - Re: [git pull] Input updates 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]

Message-ID: <4BFE0FAB.9040009@gmail.com>
Date:	Thu, 27 May 2010 00:22:35 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, Bastien Nocera <hadess@...ess.net>
Subject: Re: [git pull] Input updates for 2.6.34-rc6

On 05/13/2010 10:54 AM, Linus Torvalds wrote:
>
>
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
>>
>> Apple does proper thing in BIOS and omits keyboard and mouse PNP
>> devices, but because of other players we do not really trust PNP BIOS
>> and resort to banding on ports directly - there are cases when box has
>> mouse and/or keyboard but they are not present in BIOS. Damed if you do,
>> damned if you don't...
>
> Umm. No.
>
> PnP information _commonly_ doesn't inclure PS/2 ports, even when they
> exist. Lack of PnP information about the keyboard port means absolutely
> nothing, and anybody who tells you otherwise is totally and utterly wrong.
>
> So don't confuse this with PnP issues. That's a total red herring, and
> Apple is _not_at_all_ "doing the proper thing in the BIOS".
>
> Quite the reverse. Apple is very clearly doing something horribly _wrong_
> in their BIOS. Don't give them kudos for being incompetent morons.

I don't think they did anything wrong in their BIOS, it's working 
exactly as the spec intended. There is no PS/2 controller, and the ACPI 
PnP tables do not list one. I wouldn't argue that it was a good decision 
of them to have the hardware somehow blow up if something poked those 
ports anyway, but from a BIOS point of view they did the right thing.

>
> Just google for
>
> 	"Probing ports directly" "i8042 KBD port"
>
> and you'll get a lot of hits. That's not because those machines have wrong
> PnP tables - it's because fundamentally PNP is a joke, and on PC's what is
> much more important is "standard IO ports".
>
> For example, in that thread, Bastien is quoted:
>
> 	>  In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> 	>  controller exists, we randomly bang on the ports in the expectation
> 	>  they'll be there anyway. This seems rather misguided.
>
> and all that tells me is that Bastien doesn't know what he is doing. It is
> _not_ "randomly bang" - it's called standard PC hardware.  And it's not
> "misguided" - it's very much correct and required, exactly because PnP
> itself is the misguided aborted fetus of a braindamaged mind.

I think that may have been me, actually, not Bastien. Misguided may have 
been a too strong term, but in this case I think the PnP information is 
quite trustable because Windows trusts it. Definitely for the PS/2 mouse 
controller (quite likely the keyboard too), if Windows is in ACPI mode 
and the PnP tables do not list it, it will not detect or use it.

Now, many BIOSes seem to have have code (like an "auto" mode for the 
PS/2 port, which may or may not be always set) which disables the PnP 
entry if it doesn't detect a mouse or keyboard connected on boot. If 
memory serves, this is because I think at least on some versions, if 
Windows finds a controller but no mouse is responding then it shows up 
with an error indication in Device Manager, which tends to make people 
unhappy. This is likely what's responsible for most of those cases where 
Linux detects devices after "probing ports directly", because the BIOS 
hid the device but we were too "clever" for it and found it anyway.

In fact on a lot of boards, Linux still detects the port even if set as 
"disabled" in the BIOS, because all that does is disable the PnP entry.

Long and the short of it is, it seems pretty safe to say that on any 
ACPI machine, if there's no PnP entry for PS/2 devices, the BIOS does 
not intend for the OS to use them. There may be cases where you might 
want to try to locate ports anyway (maybe you really want to hotplug a 
mouse in after boot, or you have an ancient KVM which doesn't emulate a 
device presence on the non-selected machine), but those seem like very 
much the exception rather than the rule.

>
> We do not trust BIOS tables, because BIOS writers are invariably totally
> incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS
> writers. QED. And in fact the Apple problem is an _example_ of this BIOS
> writer incompetence, not some shining example of them doing something
> right.
>
> 			Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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