Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

14 participants
3243 discussions

[PATCH v5 0/3] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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 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. Benjamin Gaignard (3): create SMAF module SMAF: add CMA allocator SMAF: add fake secure module drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 17 + drivers/smaf/Makefile | 3 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 753 +++++++++++++++++++++++++++++++++++++++++ drivers/smaf/smaf-fakesecure.c | 92 +++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 75 ++++ include/uapi/linux/smaf.h | 52 +++ 10 files changed, 1249 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-fakesecure.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

10 years, 2 months

Re: [Linaro-mm-sig] [PATCH v4 1/2] create SMAF module

by Benjamin Gaignard

Thanks for your review I will add a lock in smaf_handle structure. One of the goal of smaf is to create a standard kernel API to allocate and secure buffers to avoid forking while implementing buffer securing feature. One concern about ION is that the selection of the heap is done by userland so hardware constraints need to be known by the userland, which is problematic from my point of view. Compare to ION I have try to introduce features like securing API, flexible allocator selection on kernel and the possibility to add custom allocator and securing modules. Benjamin 2015-10-06 3:58 GMT+02:00 Laura Abbott <labbott(a)redhat.com>: > On 10/05/2015 03:11 AM, Benjamin Gaignard wrote: >> >> diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c >> new file mode 100644 >> index 0000000..37914e7 >> --- /dev/null >> +++ b/drivers/smaf/smaf-core.c >> @@ -0,0 +1,736 @@ >> +/* >> + * smaf.c >> + * >> + * Copyright (C) Linaro SA 2015 >> + * Author: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> for Linaro. >> + * License terms: GNU General Public License (GPL), version 2 >> + */ >> + >> +#include <linux/device.h> >> +#include <linux/dma-buf.h> >> +#include <linux/dma-mapping.h> >> +#include <linux/fs.h> >> +#include <linux/ioctl.h> >> +#include <linux/list_sort.h> >> +#include <linux/miscdevice.h> >> +#include <linux/module.h> >> +#include <linux/slab.h> >> +#include <linux/smaf.h> >> +#include <linux/smaf-allocator.h> >> +#include <linux/smaf-secure.h> >> +#include <linux/uaccess.h> >> + >> +struct smaf_handle { >> + struct dma_buf *dmabuf; >> + struct smaf_allocator *allocator; >> + struct dma_buf *db_alloc; >> + size_t length; >> + unsigned int flags; >> + int fd; >> + bool is_secure; >> + void *secure_ctx; >> +}; >> + >> +/** >> + * struct smaf_device - smaf device node private data >> + * @misc_dev: the misc device >> + * @head: list of allocator >> + * @lock: list and secure pointer mutex >> + * @secure: pointer to secure functions helpers >> + */ >> +struct smaf_device { >> + struct miscdevice misc_dev; >> + struct list_head head; >> + /* list and secure pointer lock*/ >> + struct mutex lock; >> + struct smaf_secure *secure; >> +}; >> + >> +static struct smaf_device smaf_dev; >> + >> +/** >> + * smaf_allow_cpu_access return true if CPU can access to memory >> + * if their is no secure module associated to SMAF assume that CPU can >> get >> + * access to the memory. >> + */ >> +static bool smaf_allow_cpu_access(struct smaf_handle *handle, >> + unsigned long flags) >> +{ >> + if (!handle->is_secure) >> + return true; >> + >> + if (!smaf_dev.secure) >> + return true; >> + >> + if (!smaf_dev.secure->allow_cpu_access) >> + return true; >> + >> + return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, >> flags); >> +} >> + >> +static int smaf_grant_access(struct smaf_handle *handle, struct device >> *dev, >> + dma_addr_t addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> + if (!handle->is_secure) >> + return 0; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (!smaf_dev.secure->grant_access) >> + return -EINVAL; >> + >> + return smaf_dev.secure->grant_access(handle->secure_ctx, >> + dev, addr, size, dir); >> +} >> + >> +static void smaf_revoke_access(struct smaf_handle *handle, struct device >> *dev, >> + dma_addr_t addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> + if (!handle->is_secure) >> + return; >> + >> + if (!smaf_dev.secure) >> + return; >> + >> + if (!smaf_dev.secure->revoke_access) >> + return; >> + >> + smaf_dev.secure->revoke_access(handle->secure_ctx, >> + dev, addr, size, dir); >> +} >> + >> +static int smaf_secure_handle(struct smaf_handle *handle) >> +{ >> + if (handle->is_secure) >> + return 0; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (!smaf_dev.secure->create_context) >> + return -EINVAL; >> + >> + handle->secure_ctx = smaf_dev.secure->create_context(); >> + >> + if (!handle->secure_ctx) >> + return -EINVAL; >> + >> + handle->is_secure = true; >> + return 0; >> +} >> + >> +static int smaf_unsecure_handle(struct smaf_handle *handle) >> +{ >> + if (!handle->is_secure) >> + return 0; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (!smaf_dev.secure->destroy_context) >> + return -EINVAL; >> + >> + if (smaf_dev.secure->destroy_context(handle->secure_ctx)) >> + return -EINVAL; >> + >> + handle->secure_ctx = NULL; >> + handle->is_secure = false; >> + return 0; >> +} > > > All these functions need to be protected by a lock, otherwise the > secure state could change. For that matter, I think the smaf_handle > needs a lock to protect its state as well for places like map_dma_buf > >> > <snip> > >> +static long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long >> arg) >> +{ >> + switch (cmd) { >> + case SMAF_IOC_CREATE: >> + { >> + struct smaf_create_data data; >> + struct smaf_handle *handle; >> + >> + if (copy_from_user(&data, (void __user *)arg, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + >> + handle = smaf_create_handle(data.length, data.flags); >> + if (!handle) >> + return -EINVAL; >> + >> + if (data.name[0]) { >> + /* user force allocator selection */ >> + if (smaf_select_allocator_by_name(handle->dmabuf, >> + data.name)) { >> + dma_buf_put(handle->dmabuf); >> + return -EINVAL; >> + } >> + } >> + >> + handle->fd = dma_buf_fd(handle->dmabuf, data.flags); >> + if (handle->fd < 0) { >> + dma_buf_put(handle->dmabuf); >> + return -EINVAL; >> + } >> + >> + data.fd = handle->fd; >> + if (copy_to_user((void __user *)arg, &data, >> _IOC_SIZE(cmd))) { >> + dma_buf_put(handle->dmabuf); >> + return -EFAULT; >> + } >> + break; >> + } >> + case SMAF_IOC_GET_SECURE_FLAG: >> + { >> + struct smaf_secure_flag data; >> + struct dma_buf *dmabuf; >> + >> + if (copy_from_user(&data, (void __user *)arg, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + >> + dmabuf = dma_buf_get(data.fd); >> + if (!dmabuf) >> + return -EINVAL; >> + >> + data.secure = smaf_is_secure(dmabuf); >> + dma_buf_put(dmabuf); >> + >> + if (copy_to_user((void __user *)arg, &data, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + break; >> + } >> + case SMAF_IOC_SET_SECURE_FLAG: >> + { >> + struct smaf_secure_flag data; >> + struct dma_buf *dmabuf; >> + int ret; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (copy_from_user(&data, (void __user *)arg, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + >> + dmabuf = dma_buf_get(data.fd); >> + if (!dmabuf) >> + return -EINVAL; >> + >> + ret = smaf_set_secure(dmabuf, data.secure); >> + >> + dma_buf_put(dmabuf); >> + >> + if (ret) >> + return -EINVAL; >> + >> + break; >> + } >> + default: >> + return -EINVAL; >> + } >> + >> + return 0; >> +} > > > How would you see this tying into something like Ion? It seems like > Ion and SMAF have non-zero over lapping functionality for some things > or that SMAF could be implemented as a heap type. I think my biggest > concern here is that it seems like either Ion or SMAF is going to feel > redundant as an interface. > > Thanks, > Laura -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

10 years, 2 months

Re: [Linaro-mm-sig] [PATCH v4 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

I have mind few uses cases: - the basic one when an HW device need contiguous memory. - I have a device that could not cross some memory boundaries so I need a specific allocator for it. - when allocating memory for security some platform have address constraints or need to allocate memory in specific areas (most of the time because of firewall limited capacities in terms of regions) 2015-10-06 4:07 GMT+02:00 Laura Abbott <labbott(a)redhat.com>: > 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 > > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

10 years, 2 months

[PATCH v4 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 736 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 72 ++++ include/uapi/linux/smaf.h | 52 +++ 9 files changed, 1130 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 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

10 years, 2 months

[PATCH weston v2 0/8] Generic Wayland dmabuf protocol

by Pekka Paalanen

From: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Hi all, here is the v2 iteration of the Wayland protocol extension for generic sharing of dmabufs between clients and the compositor. The RFCv1 can be found at http://lists.freedesktop.org/archives/wayland-devel/2014-December/019006.ht… The related tracking bug is https://bugs.freedesktop.org/show_bug.cgi?id=83881 The major changes compared to RFCv1 are: - use drm_fourcc.h to define format codes - support FB modifiers and y-flip - simplified protocol - improved documentation - flags for interlaced buffer content As you can see, we have dropped the "RFC" status from this series now. We think this is in a good enough shape to be merged into Weston as an experimental protocol and implementation. Obviously we are still lacking on: - agreed ways to flush caches (what can we cache? EGLImages? DRM FBs?) - enumerating supported formats - supported FB modifiers? - do all imports in compositor before-hand, not as-needed (the import as DRM FB) - EGL doesn't support dmabuf import with modifiers yet - a test application not specific to (Intel) hardware (vivid?) - compositor-drm.c's import of dmabuf needs a rewrite to bypass GBM (to be done after atomic lands) - compositor-drm.c support for multi-planar buffers This patch series is also available at: https://git.collabora.com/cgit/user/pq/weston.git/log/?h=dmabuf-v2 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Louis-Francis Ratté-Boulianne <lfrb(a)collabora.com> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Axel Davy <axel.davy(a)ens.fr> Cc: linaro-mm-sig(a)lists.linaro.org Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Thomas Hellstrom <thellstrom(a)vmware.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: George Kiagiadakis <george.kiagiadakis(a)collabora.com> George Kiagiadakis (1): clients: add simple-dmabuf client Louis-Francis Ratté-Boulianne (1): gl-renderer: introduce struct egl_image Pekka Paalanen (6): protocol: add linux_dmabuf extension (v2) dmabuf: implement linux_dmabuf extension gl-renderer: add dmabuf import compositor-x11: init linux_dmabuf support compositor-drm: init linux_dmabuf support compositor-drm: dmabuf GBM import .gitignore | 1 + Makefile.am | 25 +- clients/simple-dmabuf.c | 591 ++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 10 + protocol/linux-dmabuf.xml | 279 ++++++++++++++++++++++ src/compositor-drm.c | 49 +++- src/compositor-x11.c | 7 + src/compositor.c | 28 +++ src/compositor.h | 9 + src/gl-renderer.c | 303 +++++++++++++++++++++++- src/linux-dmabuf.c | 497 ++++++++++++++++++++++++++++++++++++++ src/linux-dmabuf.h | 84 +++++++ src/weston-egl-ext.h | 16 ++ 13 files changed, 1885 insertions(+), 14 deletions(-) create mode 100644 clients/simple-dmabuf.c create mode 100644 protocol/linux-dmabuf.xml create mode 100644 src/linux-dmabuf.c create mode 100644 src/linux-dmabuf.h -- 2.3.6 Thanks, pq

10 years, 4 months

[PATCH v3 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 735 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 62 ++++ include/uapi/linux/smaf.h | 52 +++ 9 files changed, 1119 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 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

10 years, 4 months

Re: [Linaro-mm-sig] [PATCH v2 1/2] create SMAF module

by Benjamin Gaignard

I will change the ident in the macro. Thanks, Benjamin 2015-07-07 9:59 GMT+02:00 Paul Bolle <pebolle(a)tiscali.nl>: > A nit only, I'm afraid: a license mismatch. > > On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote: > > --- /dev/null > > +++ b/drivers/smaf/smaf-core.c > > > + * License terms: GNU General Public License (GPL), version 2 > > > +MODULE_LICENSE("GPL"); > > The comment at the top of this file states, succinctly, that the license > is GPL v2. And, according to include/linux/module.h, the > MODULE_LICENSE() macro here states that the license is GPL v2 or later. > So I think that either that comment or the ident used in that macro > needs to change. > > Ditto for 2/2. > > Thanks, > > > Paul Bolle > -- Benjamin Gaignard Graphic Working Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter <http://twitter.com/#!/linaroorg> | Blog <http://www.linaro.org/linaro-blog/>

10 years, 5 months

[PATCH v2 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 751 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 62 ++++ include/uapi/linux/smaf.h | 61 ++++ 9 files changed, 1144 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 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

10 years, 5 months

[GIT PULL]: dma-buf changes for 4.2

by Sumit Semwal

Hi Linus, Very small pull request on dma-buf for 4.2 merge window. May I request you to please pull? The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22: Linux 4.1-rc2 (2015-05-03 19:22:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-4.2 for you to fetch changes up to 5136629dc5a19701746abd7c8ad98ce0b84dda1d: dma-buf: Minor coding style fixes (2015-05-21 11:29:59 +0530) ---------------------------------------------------------------- Minor changes for 4.2 - add ref-counting for kernel modules as exporters - minor code style fixes ---------------------------------------------------------------- Jagan Teki (1): dma-buf: Minor coding style fixes Sumit Semwal (1): dma-buf: add ref counting for module as exporter drivers/dma-buf/dma-buf.c | 19 ++++++++++++++++--- drivers/dma-buf/reservation.c | 9 ++++++--- drivers/dma-buf/seqno-fence.c | 8 +++++++- include/linux/dma-buf.h | 10 ++++++++-- 4 files changed, 37 insertions(+), 9 deletions(-) Thanks and best regards, Sumit.

10 years, 5 months

[PATCH 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 198 ++++++++++++ drivers/smaf/smaf-core.c | 674 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 43 +++ include/linux/smaf-secure.h | 62 ++++ include/uapi/linux/smaf.h | 48 +++ 9 files changed, 1041 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 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

10 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig