linux-kernel - Re: ACPI OSI disaster on latest HP laptops

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: <20080802143833.GC14069@khazad-dum.debian.net>
Date:	Sat, 2 Aug 2008 11:38:33 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Len Brown <lenb@...nel.org>, Thomas Renninger <trenn@...e.de>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	"Moore, Robert" <robert.moore@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Christian Kornacker <ckornacker@...e.de>
Subject: Re: ACPI OSI disaster on latest HP laptops - critical temperature
	shutdown

On Sat, 02 Aug 2008, Matthew Garrett wrote:
> On Fri, Aug 01, 2008 at 07:36:57PM -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 01 Aug 2008, Len Brown wrote:
> > > It is better to expose ourselves to the known tested Windows functionality
> > > -- even if it seems arbitrary, at least it is tested.  The !Windows case
> > > results in running _completely_ untested BIOS code.
> > 
> > Actually, we should masquerade properly as the latest Windows version
> > available for that machine, then.  AFAIK, Windows does not set ALL the OSI
> > strings, just one.  We ARE running untested code in some BIOSes because of
> > it.
> 
> The BIOSes I've tested check _OSI in order of Windows release, which is 
> consistent with Windows returning OSI strings for all previous versions. 
> Do you have any examples that suggest this isn't the case?

Yes.  IBM ThinkPads store the result of each version test separately, and I
recall I saw at least one DSDT code path that didn't test all of them in
order to select a branch of code to run.

It will be hard to find that DSDT, though. It was sometime ago :(

> > Maybe it would be better if every ACPICA-using OS defined a
> > _OSI(NotWindows), plus the relevant Windows OSI string they want to support,
> > and Intel would send word that this string is to be used ONLY to disable all
> > Windows bug workarounds, not to activate or deactivate any specific
> > functionality?
> 
> Not all BIOSes would support this, so we'd need to support the Windows 
> workarounds anyway. At that point, there's no real benefit in having 
> multiple codepaths.

Sorry, but I will disagree.

Anything that can help in the future with the vendors that are better at
Linux support is a good thing.  You are right that we will still have to
deal with the others, but there are such things as vendor-specific windows
workarounds (they didn't want to change their firmware, or they couldn't, or
the others didn't care to add the workaround, etc).  If that vendor uses the
"NotWindows" OSI correctly, we would not need to take any special action.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/