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:	Thu, 20 Feb 2014 23:09:42 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	"rja@....com" <rja@....com>
CC:	"lenb@...nel.org" <lenb@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"minyard@....org" <minyard@....org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH V2] Change ACPI IPMI support to "default y"

On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
> On Thu, Feb 20, 2014 at 10:26:45PM +0000, Matthew Garrett wrote:

> > Because I'm trying to ensure that the default behaviour of the kernel is
> > to *work*. Defaulting to having IPMI be modular means that the default
> > behaviour of the kernel, as far as the ACPI spec goes, is to be broken.
> 
> The ACPI spec requires IPMI functionality before a module loads at
> boot time?  And the kernel is *broken* if it does not support ACIP IPMI
> functionality before module load time?  Really?

There's no mechanism to ensure that IPMI support will be loaded before
ACPI calls attempt to access IPMI operation regions. Really.

> > ACPI 4.0 includes support for IPMI operation regions. Modular IPMI means
> > that the kernel will spend a significant amount of time (potentially
> > until a user manually loads a driver) failing to implement part of the
> > IPMI specification. That's a problem, and the correct fix is to ensure
> > that the kernel always implements IPMI support.
> 
> The ACPI spec says ipmi_si cannot be a driver?  Really?
> What is the real problem you are trying to solve?

The most straightforward case is that of an ACPI power meter. Several
vendors implement this with an IPMI operation region. Calling any of the
power meter functions will trigger access to that IPMI operation region,
which will fail. This may result in driver initialisation failing. There
is no express dependency between the power meter driver and ipmi_si,
because the spec envisages IPMI support as basic kernel functionality.
It's meant to be there before you start loading any other drivers.

> > Now, you've described some other problems. I don't disagree that those
> > are problems. The correct thing for us to do with those problems is to
> > fix them, not to simply change the kernel defaults such that it's
> > possible for users to choose between two differently broken states. I'm
> > absolutely willing to help, as long as you're willing to put some
> > reasonable amount of effort into describing them.
> 
> How about ACPI IPMI functionality starts when the ipmi_si
> module loads at boot time.  

I've repeatedly asked for you to provide detailed descriptions of the
problems you've seen because I have a genuine interest in fixing them.
If you're just going to childishly refuse then this discussion is
pointless. 

-- 
Matthew Garrett <matthew.garrett@...ula.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ