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: <20090204142015.GB3923@srcf.ucam.org>
Date:	Wed, 4 Feb 2009 14:20:15 +0000
From:	Matthew Garrett <mjg@...hat.com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Hans de Goede <hdegoede@...hat.com>, 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
Subject: Re: [PATCH] ACPI: add "auto" to acpi_enforce_resources

On Wed, Feb 04, 2009 at 02:26:06PM +0100, Jean Delvare wrote:
> On Wed, 4 Feb 2009 13:17:09 +0000, Matthew Garrett wrote:
> > Personally, I'd rather that it was "strict" on everything. We might 
> > break some existing setups, but they're already working mostly by luck.
> 
> Are you the new hwmon and i2c subsystems maintainer and I wasn't aware
> of it?

If you've got some programmatic way to tell the difference between safe 
and dangerous reuse of ACPI resources then that would obviously be 
preferable, but I doubt that's practical. auto is a compromise that 
avoids one specific case of breakage, but it does nothing to protect us 
on the majority of systems. Allowing the firmware and the OS to attempt 
to access the same hardware without any locking is an invitation for 
disaster, and in the absence of any way to prevent the firmware from 
doing it...

But. Hans asked for my opinion - the maintainer's is obviously more 
relevant.
-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ