From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 1/2] drm: vc4: set permissions for ioctls Date: Fri, 10 Jun 2016 13:08:38 -0700 Message-ID: <87shwkhkmx.fsf@eliezer.anholt.net> References: <1465507165-16345-1-git-send-email-robh@kernel.org> <87vb1ivsir.fsf@eliezer.anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1943491094==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 0FB9C6E180 for ; Fri, 10 Jun 2016 20:08:44 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Emil Velikov Cc: ML dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1943491094== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Emil Velikov writes: > On 10 June 2016 at 00:42, Eric Anholt wrote: >> Rob Herring writes: >> >>> Ioctls generally have DRM_AUTH and DRM_RENDER_ALLOW set to restrict them >>> to authorized clients and render nodes. Without this, access from render >>> nodes fails. >> >> We've already got a fix to add RENDER_ALLOW submitted in the latest >> drm-vc4-fixes. There's no reason to require auth on this >> implementation, though. >> > Not 100% sure but I think you do. At least every other driver does... > > Why: I'm thinking that without DRM_AUTH one will be able to open the > card# node and issue the said IOCTLs even if the client is not > authenticated. Which, obviously isn't a huge deal, but doesn't sound > right. > > Then again, my knowledge of vc4 is virtually non-existent, so there > might be something special happening here ? Let's flip this around: What is the problem you see with calling any of the ioctls without having gone through the auth dance? I don't believe there's any reason to require auth, since you only have access to the buffers you create or import. Basically, auth was created a stopgap solution for "but if anyone had access to the DRM device, they could scrape the X frontbuffer!" --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJXWx5HAAoJELXWKTbR/J7oDAYP/jPPc2J6n0OmKTDNodTRFU9A ykktrlo/xRdWJdMSzPGJvVASIR3y1+5PGf4c7g364PE8LfhQD/sj541uVrzQrC/f 0Irkl95tuVB6trxhPDqfUmTmWWSgPsZdILysPARWMVPZ7wrcaS4wqpLukMxVtCu4 KKdImtpEkLO5sa9KzFJ83wp2b7vRcFc+dqfLr4gxswPPJuIMeIPZLguGs8Yz8yYV Ew9ivI2nZJPCVnJKYlvUqk7a4bqi0wSTu5yGpudB5MCoGXu4zrI9/UEe7yIzwKZT 6P2ONG08h/soOt7HUtlbvQq4Gz4nMPNY5canoru1tLlzTivb7uuljgWLaFc4/uDl Yw29ayrtTze2Oa26bgFhT3DGRMqePODTsQEhm+KmC/H9QnKUsblYKqR9fcYwhS5R 9TfqGky9F2UYaD5aya3UTieUOP8blfq8N5zem0UOl/EQH7WCTaEXX4Ob1Cse5dSA h9l33gWZBeRFEmm6SFNDntT1KINZPtovJTGYb5Tx8qz/lfTreLZkAcuydhY+g4+a EVDChMyufLl99kE3Vf3seCgDHWv/42923ONfY9bvkWKOwEFTcgF8zrcN7Ehn1AYK D0nlWph8DEUOKGG10klkb0nLeXWDVICZ5hQpoYf5okIvLWuB/ZOSmSLbbZjUW+8F gMZ8de6ZGZfVmClpjXmp =yhN0 -----END PGP SIGNATURE----- --=-=-=-- --===============1943491094== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1943491094==--