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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux