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: Tue, 14 Jun 2016 08:53:22 -0700 Message-ID: <87bn33vkb1.fsf@eliezer.anholt.net> References: <1465507165-16345-1-git-send-email-robh@kernel.org> <87vb1ivsir.fsf@eliezer.anholt.net> <87shwkhkmx.fsf@eliezer.anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0478137405==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 32C076E32B for ; Tue, 14 Jun 2016 15:53:27 +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 , Daniel Vetter Cc: ML dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0478137405== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Emil Velikov writes: > On 10 June 2016 at 21:08, Eric Anholt wrote: >> 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!" > > Personally I don't see any serious issues* with keeping DRM_AUTH out > of these. Although one could argue that the lack of it up-to recently > one was using non-auth access to the card node. The latter of which > lead to the DRM_RENDER_ALLOW going unnoticed. > > That aside, I would urge that we have consistency on the topic. > Whether adding DRM_AUTH to the said VC4 ioctls, dropping DRM_AUTH > everywhere (if DRM_RENDER_ALLOW is present on the said ioclt) or > something else. DRM_AUTH is not safe to remove from other drivers, unless they enforce access control to their buffers. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJXYChzAAoJELXWKTbR/J7ou98P/3oet85t2mwUz5ht5sGCYUoN fI2KSUJDfevsMVhgk42nWPwyCMCGEcHmNgxGLHe+8T00CsAAYit9IdPsrVQqK/A1 BB7Bxjzrs+z5UbNdhvA5HmAIWjLqKeWpuf5Xtyv1Ps/7xRLZqItrZMUPjnHZwx01 H5HNE2zqY6Ei8IfkklwT+K333tAbbByPCV3HDy31QQ2CJmK7vTvjRZrZ6ECHlnH3 2mL6pgVtmlXA0/EmLBUitHvfB/tji2HxI0oYuQqbUtBibWapAsU9YWxgLV2p66CU XZ3dy+r1Ajhm0vRjU1Y2lYJJyK8WNptbFJoAdV7ghwRpg5r80kJukPfycuBHwWZB 5dQ3nHrwc+vPjNU3ElgzoE0DVE1BaGHr8vmkiP52DY+tdR29FPRynUCoM+xrhK0f 4AgEiNUF2nSmktw/4XjjwByDzrE2/VCrzTy+Bn0SWlYdDserhVI8mGy9QkKuyR/f I6+16WkbKxBUhnw2gHRwK20BI1YCasfZNtFt3r33L/WLPBVDOAXyLOFpdECglCus a0sB7IMkrJsNAhjLF2aR8zjtgWmC9NenDFUHtI+mj3umHtXtnBbC8pKUCk9ZoGQX URgE4wkIhiTUzqGvOUJvRYI8pJyuy0dpEdVLno19AtIHLV/nJI65GHwj3iCnCalS TIiJuxN8SCB0EscWWYB8 =F0FR -----END PGP SIGNATURE----- --=-=-=-- --===============0478137405== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0478137405==--