linux-kernel - Re: LMSENSORS: 2.6.26-rc, enabling ACPI Termal Zone support costs sensors

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: <20080623143112.GA4160@srcf.ucam.org>
Date:	Mon, 23 Jun 2008 15:31:12 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Rene Herman <rene.herman@...access.nl>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	Hans de Goede <j.w.r.degoede@....nl>,
	linux-acpi@...r.kernel.org, Zhang Rui <rui.zhang@...el.com>,
	"Mark M. Hoffman" <mhoffman@...htlink.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org
Subject: Re: LMSENSORS: 2.6.26-rc,  enabling ACPI Termal Zone support costs sensors

On Mon, Jun 23, 2008 at 02:35:03PM +0200, Rene Herman wrote:
> libsensors dictated the ABI rule that the hwmon directories must have 
> device backlinks; the new ACPI Thermal Zone hwmon interface breaks that 
> bit of ABI. It is not relevant that that ABI may have gotten to be as a 
> result of unfortunate programming on the userspace side -- the only 
> thing relevant is that it IS. lm-sensors 2 is on millions of systems out 
> there. This is not meant agressively, or whatever you guys seem to want 
> to read in my words, it's un undeniable fact.

No, libsensors made an assumption about the ABI that turns out not to be 
true. The ABI hasn't changed, libsensors is just being exposed to a case 
it didn't previously see.

We've had this kind of change before. The ACPI backlight code changed in 
such a way that scripts that blindly wrote values instead of (correctly) 
reading the maximum brightness value broke. mmap's behaviour changed in 
such a way that it was no longer possible for vm86 to execute code that 
wasn't mapped as executable, breaking libx86. The applications in 
question were undeniably buggy. Those are examples that I was personally 
involved with - I'm sure there are others. Where userspace has made 
false assumptions, it's not the kernel's responsibility to continue to 
support those assumptions.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/