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: <6a89f9d50907201213x8e16e60s38b0a4bd929ce4ca@mail.gmail.com>
Date:	Mon, 20 Jul 2009 21:13:53 +0200
From:	Stephane Marchesin <marchesin@...s.u-strasbg.fr>
To:	Thomas Hellström <thomas@...pmail.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	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

> You obviously got all this completely wrong.
>
> I avoid writing closed source drivers whenever I can, I'm not whining and
> I'm not trying to push any of them. The code VIA is trying to submit has not
> been written by me nor anybody I know. All VIA code I and the companies I've
> worked for has written is open-sourced and contributed to the Openchrome /
> mesa / drm project.
>
> The point I'm trying to make is the following:
>
> If the common agreement of the linux community is to *NOT* allow these
> drivers in, so be it, then be honest and go ahead and tell the driver
> writers. Don't make them respin their development trying to fix minor flaws
> when their driver won't get in anyway!
>

I would like to raise a couple of real-life issues I have in mind:

* First example, let's say VIA gets their Chrome9 DRM merged into the
kernel. Now let's say I reverse engineer the hardware (or use the docs
whenever they're available) and write a 3D component that needs
modifications to the existing DRM interface (or maybe I realize I need
a completely new DRM). Then who gets the upper hand? Do I have to keep
compatibility with user space binary modules that I do not care about?

* Second example, what is the policy if we find security holes in the
DRM for a closed user-space afterwards? This breaks the initial
promise of security, does that get the driver removed then? Or what if
the promise is pending updated documentation that never arrives?

* Third example, what if down the line we need changes in the DRM that
require updating all DRM modules. Do we (we as in DRM developers)
touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking
the code (since we don't test with proprietary modules)? Or do we let
the Chrome9 files as-is, keeping the old DRM infrastructure and
therefore add more and more DRM cruft?

In my opinion, accepting GPL'ed DRM modules that support binary user
space components is like opening pandora's box.

Stephane
--
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/