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]
Date:	Wed, 04 Feb 2009 09:37:51 +0100
From:	Hans de Goede <hdegoede@...hat.com>
To:	Matthew Garrett <mjg@...hat.com>
CC:	Len Brown <lenb@...nel.org>, Luca Tettamanti <kronos.it@...il.com>,
	Thomas Renninger <trenn@...e.de>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, khali@...ux-fr.org
Subject: Re: [PATCH] ACPI: add "auto" to acpi_enforce_resources



Matthew Garrett wrote:
> On Wed, Feb 04, 2009 at 12:52:06AM -0500, Len Brown wrote:
> 
>> While it is slightly off-topic of the (I agree, real)
>> technical issue here, note that polling is not "normal" on ACPI systems.
>> [1] was on  SuSE Linux 10.0, which on their own decided to
>> over-ride the kernel and enable thermal zone polling by default.
> 
> Checking the DSDTs I have to hand, it seems that polling is expected on 
> about 5% of systems via an explicit _TZP and on almost all machines via 
> _TSP. Even on systems where thermal notifications are provided, it's 
> still up to the OS to poll the zone to find the current temperature and 
> take appropriate action. There's still a window for native smbus drivers 
> to screw everything up.
> 

Note that this not only applies to smbus devices but also to superio devices, 
in general these superio hwmon devices use 2 isa ports an index and a data one, 
image they mayhem which could happen if for example:
native driver sets index
acpi driver sets index
acpi driver reads data
native driver writes data (to a completely wrong register)

We *really* need to be fixing this.

Len, Matthew, what is you opinion of the proposed auto setting for 
acpi_enforce_resources, which is meant to mean strict on known problematic 
systems and lax on others?

Not I'm not asking what you think of the code (yet) just what you think of the 
principle. If we can atleast all agree on this as a compromise not breaking 
hwmon on quite a few systems (the strict setting) while stile providing 
something safer then the current lax, then I'm sure we can hash out any code 
problems soon enough.

Regards,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ