because with ion it is up to userland to decide which heap to use and until now userland doesn't have any way to get device constraints... I will prefer let a central allocator (in kernel) decide from the attached devices which allocator is the best. It is what I have implemented in smaf. Benjamin 2016-10-05 15:19 GMT+02:00 Daniel Vetter <daniel@xxxxxxxx>: > 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 -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
