From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 352F51382C5 for ; Wed, 9 May 2018 07:57:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 253FAE0BAA; Wed, 9 May 2018 07:57:16 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8780FE0AD1 for ; Wed, 9 May 2018 07:57:15 +0000 (UTC) Received: from monk.localnet ([46.5.19.123]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LpKKr-1edysi1RPZ-00f76I; Wed, 09 May 2018 09:57:01 +0200 From: Dennis Schridde To: gentoo-dev@lists.gentoo.org Cc: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= Subject: Re: [gentoo-dev] Access to DRM render nodes from portage sandbox? Date: Wed, 09 May 2018 09:56:53 +0200 Message-ID: <1633461.yP7ybrhVju@monk> In-Reply-To: <1525851283.1846.1.camel@gentoo.org> References: <2409241.tZaIjLR7Sc@monk> <1525851283.1846.1.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1579317.h7zAP719hp"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Provags-ID: V03:K1:2uJKjIaGo/2H2YfPrN72c1tKYdank0qkIDD7FbIYJkdT3FhnN1V lg8ttnU9sovIpNwZuzYA+QhPoZJscvRkg7z5gK/bz7EgCpG2Dy1wTXMBMfVnLWQbacUPCMo XD/A46o2Qmoq8Px/fqEEfRcQGaZeZ166pZAquoNwPKGgl7522ujt4f4iMeTQReDx629Mh+4 +K0AjQbbCOAqR1XSCTuzg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Nya2lr+p/tI=:5FCleh8Qy9yVPOIZGo2pMX Pxj302xKXnFHjPjKFNPBpWKi0aOQe4fr/RyoSGIx1JEG5ihrP3E+stQroQnb9C4KUmoMxUxXT hmCTx9Kak2bOAjaClnBvtAL4BqboY0YO0/n9pWvDfWhXDNY4QboBTvb7uLsq1Xa2vpCLTFMM3 C9EwkAoJLrKdhBp87L658FHFr0vc7p48DthJhUHFb9YsI3cysMB9KzytcrlFI6ipbKVEDjIsu QxW434dsDOoHMmXVRjzNk51mLwP3NUaDsemLLf9+qENxKgjRD/b1ISECaG5MWT5LGd211VNid DKkESzRyOycbzWvoa7MYD6vYbogGbBBOzQqe2pPwaHbRJ4nMlYm514ReCXNHx+Tyk1BmGidTL fl05vhOJ9+1cIe37ABcg7hGCgcBybWesZRq5V3DI6usnBzDOWLQT4A7EOiyN1e5vn9R8pRhVo Ac3GSGcXNYR0WkbpcLy6D+0hdaZ1dzJmRhkeLJ2eIv8jnLfzGZT2QrOX5QmIWwAEao0Pe2K86 OL8tG3RdHpIf+O2ME5IQOrnO02hNM0nC0Gs4idcQZzmtlDE2aafBtEDixiStE8nHnE4hrBsNK kz3PnUA9zaWv7BDsPwbx2XTPBAnBXdAk2OLZnr9b9h5dwoirQo7Q7Pn7ElSgCEIj5ETDFvA79 oPvVdTgEC7WIzGFtGLXNf3qwsesLFed5hKeSUxlD4LcrFALYPU319WS/LNQPpe+7mICdrsD6n h2BIL4WCl7nVz/1HGxOuK4Hub3fJBvHOYNa7jbfF0NSqXnCdbxblJyVzGoc= X-Archives-Salt: d5a207ec-1509-4c37-a8ed-b89ab14e570a X-Archives-Hash: 0cf9cb4a18a5f93dca0a297ab2a6e870 --nextPart1579317.h7zAP719hp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 9 May 2018 09:34:43 CEST Micha=C5=82 G=C3=B3rny wrote: > W dniu =C5=9Bro, 09.05.2018 o godzinie 08=E2=88=B651=E2=80=89+0200, u=C5= =BCytkownik Dennis >=20 > Schridde napisa=C5=82: > > I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ > > renderD128" pop up for more and more packages, probably since OpenCL > > becomes used more widely. Hence I would like to ask: Could we in Gentoo > > treat GPUs just like CPUs and allow any process to access render nodes > > (i.e. the GPUs compute capabilities via the specific interface the Linux > > kernel's DRM offers for that purpose) without sandbox restrictions? > >=20 > > See-Also: https://bugs.gentoo.org/654216 >=20 > Doesn't accessing those nodes involve a risk of programs being able to > crash your system (or xorg)? Or cause on-screen artifacts? Well, in the presence of Linux kernel bugs, programs could crash the whole= =20 system. But I believe this is also true for all other drivers and compute= =20 devices, including CPUs. I assume an application using render nodes could crash X by e.g. consuming = all=20 memory. But then this is also true for all applications using the CPU and = its=20 attached memory for computations. On-screen artifacts as in resolution switching and other KMS operations is= =20 explicitly prohibited. Insecure access (using GEM FLINK) to the memory of= =20 other applications (which could cause broken textures / windows with broken= =20 content) is also explicitly prohibited. So my understanding is that the=20 answer is: No, using render nodes cannot cause on-screen artifacts (modulo = the=20 presence of Linux kernel bugs, s.a.). DRM render nodes were specifically introduced to allow GPGPU applications t= o=20 run without impacting the security of the system (and without X). The Linux kernel documentation contains some information on the concept: * https://www.kernel.org/doc/html/v4.16/gpu/drm-uapi.html#render-nodes As well as an older blog post by David Herrmann: * https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-node= s/ And the Wikipedia article on DRM: * https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes =2D-Dennis --nextPart1579317.h7zAP719hp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGyBAABCAAdFiEE0Ngi/nirHnbsz3NFz+h/M161qdwFAlryqcUACgkQz+h/M161 qdz0Fwv2K4njndkdeBMdBleaxqKBQhidi66fHnRYMb1MMX/nNfDGgHouQgNHxnUJ 1o+AqZtU3C2xE/vro/5DwhEDNvojaza3tqOai8d7cjuhcM2jCueJNTlMwNbWXOZs 3drWiTVW5LUJrgtLY6cm/AyTx+nBRkYq/qkXVRAqKZjhVLEupv1Wi9axRGtYWhBJ Q17tfoNaBqZvDTTL+UXBesBLgXIZXn3655mMMCJ7IcXx+dYGkd9ykvL+R67N+HiF Tyb8U+kw3tl/KoUZMiWVe1mD1ccFnzxiorqOsS05LU9Vr1k+1AnE53DNgajeLhIs 8456cImYVwLFm9kLN0vemTG5f58ZtpSUAYzZ+hTrIodIVS2PWqOlqMODCrXcz4E2 epkVeDQgifA9ohYaa6U+RzZrHFGPUEuiGZQlqIfgC8B6tLaI9jyLG2w23OOLd6eT PPKqAa8KHFuzfHLFFc3PV9qw9CDRvSN4UYgwMN4MYpfB0zJ22ORQLF1Nj35xZkUg 9dK/Rz0= =9tJc -----END PGP SIGNATURE----- --nextPart1579317.h7zAP719hp--