[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56132CF2.3060902@redhat.com>
Date: Mon, 5 Oct 2015 19:07:46 -0700
From: Laura Abbott <labbott@...hat.com>
To: Benjamin Gaignard <benjamin.gaignard@...aro.org>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, daniel.vetter@...ll.ch,
robdclark@...il.com, treding@...dia.com, sumit.semwal@...aro.org,
tom.cooksey@....com, daniel.stone@...labora.com,
linux-security-module@...r.kernel.org, xiaoquan.li@...antecorp.com
Cc: tom.gall@...aro.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v4 0/2] RFC: Secure Memory Allocation Framework
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists