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

[Gwenole Beauchesne]

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. :)

>> 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?

> 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?

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.

Regards,
Gwenole.