linux-kernel - Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

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: <20070302142441.GL2156@elf.ucw.cz>
Date:	Fri, 2 Mar 2007 15:24:41 +0100
From:	Pavel Machek <pavel@....cz>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Chuck Ebbert <cebbert@...hat.com>,
	Rudolf Marek <r.marek@...embler.cz>,
	linux-acpi@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

Hi!

> > Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
> > sure that 90%+ of ACPI notebook implementations *will* want to talk to
> > their monitoring chips... for temperature readings.
> >
> > So even if we fixed ACPI to reserve the ports, you'd be still unhappy;
> > lm-sensors would break at least on all the notebooks.
> 
> That's a secondary problem. The primary issue is the concurrent access
> to resources, which cause lots of trouble which are hard to investigate.
> If ACPI reserves the ports, then the SMBus or hardware monitoring
> drivers (or any other conflicting driver) will cleanly fail to load,
> which would be a move in the right direction. Ideally we would be able
> to synchronize the accesses between ACPI and the other drivers, but if
> we can't, I'd already be _very happy_ to just prevent conflicting
> drivers from being loaded at the same time.
> 
> So, can ACPI actually reserve the ports it accesses?

No idea, talk to Len Brown (or start reading the code) :-(. I don't
think it will be easy.

> > > 1* As far as I know, we currently have no way to know if the ACPI code
> > > plans to ever access the hardware monitoring chip. If the acpi
> > > subsystem could export this information somehow, it would help a lot.
> > > But I'm not familiar with ACPI, so I don't know if this is feasable or
> > > not. We just can't prevent the SMBus and hardware monitoring drivers
> > > drivers from being loaded as soon as ACPI is enabled. This would
> > > prevent a majority of users from using them, while they work fine for
> > > most of them.
> > 
> > What about whitelist? DMI-based? That's only way to do it, I'm afraid.
> 
> What kind of whitelist do you have in mind? We can't realistically
> maintain an ever-growing whitelist of hundreds of entries in the
> kernel. We could block all laptops by default and maintain a white list
> only for them, and a black list for other systems, the would probably
> limit the maintenance work, maybe not to an acceptable level though.

I'm afraid something like that is way to go.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/