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: <20060728124940.GA26735@khazad-dum.debian.net>
Date:	Fri, 28 Jul 2006 09:49:40 -0300
From:	Henrique de Moraes Holschuh <hmh@...ian.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Shem Multinymous <multinymous@...il.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Matt Domsch <Matt_Domsch@...l.com>,
	"Brown, Len" <len.brown@...el.com>
Subject: Re: [PATCH] DMI: Decode and save OEM String information

On Thu, 27 Jul 2006, Bjorn Helgaas wrote:
> > > 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

In the T43, very recent BIOS, it is inside _SB_.PCI0.LPC.SIO, where _HID is
PNP0C02, and it holds resources to a number of different devices.  Port 1600
is not even in a block by itself, it is in a block that reserves 0x42 bytes,
while the EC occupies just 0x1600-0x161F.

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

Tell that to the vendors...

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

I very much doubt you can pull that off, but if anyone has good contacts
within IBM/Lenovo's ThinkPad notebook division, we could try.  Heck, the
Thinkpad community have *firmware* fixes to send them and no channel
whatsoever to send a report to engineering.  Lenovo support doesn't let you
report something like that, unlike, say, Intel's.

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

The table (within the driver, for whitelisting) has exactly *one* substring
for string match, that works for all models since the A31, and maybe even
earlier ones.  The OEM string table used by IBM is quite stable.

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