[PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
emil.l.velikov at gmail.com
Mon May 27 13:47:52 UTC 2019
On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at 09:17:29AM +0100, Emil Velikov wrote:
> > 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.
> Maybe correction here: Id does not care about authentication at all. It
> wants to figure out whether it has access to modeset resources, which is
> something entirely different, but happened to match in amdgpu's case.
It feels like we have conflated the two (perhaps due to historical
reasons) and I'm not 100% sure which one the AMDGPU code inspects.
Hence we can drop the DRM_AUTH all together (details in follow-up patch)
yet that cause a regression in some userspace, when it conflates the
authentication status with access to modeset resources.
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.
> > 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
> Hm I think I'm blind, I'm not seeing the fix merged to mesa master. Still
> there on gitlab:
> What am I missing?
Opted for a simple, more generic solution see commit
This way, the same check is:
- enforced where it's used
- present for all Mesa Vulkan drivers
Will include the sha + commit title for v2.
> > Add a special quirk for that case, thus we can drop DRM_AUTH bits as
> > mentioned earlier.
> > Since all the affected userspace is EOL, we also add a kconfig option
> > to disable this quirk.
> > The whole approach is inspired by DRIVER_KMS_LEGACY_CONTEXT
> > Cc: Alex Deucher <alexander.deucher at amd.com>
> > Cc: Christian König <christian.koenig at amd.com>
> > Cc: amd-gfx at lists.freedesktop.org
> > Cc: David Airlie <airlied at linux.ie>
> > Cc: Daniel Vetter <daniel at ffwll.ch>
> > Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
> Aside from the nits I think reasonable approach.
Great, glad to hear. Now all we need is to bribe^Wconvince Christian.
More information about the amd-gfx