linux-kernel - Re: [PATCH] lpc_ich: Fix a 3.5 kernel regression for iTCO

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: <20120823130814.6ba359e9@feng-i7>
Date:	Thu, 23 Aug 2012 13:08:14 +0800
From:	Feng Tang <feng.tang@...el.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Wim Van Sebroeck <wim@...ana.be>, Len Brown <len.brown@...el.com>,
	<linux-acpi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Aaron Sierra <asierra@...-inc.com>,
	Bob Moore <robert.moore@...el.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Guenter Roeck <linux@...ck-us.net>, rui.zhang@...el.com
Subject: Re: [PATCH] lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt
 driver

On Wed, 22 Aug 2012 22:55:43 +0100
Matthew Garrett <mjg59@...f.ucam.org> wrote:

> On Wed, Aug 22, 2012 at 09:55:12PM +0200, Wim Van Sebroeck wrote:
> 
> > Any idea why the acpi_check_resource_conflict() check gives a conflict?
> 
> Because the resource range is declared in ACPI and we assume that that 
> means the firmware wants to scribble on it. We'd need the output of 
> acpidump to work out whether that's safe or not.

Good point, I checked the conflict for iTCO_wdt, the conflict exists on
almost all the machines I have.

According to ICH (7/8/9 etc)spec, the TCO watchdog has a 32 bytes long IO 
space resource, and the bit 9 of TCO1_STS register is "DMISCI_STS", which
 indicates whether a SCI happens, and will be cleared by writing 1
to it. Most of DSDT table will claim a TCO op region only for one bit:
"DMISCI_STS" , as some method may need to access that bit. 

I think there is some risk, but it's quite safe as the DMISCI_STS bit has
nothing to do with TCO driver itself, and TCO driver never access it, also
this TCO driver has been there for years, and this resource conflict also
exists for many generations hardware. 

Thanks,
Feng

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