linux-kernel - Re: [OHCI] BIOS handoff failed (BIOS bug?)

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] [day] [month] [year] [list]

Message-ID: <20061202071503.GA6184@section_eight>
Date:	Sat, 2 Dec 2006 08:15:03 +0100
From:	Sebastian Kemper <sebastian_ml@....net>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	Pete Zaitcev <zaitcev@...hat.com>, thockin@...kin.org
Subject: Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, Dec 01, 2006 at 03:32:47PM -0800, thockin@...kin.org wrote:
> On Fri, Dec 01, 2006 at 03:29:22PM -0800, Pete Zaitcev wrote:
> > On Fri, 1 Dec 2006 15:23:39 -0800, thockin@...kin.org wrote:
> > 
> > > BIOS handoff assumes an SMI, right?  Could SMI be masked?
> > 
> > That might be a bad idea, because things like fans may be controlled
> > by SMM BIOS. The best thing we can do is to follow the published
> > procedure, and maybe insert a workaround if Sebastian can identify it.
> 
> Sorry, I don't mean "could we mask it" but rather "is it possible that it
> is already masked"?
> 
> Tim

Hi,

I can't see any negative effects when the handoff fails. But if any of
you think it's worth to get to the bottom of this I'm more than willing
to help the best I can. But I don't know what SMI nor SMM BIOS is, just
so you know that I can't figure out these things on my own.

I extracted my BIOS' dsdt and disassembled it (on a hunch). I grepped
it for strings like "Microsoft" and "Windows" and found three:

           Method (_INI, 0, NotSerialized)
            {
                If (STRC (_OS, "Microsoft Windows"))
                {
                    Store (0x56, SMIP)
                }
                Else
                {
                    If (STRC (_OS, "Microsoft Windows NT"))
                    {
                        If (CondRefOf (_OSI, Local0))
                        {
                            If (_OSI ("Windows 2001"))
                            {
                                Store (0x59, SMIP)
                                Store (Zero, OSFL)
                                Store (0x03, OSFX)
                            }
                        }
                        Else
                        {
                            Store (0x58, SMIP)
                            Store (Zero, OSFL)
                        }
                    }
                    Else
                    {
                        Store (0x57, SMIP)
                        Store (0x02, OSFL)
                    }
                }
            }

So I tried all possible combinations of acpi_os_name and acpi_osi
(allthough the latter seemed to be ignored by the ACPI system). But this
didn't change the OHCI handoff behaviour. At least we can rule this one
out. But probably disassembling the dsdt was a waste of time :-)

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