so there is discussion about a "central userspace allocator" (ie. more like a common userspace API that could be implemented on top of various devices/APIs) to decide in a generic way which device could allocate. https://github.com/cubanismo/allocator and I wrote up some rough thoughts/proposal about how the usage might look.. just rough, so don't try to compile it or anything, and not consensus yet so it will probably change/evolve.. https://github.com/robclark/allocator/blob/master/USAGE.md I think ion could be just another device to share buffers with, which happens to not impose any specific constraints. How "liballoc-ion.so" backend figures out how to map constraints/usage to a heap is a bit hand-wavey at the moment. BR, -R On Wed, Oct 5, 2016 at 9:40 AM, Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxx> wrote: > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
