From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laura Abbott Subject: Re: [PATCH v4 0/2] RFC: Secure Memory Allocation Framework Date: Mon, 5 Oct 2015 19:07:46 -0700 Message-ID: <56132CF2.3060902@redhat.com> References: <1444039898-7927-1-git-send-email-benjamin.gaignard@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2C8066E68E for ; Mon, 5 Oct 2015 19:07:50 -0700 (PDT) In-Reply-To: <1444039898-7927-1-git-send-email-benjamin.gaignard@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Benjamin Gaignard , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, daniel.vetter@ffwll.ch, robdclark@gmail.com, treding@nvidia.com, sumit.semwal@linaro.org, tom.cooksey@arm.com, daniel.stone@collabora.com, linux-security-module@vger.kernel.org, xiaoquan.li@vivantecorp.com Cc: linaro-mm-sig@lists.linaro.org, tom.gall@linaro.org List-Id: dri-devel@lists.freedesktop.org T24gMTAvMDUvMjAxNSAwMzoxMSBBTSwgQmVuamFtaW4gR2FpZ25hcmQgd3JvdGU6Cj4gdmVyc2lv biA0IGNoYW5nZXM6Cj4gICAtIHJlYmFzZWQgb24ga2VybmVsIDQuMy1yYzMKPiAgIC0gZml4IG1p c3NpbmcgRVhQT1JUX1NZTUJPTCBmb3Igc21hZl9jcmVhdGVfaGFuZGxlKCkKPgo+IHZlcnNpb24g MyBjaGFuZ2VzOgo+ICAgLSBSZW1vdmUgaW9jdGwgZm9yIGFsbG9jYXRvciBzZWxlY3Rpb24gaW5z dGVhZCBwcm92aWRlIHRoZSBuYW1lIG9mCj4gICAgIHRoZSB0YXJnZXRlZCBhbGxvY2F0b3Igd2l0 aCBhbGxvY2F0aW9uIHJlcXVlc3QuCj4gICAgIFNlbGVjdGluZyBhbGxvY2F0b3IgZnJvbSB1c2Vy bGFuZCBpc24ndCB0aGUgcHJlZmVyZWQgd2F5IG9mIHdvcmtpbmcKPiAgICAgYnV0IGlzIG5lZWRl ZCB3aGVuIHRoZSBmaXJzdCB1c2VyIG9mIHRoZSBidWZmZXIgaXMgYSBzb2Z0d2FyZSBjb21wb25l bnQuCj4gICAtIEZpeCBpc3N1ZXMgaW4gY2FzZSBvZiBlcnJvciB3aGlsZSBjcmVhdGluZyBzbWFm IGhhbmRsZS4KPiAgIC0gRml4IG1vZHVsZSBsaWNlbnNlLgo+ICAgLSBVcGRhdGUgbGlic21hZiBh bmQgdGVzdHMgdG8gY2FyZSBvZiB0aGUgU01BRiBBUEkgZXZvbHV0aW9uCj4gICAgIGh0dHBzOi8v Z2l0LmxpbmFyby5vcmcvcGVvcGxlL2JlbmphbWluLmdhaWduYXJkL2xpYnNtYWYuZ2l0Cj4KPiB2 ZXJzaW9uIDIgY2hhbmdlczoKPiAgIC0gQWRkIG9uZSBpb2N0bCB0byBhbGxvdyBhbGxvY2F0b3Ig c2VsZWN0aW9uIGZyb20gdXNlcnNwYWNlLgo+ICAgICBUaGlzIGlzIHJlcXVpcmVkIGZvciB0aGUg dXNlcyBjYXNlIHdoZXJlIHRoZSBmaXJzdCB1c2VyIG9mCj4gICAgIHRoZSBidWZmZXIgaXMgYSBz b2Z0d2FyZSBJUCB3aGljaCBjYW4ndCBwZXJmb3JtIGRtYV9idWYgYXR0YWNoZW1lbnQuCj4gICAt IEFkZCBuYW1lIGFuZCByYW5raW5nIHRvIGFsbG9jYXRvciBzdHJ1Y3R1cmUgdG8gYmUgYWJsZSB0 byBzb3J0IHRoZW0uCj4gICAtIENyZWF0ZSBhIHRpbnkgbGlicmFyeSB0byB0ZXN0IFNNQUY6Cj4g ICAgIGh0dHBzOi8vZ2l0LmxpbmFyby5vcmcvcGVvcGxlL2JlbmphbWluLmdhaWduYXJkL2xpYnNt YWYuZ2l0Cj4gICAtIEZpeCBvbmUgaXNzdWUgd2hlbiB0cnkgdG8gc2VjdXJlIGJ1ZmZlciB3aXRo b3V0IHNlY3VyZSBtb2R1bGUgcmVnaXN0ZXJlZAo+Cj4gVGhlIG91dGNvbWUgb2YgdGhlIHByZXZp b3VzIFJGQyBhYm91dCBob3cgZG8gc2VjdXJlIGRhdGEgcGF0aCB3YXMgdGhlIG5lZWQKPiBvZiBh IHNlY3VyZSBtZW1vcnkgYWxsb2NhdG9yIChodHRwczovL2xrbWwub3JnL2xrbWwvMjAxNS81LzUv NTUxKQo+Cj4gU01BRiBnb2FsIGlzIHRvIHByb3ZpZGUgYSBmcmFtZXdvcmsgdGhhdCBhbGxvdyBh bGxvY2F0aW5nIGFuZCBzZWN1cmluZwo+IG1lbW9yeSBieSB1c2luZyBkbWFfYnVmLiBFYWNoIHBs YXRmb3JtIGhhdmUgaXQgb3duIHdheSB0byBwZXJmb3JtIHRob3NlIHR3bwo+IGZlYXR1cmVzIHNv IFNNQUYgZGVzaWduIGFsbG93IHRvIHJlZ2lzdGVyIGhlbHBlciBtb2R1bGVzIHRvIHBlcmZvcm0g dGhlbS4KPgo+IFRvIGJlIHN1cmUgdG8gc2VsZWN0IHRoZSBiZXN0IGFsbG9jYXRpb24gbWV0aG9k IGZvciBkZXZpY2VzIFNNQUYgaW1wbGVtZW50Cj4gZGVmZXJyZWQgYWxsb2NhdGlvbiBtZWNoYW5p c206IG1lbW9yeSBhbGxvY2F0aW9uIGlzIG9ubHkgZG9uZSB3aGVuIHRoZSBmaXJzdAo+IGRldmlj ZSBlZmZlY3RpdmVseSByZXF1aXJlZCBpdC4KPiBBbGxvY2F0b3IgbW9kdWxlcyBoYXZlIHRvIGlt cGxlbWVudCBhIG1hdGNoKCkgdG8gbGV0IFNNQUYga25vdyBpZiB0aGV5IGFyZQo+IGNvbXBhdGli bGVzIHdpdGggZGV2aWNlcyBuZWVkcy4KPiBUaGlzIHBhdGNoIHNldCBwcm92aWRlIGFuIGV4YW1w bGUgb2YgYWxsb2NhdG9yIG1vZHVsZSB3aGljaCB1c2UKPiBkbWFfe2FsbG9jL2ZyZWUvbW1hcH1f YXR0cnMoKSBhbmQgY2hlY2sgaWYgYXQgbGVhc3Qgb25lIGRldmljZSBoYXZlCj4gY29oZXJlbnRf ZG1hX21hc2sgc2V0IHRvIERNQV9CSVRfTUFTSygzMikgaW4gbWF0Y2ggZnVuY3Rpb24uCj4gSSBo YXZlIG5hbWVkIHNtYWYtY21hLmMgbGlrZSBpdCBpcyBkb25lIGZvciBkcm1fZ2VtX2NtYV9oZWxw ZXIuYyBldmVuIGlmCj4gYSBiZXR0ZXIgbmFtZSBjb3VsZCBiZSBmb3VuZCBmb3IgdGhpcyBmaWxl Lgo+Cj4gU2VjdXJlIG1vZHVsZXMgYXJlIHJlc3BvbnNpYmxlcyBvZiBncmFudGluZyBhbmQgcmV2 b2tpbmcgZGV2aWNlcyBhY2Nlc3MgcmlnaHRzCj4gb24gdGhlIG1lbW9yeS4gU2VjdXJlIG1vZHVs ZSBpcyBhbHNvIGNhbGxlZCB0byBjaGVjayBpZiBDUFUgbWFwIG1lbW9yeSBpbnRvCj4ga2VybmVs IGFuZCB1c2VyIGFkZHJlc3Mgc3BhY2VzLgo+IEFuIGV4YW1wbGUgb2Ygc2VjdXJlIG1vZHVsZSBp bXBsZW1lbnRhdGlvbiBjYW4gYmUgZm91bmQgaGVyZToKPiBodHRwOi8vZ2l0LmxpbmFyby5vcmcv cGVvcGxlL2JlbmphbWluLmdhaWduYXJkL29wdGVlLXNkcC5naXQKPiBUaGlzIGNvZGUgaXNuJ3Qg eWV0IHBhcnQgb2YgdGhlIHBhdGNoIHNldCBiZWNhdXNlIGl0IGRlcGVuZHMgb24gZ2VuZXJpYyBU RUUKPiB3aGljaCBpcyBzdGlsbCB1bmRlciBkaXNjdXNzaW9uIChodHRwczovL2x3bi5uZXQvQXJ0 aWNsZXMvNjQ0NjQ2LykKPgo+IEZvciBhbGxvY2F0aW9uIHBhcnQgb2YgU01BRiBjb2RlIEkgZ2V0 IGluc3BpcmF0ZWQgYnkgU3VtaXQgU2Vtd2FsIHdvcmsgYWJvdXQKPiBjb25zdHJhaW50IGF3YXJl IGFsbG9jYXRvci4KPgoKT3ZlcmFsbCBJIGxpa2UgdGhlIGFic3RyYWN0aW9uLiBEbyB5b3UgaGF2 ZSBhIHVzZSBjYXNlIGluIG1pbmQgcmlnaHQgbm93IGZvcgp0aGUgYmVzdCBhbGxvY2F0aW9uIG1l dGhvZD8gU29tZSBvZiB0aGUgY2xhc3NpYyBleGFtcGxlcyAobW11IHZzLiBubyBtbXUpCmFyZSBn cmFkdWFsbHkgYmVjb21pbmcgbGVzcyByZWxldmFudCBhcyB0aGUgc3lzdGVtcyBoYXZlIGV2b2x2 ZWQuIEkgd2FzCmRpc2N1c3NpbmcgY29uc3RyYWludHMgd2l0aCBTdW1pdCB3LnIudC4gSW9uIGF0 IHBsdW1iZXJzIHNvIEknbSBjdXJpb3VzIGFib3V0CnlvdXIgdXNlcy4KClRoYW5rcywKTGF1cmEK CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2 ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57110 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751131AbbJFCHu (ORCPT ); Mon, 5 Oct 2015 22:07:50 -0400 Subject: Re: [PATCH v4 0/2] RFC: Secure Memory Allocation Framework To: Benjamin Gaignard , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, daniel.vetter@ffwll.ch, robdclark@gmail.com, treding@nvidia.com, sumit.semwal@linaro.org, tom.cooksey@arm.com, daniel.stone@collabora.com, linux-security-module@vger.kernel.org, xiaoquan.li@vivantecorp.com References: <1444039898-7927-1-git-send-email-benjamin.gaignard@linaro.org> Cc: tom.gall@linaro.org, linaro-mm-sig@lists.linaro.org From: Laura Abbott Message-ID: <56132CF2.3060902@redhat.com> Date: Mon, 5 Oct 2015 19:07:46 -0700 MIME-Version: 1.0 In-Reply-To: <1444039898-7927-1-git-send-email-benjamin.gaignard@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On 10/05/2015 03:11 AM, Benjamin Gaignard wrote: > version 4 changes: > - rebased on kernel 4.3-rc3 > - fix missing EXPORT_SYMBOL for smaf_create_handle() > > version 3 changes: > - Remove ioctl for allocator selection instead provide the name of > the targeted allocator with allocation request. > Selecting allocator from userland isn't the prefered way of working > but is needed when the first user of the buffer is a software component. > - Fix issues in case of error while creating smaf handle. > - Fix module license. > - Update libsmaf and tests to care of the SMAF API evolution > https://git.linaro.org/people/benjamin.gaignard/libsmaf.git > > version 2 changes: > - Add one ioctl to allow allocator selection from userspace. > This is required for the uses case where the first user of > the buffer is a software IP which can't perform dma_buf attachement. > - Add name and ranking to allocator structure to be able to sort them. > - Create a tiny library to test SMAF: > https://git.linaro.org/people/benjamin.gaignard/libsmaf.git > - Fix one issue when try to secure buffer without secure module registered > > The outcome of the previous RFC about how do secure data path was the need > of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) > > SMAF goal is to provide a framework that allow allocating and securing > memory by using dma_buf. Each platform have it own way to perform those two > features so SMAF design allow to register helper modules to perform them. > > To be sure to select the best allocation method for devices SMAF implement > deferred allocation mechanism: memory allocation is only done when the first > device effectively required it. > Allocator modules have to implement a match() to let SMAF know if they are > compatibles with devices needs. > This patch set provide an example of allocator module which use > dma_{alloc/free/mmap}_attrs() and check if at least one device have > coherent_dma_mask set to DMA_BIT_MASK(32) in match function. > I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if > a better name could be found for this file. > > Secure modules are responsibles of granting and revoking devices access rights > on the memory. Secure module is also called to check if CPU map memory into > kernel and user address spaces. > An example of secure module implementation can be found here: > http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git > This code isn't yet part of the patch set because it depends on generic TEE > which is still under discussion (https://lwn.net/Articles/644646/) > > For allocation part of SMAF code I get inspirated by Sumit Semwal work about > constraint aware allocator. > Overall I like the abstraction. Do you have a use case in mind right now for the best allocation method? Some of the classic examples (mmu vs. no mmu) are gradually becoming less relevant as the systems have evolved. I was discussing constraints with Sumit w.r.t. Ion at plumbers so I'm curious about your uses. Thanks, Laura