BMC/Intel-BMC/linux.git/drivers/gpu/drm/drm_ioctl.c, branch dev-5.2

drm: introduce a capability flag for syncobj timeline support

2019-05-02T02:36:47+00:00

Unfortunately userspace users of this API cannot be publicly disclosed yet. This commit effectively disables timeline syncobj ioctls for all drivers. Each driver wishing to support this feature will need to expose DRIVER_SYNCOBJ_TIMELINE. v2: Add uAPI capability check (Christian) Signed-off-by: Lionel Landwerlin Reviewed-by: Christian König (v1) Cc: Dave Airlie Cc: Daniel Vetter Cc: Christian König Cc: Chunming Zhou Reviewed-by: Dave Airlie Reviewed-by: Chunming Zhou Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190416125750.31370-1-lionel.g.landwerlin@intel.com

drm: allow removal of legacy codepaths (v4.1)

2019-04-24T02:33:15+00:00

If you don't want the legacy drivers, then lets get rid of all the legacy codepaths from the core module. This drop the size of drm.ko for me by about 10%. 380515 7422 4192 392129 5fbc1 ../../drm-next-build/drivers/gpu/drm/drm.ko 351736 7298 4192 363226 58ada ../../drm-next-build/drivers/gpu/drm/drm.ko v2: drop drm_lock as well, fix some DMA->DRM typos v3: avoid ifdefs in mainline code v4: rework ioctl defs v4.1: fix nouveau Kconfig Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie

Revert "drm: allow render capable master with DRM_AUTH ioctls"

2019-04-17T20:46:33+00:00

This reverts commit 8059add0478e29cb641936011a8fcc9ce9fd80be. This commit while seemingly a good idea, breaks a radv check, for a node being master because something succeeds where it failed before now. Apply the Linus rule, revert early and try again, we don't break userspace. Signed-off-by: Dave Airlie

drm/syncobj: add timeline signal ioctl for syncobj v5

2019-04-01T10:09:00+00:00

v2: individually allocate chain array, since chain node is free independently. v3: all existing points must be already signaled before cpu perform signal operation, so add check condition for that. v4: remove v3 change and add checking to prevent out-of-order v5: unify binary and timeline Signed-off-by: Chunming Zhou Signed-off-by: Christian König Cc: Tobias Hector Cc: Jason Ekstrand Cc: Dave Airlie Cc: Chris Wilson Reviewed-by: Lionel Landwerlin Link: https://patchwork.freedesktop.org/patch/295792/?series=58813&rev=1

drm/syncobj: add transition iotcls between binary and timeline v2

2019-04-01T10:08:44+00:00

we need to import/export timeline point. v2: unify to one transfer ioctl Signed-off-by: Chunming Zhou Signed-off-by: Christian König Reviewed-by: Lionel Landwerlin Link: https://patchwork.freedesktop.org/patch/295790/?series=58813&rev=1

drm/syncobj: add timeline payload query ioctl v6

2019-04-01T10:06:38+00:00

user mode can query timeline payload. v2: check return value of copy_to_user v3: handle querying entry by entry v4: rebase on new chain container, simplify interface v5: query last signaled timeline point, not last point. v6: add unorder point check Signed-off-by: Chunming Zhou Signed-off-by: Christian König Cc: Tobias Hector Cc: Jason Ekstrand Cc: Dave Airlie Cc: Chris Wilson Reviewed-by: Lionel Landwerlin Link: https://patchwork.freedesktop.org/patch/295784/?series=58813&rev=1

drm/syncobj: add support for timeline point wait v8

2019-04-01T10:06:11+00:00

points array is one-to-one match with syncobjs array. v2: add seperate ioctl for timeline point wait, otherwise break uapi. v3: userspace can specify two kinds waits:: a. Wait for time point to be completed. b. and wait for time point to become available v4: rebase v5: add comment for xxx_WAIT_AVAILABLE v6: rebase and rework on new container v7: drop _WAIT_COMPLETED, it is the default anyway v8: correctly handle garbage collected fences Signed-off-by: Chunming Zhou Signed-off-by: Christian König Cc: Tobias Hector Cc: Jason Ekstrand Cc: Dave Airlie Cc: Chris Wilson Reviewed-by: Lionel Landwerlin Link: https://patchwork.freedesktop.org/patch/295782/?series=58813&rev=1

drm: allow render capable master with DRM_AUTH ioctls

2019-02-13T17:42:36+00:00

There are cases (in mesa and applications) where one would open the primary node without properly authenticating the client. Sometimes we don't check if the authentication succeeds, but there's also cases we simply forget to do it. The former was a case for Mesa where it did not not check the return value of drmGetMagic() [1]. That was fixed recently although, there's the question of older drivers or other apps that exbibit this behaviour. While omitting the call results in issues as seen in [2] and [3]. In the libva case, libva itself doesn't authenticate the DRM client and the vaGetDisplayDRM documentation doesn't mention if the app should either. As of today, the official vainfo utility doesn't authenticate. To workaround issues like these, some users resort to running their apps under sudo. Which admittedly isn't always a good idea. Since any DRIVER_RENDER driver has sufficient isolation between clients, we can use that, for unauthenticated [primary node] ioctls that require DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. v2: - Rework/simplify if check (Daniel V) - Add examples to commit messages, elaborate. (Daniel V) v3: - Use single unlikely (Daniel V) [1] https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 Testcase: igt/core_unauth_vs_render Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.velikov@gmail.com

drm: drop DRM_AUTH requirement from AUTH_MAGIC ioctl

2019-02-13T17:37:45+00:00

Currently only an authenticated master can authenticate another client. In practise the client can only be master if CAP_SYS_ADMIN is present, although having the CAP also sets the client as authenticated. Thus DRM_AUTH in AUTH_MAGIC's "DRM_AUTH | DRM_MASTER" is superfluous. Notices while working on IGT tests. Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114084305.15141-1-emil.l.velikov@gmail.com

drm/ioctl: Fix Spectre v1 vulnerabilities

2018-12-20T07:13:29+00:00

nr is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/drm_ioctl.c:805 drm_ioctl() warn: potential spectre issue 'dev->driver->ioctls' [r] drivers/gpu/drm/drm_ioctl.c:810 drm_ioctl() warn: potential spectre issue 'drm_ioctls' [r] (local cap) drivers/gpu/drm/drm_ioctl.c:892 drm_ioctl_flags() warn: potential spectre issue 'drm_ioctls' [r] (local cap) Fix this by sanitizing nr before using it to index dev->driver->ioctls and drm_ioctls. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181220000015.GA18973@embeddedor