[PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

[Daniel Vetter]

On Mon, May 27, 2019 at 3:42 PM Koenig, Christian
<Christian.Koenig at amd.com> wrote:
>
> Am 27.05.19 um 15:26 schrieb Emil Velikov:
> > On 2019/05/27, Daniel Vetter wrote:
> >> On Mon, May 27, 2019 at 10:47:39AM +0000, Koenig, Christian wrote:
> >>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> >>>> From: Emil Velikov <emil.velikov at collabora.com>
> >>>>
> >>>> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> >>>> render node. A seemingly deliberate design decision.
> >>>>
> >>>> Hence we can drop the DRM_AUTH all together (details in follow-up patch)
> >>>> yet not all userspace checks if it's authenticated, but instead uses
> >>>> uncommon assumptions.
> >>>>
> >>>> After days of digging through git log and testing, only a single (ab)use
> >>>> was spotted - the Mesa RADV driver, using the AMDGPU_INFO ioctl and
> >>>> assuming that failure implies lack of authentication.
> >>>>
> >>>> Affected versions are:
> >>>>    - the whole 18.2.x series, which is EOL
> >>>>    - the whole 18.3.x series, which is EOL
> >>>>    - the 19.0.x series, prior to 19.0.4
> >>> Well you could have saved your time, cause this is still a NAK.
> >>>
> >>> For the record: I strongly think that we don't want to expose any render
> >>> functionality on the primary node.
> >>>
> >>> To even go a step further I would say that at least on AMD hardware we
> >>> should completely disable DRI2 for one of the next generations.
> >>>
> >>> As a follow up I would then completely disallow the DRM authentication
> >>> for amdgpu, so that the command submission interface on the primary node
> >>> can only be used by the display server.
> >> So amdgpu is running in one direction, while everyone else is running in
> >> the other direction? Please note that your patch to change i915 landed
> >> already, so that ship is sailing (but we could ofc revert that back
> >> again).
> >>
> >> Imo really not a great idea if we do a amdgpu vs. everyone else split
> >> here. If we want to deprecate dri2/flink/rendering on primary nodes across
> >> the stack, then that should be a stack wide decision, not an amdgpu one.
> >>
> > Cannot agree more - I would love to see drivers stay consistent.
>
> Yeah, completely agree to that. That's why I think we should not do this
> at all and just let Intel fix it's userspace bugs :P

So you're planning to submit that revert? You did jump the gun with
sending out that patch after all too ... (aside from it got merged
because of some other mixup with r-b tags and what not).
-Daniel

> Anyway my concern is really that we should stop extending functionality
> on the primary node.
>
> E.g. the render node is for use by the clients and the primary node for
> mode setting and use by the display server only.
>
> Regards,
> Christian.
>
> > Fwiw, this series consistently paves the way toward nuking DRM_AUTH ;-)
> >
> > Thanks
> > Emil
>


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