linux-kernel - Re: [RFC] Simple userspace interface for PCI drivers

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: <20060831213935.GA11939@kroah.com>
Date:	Thu, 31 Aug 2006 14:39:35 -0700
From:	Greg KH <greg@...ah.com>
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	Lee Revell <rlrevell@...-job.com>,
	Xavier Bestel <xavier.bestel@...e.fr>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] Simple userspace interface for PCI drivers

On Thu, Aug 31, 2006 at 02:53:58PM -0600, Chris Friesen wrote:
> Lee Revell wrote:
> 
> >Why?  There's no technical or legal requirement for userspace drivers to
> >be GPLed.
> 
> I could see a benefit to tainting the kernel once userspace starts 
> poking at the hardware directly.  That way at least we'd know that a 
> crash might be due to userspace doing bad things.
> 
> For instance, consider the case where userspace misprograms a DMA 
> engine, which starts overwriting random kernel memory.

Then you get to keep the two pieces that the kernel just broke into.

We can't "taint" anything here.  Userspace is doing these kinds of
things already today.  You can mmap a PCI device and plug away at all
sorts of fun things with it right now.  You can to /dev/mem fun tricks,
and all sorts of other 'evil' things.

And us kernel developers don't really care.

What this framework does, is give users who already do this kind of
userspace driver thing today, a sane interface in which to do it.  One
that is simple and fast, and makes sense, unlike almost every other
proposal like this that I have seen in the past.

We are trying to help people out here.  Pushing drivers to userspace is
a good thing from a kernel's perspective, if they work well for the
driver in question.  USB has been doing this for years quite well.  This
just allows the PCI interrupt to be sanely handled so PCI and other
types of devices like it, can also work in a well defined way.

If a author of a driver doesn't want to put it in the kernel for
whatever reason, that's fine, do it in userspace.  Not all types of
drivers make sense in the kernel as they don't need any of the things
kernelspace is good for (speed, caching, common userspace interfaces,
etc.)

So there is nothing to worry about here, except for more Linux based,
laser welding robots taking over your neighborhood manufacturing plant.

And to answer the question that everyones been asking me in private, no,
I have no idea if nVidia or ATI can use this interface to move their
kerneldrivers out into userspace.  I've never seen that code and do not
know what their requirements are, nor do I care.  Go ask them, they know
this kind of thing, I sure don't.  And if they can move them there,
bully for them.

I don't know why people have this morbid fascination with these two,
monstrously horrible closed source drivers.  There are way more much
more insidious and common closed source Linux kernel modules out there
right now that everyone in the press seems to be ignoring.  Those are
the ones that I worry about...

And those are the ones that this interface might just help out with, and
if that happens, it is a very good thing for Linux overall.

thanks,

greg k-h
-
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/