linux-kernel - Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110107143741.7b2b2a8d@jbarnes-desktop>
Date:	Fri, 7 Jan 2011 14:37:41 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>, Jiri Slaby <jslaby@...e.cz>,
	linux-pci@...r.kernel.org, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Thomas Renninger <trenn@...e.de>
Subject: Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes

On Fri, 07 Jan 2011 21:44:35 +0100
Jiri Slaby <jirislaby@...il.com> wrote:

> On 01/06/2011 08:24 PM, Bjorn Helgaas wrote:
> > Theoretically, ACPI tells us about the GPIO/TCO/etc. regions in a
> > generic way via namespace devices or something in the static tables.
> > Is that generic information missing, or is it there and Linux is
> > ignoring it?  If we're ignoring it, I'd rather fix that.
> 
> It works for most boxes I would say. Try to google for "claimed by ICH4
> ACPI/GPIO/TCO", it reports sane ranges like 0400-047f or 4000-407f.
> 
> > The main reason for claiming I/O regions is to keep us from placing
> > another device on top of them.  But we've had PCIBIOS_MIN_IO = 0x1000
> > forever, which should keep us from putting anything below that anyway
> > (at least for PCI devices).  So there must be some other reason for
> > claiming space in this quirk.
> 
> Anyway, this ACPI space may be below 0x1000 as can be seen above. From
> the ICH standard, it can be anywhere...

Is there some other resource we should be considering to avoid this
space?

And we know it won't work if we try to use the IDE controller in the
LPC allocated space?  Have you checked the ICH4 specs to see what the
decode rules are on this space?  I guess LPC has priority and doesn't
forward requests through to IDE?

Either way, it would be good to understand this issue a little better
before we start restricting the LPC space like this.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/