linux-kernel - Re: ACPI locks hardware devices when it doesn't detect vista

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: <1251506453.28828.0.camel@maxim-laptop>
Date:	Sat, 29 Aug 2009 03:40:53 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	linux-pm <linux-pm@...ts.linux-foundation.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Mairo <rety@...zta.onet.pl>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: ACPI locks hardware devices when it doesn't detect vista

Oh, and cc linux-acpi....

On Sat, 2009-08-29 at 02:53 +0300, Maxim Levitsky wrote:
> On Sat, 2009-08-22 at 15:48 +0300, Maxim Levitsky wrote:
> > Hi,
> > 
> > <joke>
> > This should be brought to a Microsoft antitrust case...
> > </joke>
> > 
> > 
> > Today many notebooks ship with a embedded infrared receiver.
> > In Vista there is new subsystem that decodes these signals.
> > (of course it works only with Microsoft Certificated Remotes (TM)...)
> > 
> > The receiver is usually presented to system as a pnp device 
> > (using acpi tables)
> > 
> > It turns out that some bioses actually use the OSI, ACPI feature of the
> > operation system to detect if running inside Vista. If not they disable
> > the infrared receiver.
> > 
> >             Device (MIR)
> >             {
> >                 Name (_HID, EisaId ("ENE0100"))
> >                 Method (_STA, 0, NotSerialized)
> >                 {
> >                     If (LAnd (MCIR, LEqual (OSYS, 0x07D6)))
> >                     {
> >                         Return (0x0F)
> >                     }
> >                     Else
> >                     {
> >                         Store (Zero, ^^LPCB.IOR2)
> >                         Return (Zero)
> >                     }
> >                 }
> > 
> > 	.......
> > 
> 
> >     Scope (_SB)
> >     {
> >         Method (_INI, 0, NotSerialized)
> >         {
> 		....
> 
> >             If (CondRefOf (_OSI, Local0))
> >             {
> >                 If (_OSI ("Linux"))
> >                 {
> >                     Store (One, LINX)
> >                     Store (Zero, ECDY)
> >                 }
> 
>                   ..........
> > 
> 
> >                 If (_OSI ("Windows 2006"))
> >                 {
> >                     Store (0x07D6, OSYS)
> >                 }
>                   .......
> 
> 
> I have finally managed to find root case of this problem.
> 
> Indeed the _STA method of infrared receiver is called before the _INI of
> _SB.
> 
> The problem lies in acpi_bus_init()
> 	/*
> 	 * ACPI 2.0 requires the EC driver to be loaded and work before
> 	 * the EC device is found in the namespace (i.e. before acpi_initialize_objects()
> 	 * is called).
> 	 *
> 	 * This is accomplished by looking for the ECDT table, and getting
> 	 * the EC parameters out of that.
> 	 */
> 
> 	status = acpi_ec_ecdt_probe();
> 	/* Ignore result. Not having an ECDT is not fatal. */
> 
> 	status = acpi_initialize_objects(ACPI_FULL_INITIALIZATION);
> 	if (ACPI_FAILURE(status)) {
> 		printk(KERN_ERR PREFIX "Unable to initialize ACPI objects\n");
> 		goto error1;
> 	}
>         .......
> 
> 
> on Mairo's system (just as well as on mine) there is no ECDT.
> Thus, acpi_ec_ecdt_probe() triggers a acpi namespace walk, 
> which in turn triggers invocation on _STA (which is supposed to be
> harmless, but the <beep>, the bios developers produce doesn't seem to
> meet this criteria....).
> 
> And this is done before running _INI methods, which are run just later,
> in acpi_initialize_objects.
> 
> I suspect that many systems use _SB._INI to test the OS version, thus
> this behavior needs to be revised.
> 
> The fact that this (as usual) works in windows suggest that it might  be
> good to look up the ECDT table before acpi_initialize_objects, but if
> not found, look up the EC later.
> 
> On my system, although I have tried to reproduce this bug, I couldn't,
> and I know now why: It just so happens that on my system CIR device is
> listed in acpi tables after the EC, but on Mairo's system EC is just
> first device.
> 
> Maybe we can add a 'walk only' function, that walks the namespace, but
> doesn't touch the _STA, and use it to find the EC there?
> 
> Looking for comments,
> 	Best regards,
> 		Maxim Levitsky
> 

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