drm: Remove drm_mode_validate_clocks

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
drm/vma: add access management helpers

The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.

We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.

We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.

As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
 - Most times only a single filp is added per bo so we could use a static
   "struct file *main_filp" which is checked/added/removed first before we
   fall back to the rbtree+drm_vma_offset_file.
   This could be even done lockless with rcu.
 - Let user-space pass a hint whether mmap() should be supported on the
   bo and avoid access-management if not.
 - .. there are probably more ideas once we have benchmarks ..

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/ast: implement mmap access managament

Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.

Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/cirrus: implement mmap access managament

Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.

Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/mgag200: implement mmap access managament

Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.

Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/nouveau: implement mmap access managament

Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.

Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/radeon: implement mmap access managament

Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.

Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/qxl: implement mmap access managament

Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.

Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/vmwgfx: implement mmap access managament

Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager. We also need to make vmw_user_dmabuf_reference()
correctly increase the vma-allow counter, but it is unused so remove it
instead.

Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/ttm: prevent mmap access to unauthorized users

If a user does not have access to a given buffer, we must not allow them
to mmap it. Otherwise, users could "guess" the buffer offsets of other
users and get access to the buffer.
Similar to mmap(), we also fix ttm_bo_io() which is the backend for read()
and write() syscalls. It's currently unused, though.

All TTM drivers already use the new VMA offset manager access management
so we can enable TTM mmap access management now.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/gem: implement mmap access management

Implement automatic access management for mmap offsets for all GEM
drivers. This prevents user-space applications from "guessing" GEM BO
offsets and accessing buffers which they don't own.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm: fix minor number range calculation

Currently, both ranges overlap. Fix the limits so both ranges are mutually
exclusive. Also use the occasion to convert whitespaces to tabs.

Cc: Martin Peres <martin.peres@labri.fr>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm: implement render nodes

Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.

Compared to legacy clients, render clients no longer need any
authentication to perform client ioctls. Instead, user-space controls
render/client access to GPUs via filesystem access-modes on the
render-node. Once a render-node was opened, a client has full access to
the client/render operations on the GPU. However, no modesetting or ioctls
that affect global state are allowed on render nodes.

To prevent privilege-escalation, drivers must explicitly state that they
support render nodes. They must mark their render-only ioctls as
DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
support clients without any attached master.

If filesystem access-modes are not enough for fine-grained access control
to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
you may still fall-back to fd-passing from server to client (which allows
arbitrary access-control). However, note that revoking access is
currently impossible and unlikely to get implemented.

Note: Render clients no longer have any associated DRM-Master as they are
supposed to be independent of any server state. DRM core highly depends on
file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
Therefore, drivers must be very careful to not require DRM-Master if they
support DRIVER_RENDER.

Cc: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/i915: Support render nodes

Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drm/nouveau: Support render nodes

Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.

Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>