Re: [MAINTAINER SUMMIT] User-space requirements for accelerator drivers

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi James,

On Fri, Sep 10, 2021 at 02:51:43PM -0700, James Bottomley wrote:
> On Fri, 2021-09-10 at 15:00 -0600, Jonathan Corbet wrote:
> >  - Are there internal kernel interfaces, such as DMA-BUF or P2PDMA,
> > that are only available to drivers with a free user-space
> > implementation? Do we need an EXPORT_SYMBOL_USERSPACE_GPL()?
> 
> I don't think reasonably we can do this.  The kernel GPLv2 licence
> includes this system exception:
> 
>       NOTE! This copyright does *not* cover user programs that use
>    kernel services by normal system calls - this is merely considered
>    normal use of the kernel, and does *not* fall under the heading of
>    "derived work". Also note that the GPL below is copyrighted by the
>    Free Software Foundation, but the instance of code that it refers to
>    (the Linux kernel) is copyrighted by me and others who actually
>    wrote it.
> 
>     Also note that the only valid version of the GPL as far as the
>    kernel is concerned is _this_ particular version of the license (ie
>    v2, not v2.2 or v3.x or whatever), unless explicitly otherwise
>    stated.
> 
> This means currently that once an API is exposed to user space, we've
> given up control of the type of programme (proprietary or open source)
> that may use it.
> 
> It might be possible legally to try and take back that control by
> modifying the system exception (what is a "normal" system call), but I
> personally think that would be unwise and create a raft of other
> problems for other proprietary user space code running on Linux, which
> I really think we don't want to do.

I overall agree that forbidding APIs from being used by closed-source
userspace is likely a no-go from a license point of view, and that it
would create a dangerous precedent and convey a bad message.

> I think our only recourse for user space accelerators is not to export
> the interface if we think it would only be used for evil purposes.

In my opinion the issue at hand isn't so much that the interface can be
used for evil purpose, but that drivers can reap the benefits of being
included in mainline while ignoring (in good faith or not) the
counterpart of allowing all userspace, open or not, to use the device.
The problematic part is usually not the internal kernel interfaces that
those drivers use, but the fact that they expose vendor-specific API
elements to userspace without documenting them.

One obvious option, *if* we decide that this isn't an acceptable
behaviour, is to refuse merging such drivers. DMA-BUF or P2PDMA are not
in themselves problematic, but in the case that Jon mentioned, they
indicate that the device is expected to inter-operate with other devices
by sharing data either through system memory or with direct DMA between
the devices. This makes the absence of an open userspace more
problematic as it may also affect the ability to use other devices in
the system. It could thus be considered as a criteria to decide which
drivers would require at one open userspace, should we decide that not
all drivers would.

-- 
Regards,

Laurent Pinchart