linux-kernel - Re: [PATCH] ipmi: add new kernel options to prevent automatic ipmi init

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: <50CB3662.5080100@redhat.com>
Date:	Fri, 14 Dec 2012 09:23:30 -0500
From:	Tony Camuso <tcamuso@...hat.com>
To:	minyard@....org
CC:	Corey Minyard <tcminyard@...il.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	rob.herring@...xeda.com, openipmi-developer@...ts.sourceforge.net,
	grant.likely@...retlab.ca, Robert Evans <Robert.Evans@...atus.com>,
	Jim Paradis <jparadis@...hat.com>
Subject: Re: [PATCH] ipmi: add new kernel options to prevent automatic ipmi
 init

RHEL builds the ipmi_si into the kernel by default, rather than as a
module, because it is required early in order to be available for ACPI
opregion access. However, it appears that some of our customers have
custom ipmi drivers, and this gets in their way.

Stratus is currently evaluating your suggestions, and we are expecting a
response from them sometime today or early next week.

On 12/13/2012 02:51 PM, Corey Minyard wrote:
> Well, the built-in driver works on systems that have more than one interface
> and more than one BMC, and multiple IPMBs (and all of the other channel
> types for that matter, and the driver handles all the multiplexing and nasty
> addressing).  There is, in fact, no arbitrary limit, and IBM tested
> this fairly extensively with some of their systems.  I'm not sure why you
> would need a custom driver, and if there are some custom things that need
> to be done for your servers, I'd be happy to add that.  I've worked with a
> number of other vendors to get changes like this in.  And then ipmitool,
> freeipmi, openipmi, etc. will work with the device.
>
> I don't have a big problem with this patch.  I wonder why you would want
> to compile the standard driver into your kernel if you expected to load a
> module with a custom driver later, though.  None of the distros I know of
> compile it in, it's always a module.
>
> You can also dynamically remove the device from the driver using the hot
> add/remove capability.  To remove it, you can do:
>    echo remove,`cat /proc/ipmi/0/params`
> and it will disassociate that device (IPMI interface 0 in this case) from the
> driver.  So you can iterate through all the devices in /proc/ipmi and
> remove them all at startup.
>
> If none of the above options work for you, we can go ahead with this
> patch.  Just wanted to let you know that current options exist, and see
> if you wanted to take a different direction.
>
> -corey
>
--
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/