linux-kernel - Re: [PATCH] DMI: Decode and save OEM String information

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: <200607272127.14689.bjorn.helgaas@hp.com>
Date:	Thu, 27 Jul 2006 21:27:14 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	"Shem Multinymous" <multinymous@...il.com>
Cc:	"linux kernel mailing list" <linux-kernel@...r.kernel.org>,
	"Matt Domsch" <Matt_Domsch@...l.com>,
	"Brown, Len" <len.brown@...el.com>,
	"Henrique de Moraes Holschuh" <hmh@...ian.org>
Subject: Re: [PATCH] DMI: Decode and save OEM String information

On Thursday 27 July 2006 10:42, Shem Multinymous wrote:
> On 7/27/06, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
> > I always thought that ACPI was supposed to describe everything that
> > (a) consumes resources or requires a driver and (b) is not enumerable
> > by other hardware standards such as PCI.
> >
> > If that's true, isn't it a BIOS defect if this embedded controller isn't
> > described via ACPI?
> 
> The ThinkPad ACPI tables do list the relevant IO ports (0x1600-0x161F)
> as reserved, but provide no way to discern what's behind them.

How are they listed?  Maybe an example would help.  Do you mean the
ACPI namespace has a device whose _CRS includes ports 0x1600-0x161F,
but that device's _HID is used for devices with different programming
models?  Or do you mean it's in some static table (not the namespace)?
Or is the device at 0x1600-0x161F really a bridge, and we can't
determine what's on the other side?

> BTW, I should clarify that this embedded controller interface (used by
> hdaps and tp_smapi) is different than the standard ACPI EC interface,
> and goes through different IO ports.

That's fine.  The point is that for every device, ACPI should tell the
OS the programming model (with _HID/_CID) and resources it uses (with
_CRS/_PRS).  If ACPI doesn't do that, how is the OS supposed to know
that it can't allocate those I/O ports to other devices?

> > it seems like the ideal way forward
> > would be to get the BIOS fixed so you could claim the device with PNP
> > for future ThinkPads, and the table of OEM strings would not require
> > ongoing maintenance.
> 
> This is unrealistic. The hdaps and tp_smapi drivers support dozens of
> ThinkPad models, each with a different BIOS.

If there's an ACPI defect, I think it's realistic to report it and
ask for a fix in future releases.  Obviously you can't fix all the
machines in the field, so you'd still need something like the OEM
string table.  But if the BIOS were fixed for future machines, at
least the OEM string table would stop growing.

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