From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Enrico Weigelt, metux IT consult" Subject: Re: [RFC] How implement Secure Data Path ? Date: Fri, 8 May 2015 10:55:19 +0200 Message-ID: <554C79F7.2080308@melag.de> References: <20150505175405.2787db4b@lxorguk.ukuu.org.uk> <20150506083552.GF30184@phenom.ffwll.local> <20150506091919.GC16325@ulmo.nvidia.com> <20150506131532.GC30184@phenom.ffwll.local> <20150507132218.GA24541@ulmo.nvidia.com> <20150507135212.GD30184@phenom.ffwll.local> <20150507174003.2a5b42e6@lxorguk.ukuu.org.uk> <20150508083735.GB15256@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150508083735.GB15256@phenom.ffwll.local> Sender: linux-kernel-owner@vger.kernel.org To: One Thousand Gnomes , Thierry Reding , Benjamin Gaignard , "linux-media@vger.kernel.org" , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , Hans Verkuil , Laurent Pinchart , Rob Clark , Dave Airlie , Sumit Semwal , Tom Gall List-Id: dri-devel@lists.freedesktop.org Am 08.05.2015 um 10:37 schrieb Daniel Vetter: > dma-buf user handles are fds, which means anything allocated can be p= assed > around nicely already. The question really is whether we'll have one = ioctl > on top of a special dev node or a syscall. I thought that in these ca= ses > where the dev node is only ever used to allocate the real thing, a sy= scall > is the preferred way to go. I'd generally prefer a /dev node instead of syscall, as they can be dynamically allocated (loaded as module, etc), which in turn offers mor= e finer control (eg. for containers, etc). One could easily replace the it with its own implementation (w/o patching the kernel directly and reboot it). Actually, I'm a bit unhappy with the syscall inflation, in fact I'm not even a big friend of ioctl's - I'd really prefer the Plan9 way :p >> I guess the same kind of logic as with GEM (except preferably withou= t >> the DoS security holes) applies as to why its useful to have handles= to >> the DMA buffers. > > We have handles (well file descriptors) to dma-bufs already, I'm a bi= t > confused what you mean? Just curious (as I'm pretty new to this area): how to GEM objects and dma-bufs relate to each other ? Is it possible to directly exchange buffers between GPUs, VPUs, IPUs, FBs, etc ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg = HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur f=FCr ein= en begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist = ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie gerichtet worden= ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d=FCrfen Sie dies= e nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweis= e in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt=FCmlich er= halten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf = diese Nachricht antworten. Bitte l=F6schen Sie in diesem Fall diese Nac= hricht und alle Anh=E4nge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged i= nformation. It is intended only for the person it was addressed to. If = you are not the intended recipient of this email you may not copy, forw= ard, disclose or otherwise use it or any part of it in any form whatsoe= ver. If you received this email in error please notify the sender by re= plying and delete this message and any attachments without retaining a = copy.