linux-kernel - Re: [PATCH][resubmit] HP iLO driver

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:	Tue, 8 Jul 2008 09:21:52 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	"Altobelli, David" <david.altobelli@...com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"greg@...ah.com" <greg@...ah.com>
Subject: Re: [PATCH][resubmit] HP iLO driver

On Mon 2008-07-07 17:37:18, Altobelli, David wrote:
> Pavel Machek wrote:
> > Hi!
> >
> >>>> A driver for the HP iLO/iLO2 management processor, which allows
> >>>> userspace programs to query the management processor. Programs can
> >>>> open a channel to the device (/dev/hpilo/dXccbN), and use this to
> >>>> send/receive queries.
> >>>
> >>> What kind of queries? Is there documentation somewhere?
> >>
> >> Generally, it can get data out of the management processor - things
> >> like basic iLO configuration (users, nic, etc), handle SNMP traffic,
> >> flashing iLO, and some others.
> >>
> >> Unfortunately, there isn't yet any available documenation.
> >
> > Ok, I guess we should have documentation "what does it do" and "what
> > protocol does it speak" before we can think about merging.
> 
> I really hope that isn't the case.

Telling us "what does it do" seems like good start.

> However, I do think there is value in merging the driver without docs.
> Having drivers in tree is often stated as a goal, because of the obvious
> security and API/ABI disadvantages to out of tree drivers.

You know, we'd prefer to have kernel<->user ABI documented. With this
driver... we don't.

What does /dev/hpilo/* do? Beep speakers? Control fans? Launch atomic
bombs? What will happen on cat /bin/bash > /dev/hpilo/dXccbN? Does
that depend on concrete machine? Is it acceptable for this
functionality not to be abstracted out? (Kernel should provide hw
abstraction, right?)

> If this can't be merged, then we continue to ship an out of tree driver,
> which no one (us, distros, customers) likes.  We pester our partners to
> support this driver, or include it, or what have you.  We get slowly
> out of date, and bugs creep in, or our package breaks on upstream kernels.
> To me, it seems like merging the driver is the better path.

Docs for kernel<->user ABI does not seem like too much to ask.

If you wrote a driver, I don't think it is unreasonable for me to ask
"how to use that driver".
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/