[Libva] [PATCH] drm: improve check for authentication.

[Daniel Vetter]

Adding David Herrmann who's doing the rendernode implementation on the
kernel side.

On Tue, Jul 16, 2013 at 04:26:27PM +0200, Daniel Vetter wrote:
> On Tue, Jul 16, 2013 at 03:32:53PM +0200, Gwenole Beauchesne wrote:
> > Hi,
> > 
> > 2013/7/16 Daniel Vetter <daniel at ffwll.ch>:
> > > On Tue, Jul 16, 2013 at 2:38 PM, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
> > >>
> > >> 2013/7/16 Daniel Vetter <daniel at ffwll.ch>:
> > >>> On Mon, Jul 15, 2013 at 6:30 PM, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
> > >>
> > >>>> On Linux systems, the drmGetClient() function would return the thread ID
> > >>>> instead of the actual process ID.
> > >>>>
> > >>>> Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne at intel.com>
> > >>>
> > >>> Oh dear, why is it always libva. I've prepared a patch to kill this
> > >>> ioctl (almost) completely since it's imo rather pointless. Now I've
> > >>> just discovered that libva uses it and will make it much harder to
> > >>> fake things in the kernel! Or have I just misread the code and it's
> > >>> actually possible to return -EINVAL for this ioctl and libva will
> > >>> transparently fall back to doing the X11 auth stuff?
> > >>
> > >> Yes, we will transparently fallback to X11 auth. In this case, we
> > >> should not check auth status again if X11 auth was successful.
> > >
> > > Re-reading the code you recheck the auth status even if
> > > va_drm_authenticate succeeded, so I think completely breaking the
> > > GET_CLIENT ioctl won't work out.
> > 
> > Yes, this is why I said "we should not check auth status again", thus
> > implying that another patch is needed. :)
> 
> Oh, for kernel work that doesn't help since libva has shipped in this
> configuration, so we get to support it for the next 10 years ;-)
> 
> > >> However, drmGetClient() was used to check we are already
> > >> authenticated. What would the alternative be?
> > >
> > > I've just wondered a bit why libva can't keep track of the auth status
> > > like mesa and only attempt the auth dance once.
> > 
> > There are some provisions to cache the resulting VA/DRM display too,
> > but this is not done yet and it seems that some other layers (driver,
> > or middleware) would not expect that behaviour on the other hand.
> > 
> > BTW, if no X display server is running, are we ensured nowadays that
> > drmAuthMagic() would not silently fail while still returning zero?
> 
> I think currently you can't reliably use a drm device without either a
> display server to authenticate you or being root. Everything else is a
> pretty messy hack.
> 
> > > So imo userspace
> > > doesn't really need to know this information. Anyway it'll all die
> > > with the advent of rendernodes, the only downside is that it'll make
> > > transparently using rendernodes instead of of the legacy nodes for drm
> > > clients a bit more awkward ...
> > 
> > Do you mean, anything more awkward than adding an ioctl to determine
> > if we have a rendernode or a legacy one, or trying to determine the
> > device path from the fd if no ioctl is available for that?
> 
> Imo modern userspace should just not care about whether auth fails or not.
> And iirc mesa doesn't really check that, but mesa also has a pretty
> massive abstraction for the differen windowing systems you can run egl on
> top of. I expect that we need to teach gbm (or similar layers) some smarts
> for running headless clients on rendernodes (so that it tries to open the
> rendernode if they're available before trying legacy nodes).
> 
> But with a display server I really hope X/Wayland could just point the
> client at the respective rendernode and stuff would Just Work.
> 
> > I think, at some point, we also wanted to delegate that auth magic to
> > a third party library, instead of having each client trying to
> > implement its own auth mechanism.
> 
> I think the plan with dri3 is to pass the drm fd from X to the client. X
> can then either pass a rendernode or an authenticated legacy node and the
> X client doesn't have to care at all.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch