[lkml]   [2009]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectDRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

    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

    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:

    1. In what ways can the GPU access random system pages and how is
    user-space prevented from doing that in the driver?
    2. In what ways can the GPU transfer random user data into its own
    privileged command stream and, if relevant, how is that prevented
    in the driver?
    3. Is the driver capable of maintaining video memory ownership and
    (Currently not a requirement)
    4. How is user-space prevented from causing the kernel driver to do
    unlimited allocations of kernel resources, like buffer objects or
    references to them.

    I really don't think an open-source user-space client can add much more
    to this. It can perhaps be used to detect obvious big security flaws but
    that should be apparent also from the open docs and the security analysis.

    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.

    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 it would help a lot of there was a documented set of driver
    features that were required and sufficient for a DRM driver to go
    upstream. It could look something like

    * Kernel coding style obeyed. Passing checkpatch.
    * short description of underlying driver architecture (GEM / TTM /
    Traditional) and future plans
    * Security analysis according to the above.
    * Open user-space source exercising all functions of the driver or
    fully open docs.
    * User-space interface description and relation to future plans.


     \ /
      Last update: 2009-07-20 15:41    [W:0.039 / U:0.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site