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-next>] [day] [month] [year] [list]
Message-Id: <1250945310.14167.150.camel@maxim-laptop>
Date:	Sat, 22 Aug 2009 15:48:30 +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>
Subject: ACPI locks hardware devices when it doesn't detect vista

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.

On my system this it is still tolerable:

            Device (MIR)
            {
                Name (_HID, EisaId ("ENE0100"))
                Method (_STA, 0, NotSerialized)
                {
                    If (LGreaterEqual (OSYS, 0x07D6))
                    {
                        If (LOr (And (OTHR, 0x02), And (OTHR, 0x40)))
                        {
                            Return (0x00)
                        }
                        Else
                        {
                            Return (0x0F)
                        }
                    }
                    Else
                    {
                        Return (0x00)
                    }
                }

But not so, on Mairo's system:

            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)
                    }
                }

	.......

    Method (_WAK, 1, NotSerialized)
    {
    .......
        If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
        {
            Store (Zero, \_SB.PCI0.LPCB.IOR2)
        }


.....

    Scope (_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            If (DTSE)
            {
                TRAP (0x47)
            }

            Store (0x07D0, OSYS)
            If (CondRefOf (_OSI, Local0))
            {
                If (_OSI ("Linux"))
                {
                    Store (One, LINX)
                    Store (Zero, ECDY)
                }

                If (_OSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }

                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }

                If (LEqual (TPMV, One))
                {
                    If (LLessEqual (OSYS, 0x07D2))
                    {
                        TRAP (0x49)
                    }
                }
            }

            If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
            {
                TRAP (0x3D)
            }

            TRAP (0x2B)
        }
    }

We have tried to boot the system with acpi_osi="Windows 2006", but it
didn't help (kernel log confirmed that this parameter was set)

The only explanation I think of is ether his laptop is whitelisted on
osi=Linux, or that _SB._INI is called by linux _after_ MIR._STA
or that acpi_osi isn't yet in charge when _SB._INI is called.


The kernel in question is quite recent kernel, (2.6.30.5 from debian
unstable).


The only way I managed to 'enable' this device is to 
do 'sudo setpci -s 00:1f.0 0x88.W=0x701'

Or in other words undo the damage done by these ACPI commands.

Mairo, can you boot the system with acpi=off, and then poke the cir IO
range (0x700-0x703) ?



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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ