Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752808AbbEFIfQ (ORCPT ); Wed, 6 May 2015 04:35:16 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:33113 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751407AbbEFIfM (ORCPT ); Wed, 6 May 2015 04:35:12 -0400 Date: Wed, 6 May 2015 10:37:30 +0200 From: Daniel Vetter To: Laurent Pinchart Cc: Christoph Hellwig , Benjamin Gaignard , "linux-media@vger.kernel.org" , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , Hans Verkuil , Daniel Vetter , Rob Clark , Thierry Reding , Dave Airlie , Sumit Semwal , Tom Gall Subject: Re: [RFC] How implement Secure Data Path ? Message-ID: <20150506083730.GG30184@phenom.ffwll.local> Mail-Followup-To: Laurent Pinchart , Christoph Hellwig , Benjamin Gaignard , "linux-media@vger.kernel.org" , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , Hans Verkuil , Rob Clark , Thierry Reding , Dave Airlie , Sumit Semwal , Tom Gall References: <20150505162752.GA12132@infradead.org> <6502790.6UvsMdppjg@avalon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6502790.6UvsMdppjg@avalon> X-Operating-System: Linux phenom 4.0.0-rc3+ User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1909 Lines: 39 On Wed, May 06, 2015 at 03:50:13AM +0300, Laurent Pinchart wrote: > On Tuesday 05 May 2015 09:27:52 Christoph Hellwig wrote: > > On Tue, May 05, 2015 at 05:39:57PM +0200, Benjamin Gaignard wrote: > > > Since few months I'm looking for Linaro to how do Secure Data Path (SPD). > > > I have tried and implemented multiple thinks but I always facing > > > architecture issues so I would like to get your help to solve the > > > problem. > > > > > > First what is Secure Data Path ? SDP is a set of hardware features to > > > garanty that some memories regions could only be read and/or write by > > > specific hardware IPs. You can imagine it as a kind of memory firewall > > > which grant/revoke accesses to memory per devices. Firewall configuration > > > must be done in a trusted environment: for ARM architecture we plan to > > > use OP-TEE + a trusted application to do that. > > > > > > One typical use case for SDP in a video playback which involve those > > > elements: decrypt -> video decoder -> transform -> display > > > > Sounds like a good enough reason not to implement it ever. > > The irony of it is to post an RFC on they day before > http://www.defectivebydesign.org/dayagainstdrm/ :-) Just for the record: Even though I disagree with the design&threat model for secure memory I don't think we should outright refuse to merge patches. Assuming it comes with a sane design and no blob bits I'd be very much willing to merge support for i915. Unfortunately Intel isn't willing to publish the specs for any of the content protection stuff, at least right now. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/