From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Peres Subject: [RFC] Complete experimental render node implementation Date: Mon, 17 Dec 2012 02:42:00 +0100 Message-ID: <50CE7868.4040205@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by gabe.freedesktop.org (Postfix) with ESMTP id BC86FE5C48 for ; Sun, 16 Dec 2012 17:42:07 -0800 (PST) Received: from [192.168.1.101] (unknown [89.159.199.232]) (Authenticated sender: martin.peres) by smtp6-g21.free.fr (Postfix) with ESMTPA id 29083822D6 for ; Mon, 17 Dec 2012 02:42:01 +0100 (CET) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Hi, Following to my shared talk with krh, danvet and Timoth=E9e Ravier @ = XDC2012, I have actually taken the time to start fixing some security holes found in the = graphics stack. Today, I would like to request your comments on the render node = patchset. Keep in mind that I am not asking for inclusion. However, I know this patchset works on my = nvidia card and I would like to know if anyone has anything against this architecture. ## DRM If I'm not mistaken, the idea originated from airlied which got = simplified later by krh. Both only provided drm patches. Here is what I did: - I took krh's patchset - rebased it on top on drm 3.7-rc8 - added support for Nouveau - fixed a few bugs along the way (as stated in the commit logs) The kernel can be found here: = https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/render_nodes The patches will also be sent in reply, to let you comment on specific = parts of the patches. ## Libdrm Here are the two main goals of this patchset: - Add a new symbol called drmOpenType that allows to open a specific = type of device (usual node, render node) - Add a new symbol called drmGetSameDeviceButType to get the path to the = same drm_device but with a different type The patches are available here: http://cgit.freedesktop.org/~mperes/drm/ ## DRI2Proto What we want here is to let the ddx send the render node instead of the = usual one. However, authentication is not necessary and not shouldn't be done on a = render node. This modification to DRI2Proto adds a boolean in the Connection response = to tell the dri2 client that no authentication is required. The patches are available here: = http://cgit.freedesktop.org/~mperes/dri2proto/ ## XServer The X-Server is responsible for collecting the DRI2 informations from = the ddx. In this patch, we provide the way for the ddx to specify whether the = DRI2 client should authenticate or not. The patches are available here: http://cgit.freedesktop.org/~mperes/xserver/ ## xf86-video-nouveau In this patch, we simply tell the DRI2 extension to use the render node if available (using drmGetSameDeviceButType), and if it is the case, we set the "require_authentication" attribute to 0. The patches are available here: = http://cgit.freedesktop.org/~mperes/xf86-video-nouveau/ ## Mesa In this patch, I simply check whether I should authenticate or not using = the information from the DRI2 protocol. The patches are available here: http://cgit.freedesktop.org/~mperes/mesa/ Cheers, Martin