On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote: > version 10 changes: > - rebased on kernel 4.8 tag > - minor typo fix > > version 9 changes: > - rebased on 4.8-rc5 > - struct dma_attrs doesn't exist anymore so update CMA allocator > to compile with new dma_*_attr functions > - add example SMAF use case in cover letter > > version 8 changes: > - rework of the structures used within ioctl > by adding a version field and padding to be futur proof > - rename fake secure moduel to test secure module > - fix the various remarks done on the previous patcheset > > version 7 changes: > - rebased on kernel 4.6-rc7 > - simplify secure module API > - add vma ops to be able to detect mmap/munmap calls > - add ioctl to get number and allocator names > - update libsmaf with adding tests > https://git.linaro.org/people/benjamin.gaignard/libsmaf.git > - add debug log in fake secure module > > version 6 changes: > - rebased on kernel 4.5-rc4 > - fix mmapping bug while requested allocation size isn't a a multiple of > PAGE_SIZE (add a test for this in libsmaf) > > version 5 changes: > - rebased on kernel 4.3-rc6 > - rework locking schema and make handle status use an atomic_t > - add a fake secure module to allow performing tests without trusted > environment > > 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 > > SMAF aim to solve two problems: allocating memory that fit with hardware IPs > constraints and secure those data from bus point of view. > > One example of SMAF usage is camera preview: on SoC you may use either an USB > webcam or the built-in camera interface and the frames could be send directly > to the dipslay Ip or handle by GPU. > Most of USB interfaces and GPU have mmu but almost all built-in camera > interace and display Ips don't have mmu so when selecting how allocate > buffer you need to be aware of each devices constraints (contiguous memroy, > stride, boundary, alignment ...). > ION has solve this problem by let userland decide which allocator (heap) to use > but this require to adapt userland for each platform and sometime for each > use case. > > 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. > > In the same camera preview use case, SMAF allow to protect the data from being > read by unauthorized IPs (i.e. a malware to dump camera stream). > Until now I have only see access rights protection at process/thread level > (PKeys/MPK) or on file (SELinux) but nothing allow to drive data bus firewalls. > SMAF propose an interface to control and implement those firewalls. > Like IOMMU, firewalls IPs can help to protect memory from malicious/faulty devices > that are attempting DMA attacks. > > 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. semi-random review comment, and a bit late: Why not implement smaf as a new heap in ion? I think consensus is pretty much that we'll be stuck with ion forever, and I think it's better to have 1 central buffer allocater than lots of them ... -Daniel > > Benjamin Gaignard (3): > create SMAF module > SMAF: add CMA allocator > SMAF: add test secure module > > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/smaf/Kconfig | 17 + > drivers/smaf/Makefile | 3 + > drivers/smaf/smaf-cma.c | 186 ++++++++++ > drivers/smaf/smaf-core.c | 818 +++++++++++++++++++++++++++++++++++++++++ > drivers/smaf/smaf-testsecure.c | 90 +++++ > include/linux/smaf-allocator.h | 45 +++ > include/linux/smaf-secure.h | 65 ++++ > include/uapi/linux/smaf.h | 85 +++++ > 10 files changed, 1312 insertions(+) > create mode 100644 drivers/smaf/Kconfig > create mode 100644 drivers/smaf/Makefile > create mode 100644 drivers/smaf/smaf-cma.c > create mode 100644 drivers/smaf/smaf-core.c > create mode 100644 drivers/smaf/smaf-testsecure.c > create mode 100644 include/linux/smaf-allocator.h > create mode 100644 include/linux/smaf-secure.h > create mode 100644 include/uapi/linux/smaf.h > > -- > 1.9.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
