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

From: Daniel Vetter <daniel@ffwll.ch>
To: "Koenig, Christian" <Christian.Koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>
Subject: Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Date: Fri, 21 Jun 2019 11:09:53 +0200	[thread overview]
Message-ID: <20190621090953.GZ12905@phenom.ffwll.local> (raw)
In-Reply-To: <9cad6e74-4751-0b0a-35d1-e8f0ac4d3efc@amd.com>

On Fri, Jun 21, 2019 at 07:12:14AM +0000, Koenig, Christian wrote:
> Am 20.06.19 um 18:30 schrieb Emil Velikov:
> > On 2019/06/14, Koenig, Christian wrote:
> >> Am 14.06.19 um 17:53 schrieb Emil Velikov:
> >>> On 2019/06/14, Koenig, Christian wrote:
> >>>> Am 14.06.19 um 14:09 schrieb Emil Velikov:
> >>>>> On 2019/05/27, Emil Velikov wrote:
> >>>>> [SNIP]
> >>>>> Hi Christian,
> >>>>>
> >>>>>
> >>>>> In the following, I would like to summarise and emphasize the need for
> >>>>> DRM_AUTH removal. I would kindly ask you to spend a couple of minutes
> >>>>> extra reading it.
> >>>>>
> >>>>>
> >>>>> Today DRM drivers* do not make any distinction between primary and
> >>>>> render node clients.
> >>>> That is actually not 100% correct. We have a special case where a DRM
> >>>> master is allowed to change the priority of render node clients.
> >>>>
> >>> Can you provide a link? I cannot find that code.
> >> See amdgpu_sched_ioctl().
> >>
> >>>>> Thus for a render capable driver, any premise of
> >>>>> separation, security or otherwise imposed via DRM_AUTH is a fallacy.
> >>>> Yeah, that's what I agree on. I just don't think that removing DRM_AUTH
> >>>> now is the right direction to take.
> >>>>
> >>> Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW
> >>> ioctls.
> >>>
> >>> That aside, can you propose an alternative solution that addresses this
> >>> and the second point just below?
> >> Give me a few days to work on this, it's already Friday 6pm here.
> >>
> > Hi Christian,
> >
> > Any progress? As mentioned earlier, I'm OK with writing the patches although
> > I would love to hear your plan.
> 
> First of all I tried to disable DRM authentication completely with a 
> kernel config option. Surprisingly that actually works out of the box at 
> least on the AMDGPU stack.
> 
> This effectively allows us to get rid of DRI2 and the related security 
> problems. Only thing left for that is that I'm just not sure how to 
> signal this to userspace so that the DDX wouldn't advertise DRI2 at all 
> any more.
> 
> 
> As a next step I looked into if we can disable the command submission 
> for DRM master. Turned out that this is relatively easy as well.
> 
> All we have to do is to fix the bug Michel pointed out about KMS handles 
> for display and let the DDX use a render node instead of the DRM master 
> for Glamor. Still need to sync up with Michel and/or Marek whats the 
> best way of doing this.
> 
> 
> The last step (and that's what I haven't tried yet) would be to disable 
> DRM authentication for Navi even when it is still compiled into the 
> kernel. But that is more or less just a typing exercise.

So just to get this straight, we're now full on embracing a subsystem
split here:
- amdgpu plans to ditch dri2/rendering on primary nodes
- bunch of drivers (I think more than i915 by now) merged the DRM_AUTH
  removal
- others are just hanging in there somehow

"best of both^W worlds" ftw?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel