linux-kernel - Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via

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: <20090720135844.GA16844@infradead.org>
Date:	Mon, 20 Jul 2009 09:58:44 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Thomas Hellstr?m <thomas@...pmail.org>
Cc:	DRI <dri-devel@...ts.sourceforge.net>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: DRM drivers with closed source user-space: WAS  [Patch 0/3]
	Resubmit VIA Chrome9 DRM via_chrome9 for upstream

On Mon, Jul 20, 2009 at 03:38:32PM +0200, Thomas Hellstr?m wrote:
> Hi!
>
> It appears that GPL'd DRM drivers for closed-source user-space clients  
> are becoming more common, and the situation appears to be causing a lot  
> of unnecessary work from people wanting their drivers in the mainstream  
> kernel. Arguments against pushing upstream include.
>
>    * Security.
>    * User space interface validation and maintainability.
>    * Politics

There are also useless.

> Security:
> I think from a security point of view, open docs and a thorough  
> documented security analysis by the driver writer should be sufficient.  
> This should include:

I think you're just trying to push your agenda.  Every closed driver
I had access to was an utter piece of rubbish so far, and you'll need
the code to prove otherwise.

> User-space interface:
> Historically driver-specific interfaces have really been up to the  
> driver writer and when posted for review they receive very little  
> comments unless there are things like 64/32 bit incompatibilities etc,  
> but as mentioned on the list, small programs that demonstrate the use of  
> all interface functions would be desirable, and very helpful if someone  
> decides to do write an open-source driver.

Unless you actually have a generic userspace working with all drm
drivers you'll also have a very hard time claiming it's not a derived
work of the kernel drm.   Nevermind code not having open userspace is
impossible to test properly.

> Politics:
> It's true that sometimes some people don't like the code or what it  
> does. But when this is the underlying cause of NAK-ing a driver I think  
> it's very important that this is clearly stated, instead of inventing  
> various random reasons that can easily be argued against. How should the  
> driver writer otherwise get it right? Man-years might be spent fixing up  
> drivers that will never get upstream anyway.

I think you're just trying to defend your business writing closed source
drivers.  Drivers that aren't usable without binary blobs don't have
a business in the kernel tree, and your whining doesn't help it.  You'd
be better off spending your time getting proper open drivers done than
defending doing the work to support closed binaries.
--
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/