Freescale Linux BSP review

[Dave Airlie]

On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey <matt at genesi-usa.com> wrote:
> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>>
>>> >> My point which people keep missing is that graphics stacks are a
>>> >> single entity, that span kernel and userspace, one cannot exist
>>> >> without the other, and there are interfaces that join them.
>>> >
>>> > As a copyright holder on the kernel I'll also remind the people concerned
>>> > that the definition of a derivative work is a legal not a technical one
>>> > and if the kernel and user space cannot be used except together and one
>>> > half depends on GPL elements I hope your lawyers have reviewed it
>>> > carefully. I have never given anyone permission to link my GPL kernel
>>> > contributions with anything but GPL code, modular or otherwise, except
>>> > according to the derivative work rules laid down by the GPL (and indeed
>>> > by the boundaries placed on copyright law).
>>>
>>> but it can be circumvented by writing GPL driver which will act as 'glue
>>> logic' inbetween userspace driver and which will work in kernel space?
>>>
>>> technically then driver would be GPL, except it's closed parts which will
>>> be ran in userspace... or can you forbid usage of certain closed userspace
>>> components with kernel?
>>
>> Anyone can try shipping this and risk a lawsuit, and all copyright holders
>> of the kernel can try suing people that distribute such code. Most sensible
>> people stay out of both the shipping questionable code and the suing part,
>> but apparently the entire mobile phone industry is already doing both, so
>> we can just wait and see if anyone has deep enough pockets to bring this
>> up in court first ;-).
>
> Nobody will because it is unenforcable.
>
> The GPLv2 is written such that the "if you're interfacing the kernel
> or compiler you don't need to opensource that bit with your app"
> clause can actually be manipulated to basically disavow closed source
> code from having to be published as open source if it interfaces with
> the standard operating system components. It is meant to protect
> software developers from having to bundle a gigabyte of kernel and
> compiler code with their 100 line app that uses an ioctl, but legally
> it works against  the GPL in this way. It is what means AMD, nVidia,
> Intel (hi Alan), and others can produce binary code and binary
> executables that run on opensource kernels (wireless regulatory daemon
> in the early days) basically with impunity.
>
> You may think it's a horrible idea, and from a technical perspective
> it is, but from a legal perspective.. it's not a problem.

You should probably refrain from stating legal opinions around here,
Alan stated there is a possible issue legally and you should talk to
lawyers. I find his reasoning to be sane but no idea if its legal. The
point you are missing (you seem to not think much before typing) is
this:

you have two pieces of code, a userspace 3D *driver* (not
application), and a kernel driver talking to the hw, if the userspace
3D driver cannot exist without the kernel driver, it could very well
be considered a derivative work of the kernel driver. You are not
protected by the standard Linux system call exception since it states
"normal system calls", so adding a driver to the kernel to expose a
bunch of driver specific ioctls to allow the userspace 3D work blurs
the lines sufficiently that you are into the domain of derived works
and should call your lawyers.


>
> Frankly, this discussion (besides the sidetrack to the non-existant
> legal issues) did pop up a major problem in the possibility of
> unifying the IPU, dual GPU and other graphics subsystem frameworks on
> the i.MX processor line, and potentially others too (TI's LCDC and PVR
> graphics) in that DRM/DRI security policy will forbid them (in the
> form of David Arlie complaining) from sharing the same memory area,
> MMUs on or off. This actually means all 2D, 2D acceleration, 3D
> acceleration and DMA between the units requires bounce buffers and
> some overly complicated memory copying between memory areas for them
> to interoperate. I think TI hit this problem trying to get a texture
> from the DSP to the GPU to render it to a texture and came up with an
> awful (closed source :) method of ioctls and so on to achieve it. I
> had an idea to solve it using DRM and GEM but it's been shot down in
> concept now... what's the point? It'll never get into mainline.

I never said the security policy would forbid anything, I said they
need to prove
that they've thought about these things and can prove they are secure, if this
requires opening the code and/or documents then that is the way it is. The
thing is if you require a userspace application with user privs to
access these devices
then you must stop the user from doing bad things, from my experience vendors
give little concern for these issues until

a) upstream people point out the problem and refuse to merge
b) they are used as the rootkit entry point.

Dave.