[PATCH v10 0/3] Secure Memory Allocation Framework

[PATCH v10 0/3] Secure Memory Allocation Framework

[Benjamin Gaignard]

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.

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

[PATCH v10 1/3] create SMAF module

[Benjamin Gaignard]

Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred allocation (i.e. allocate memory when only really needed)

Allocation modules (smaf-alloctor.h):
SMAF could manage with multiple allocation modules at same time.
To select the good one SMAF call match() to be sure that a module
can allocate memory for a given list of devices. It is to the module
to check if the devices are compatible or not with it allocation
method.

Securing module (smaf-secure.h):
The way of how securing memory it is done is platform specific.
Secure module is responsible of grant/revoke memory access.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
 drivers/Kconfig                |   2 +
 drivers/Makefile               |   1 +
 drivers/smaf/Kconfig           |   5 +
 drivers/smaf/Makefile          |   1 +
 drivers/smaf/smaf-core.c       | 818 +++++++++++++++++++++++++++++++++++++++++
 include/linux/smaf-allocator.h |  45 +++
 include/linux/smaf-secure.h    |  65 ++++
 include/uapi/linux/smaf.h      |  85 +++++
 8 files changed, 1022 insertions(+)
 create mode 100644 drivers/smaf/Kconfig
 create mode 100644 drivers/smaf/Makefile
 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

diff --git a/drivers/Kconfig b/drivers/Kconfig
index e1e2066..0697466 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
 
 source "drivers/fpga/Kconfig"
 
+source "drivers/smaf/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 53abb4a..b129ba1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -173,3 +173,4 @@ obj-$(CONFIG_STM)		+= hwtracing/stm/
 obj-$(CONFIG_ANDROID)		+= android/
 obj-$(CONFIG_NVMEM)		+= nvmem/
 obj-$(CONFIG_FPGA)		+= fpga/
+obj-$(CONFIG_SMAF) 		+= smaf/
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
new file mode 100644
index 0000000..d36651a
--- /dev/null
+++ b/drivers/smaf/Kconfig
@@ -0,0 +1,5 @@
+config SMAF
+	tristate "Secure Memory Allocation Framework"
+	depends on DMA_SHARED_BUFFER
+	help
+	  Choose this option to enable Secure Memory Allocation Framework
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
new file mode 100644
index 0000000..40cd882
--- /dev/null
+++ b/drivers/smaf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SMAF) += smaf-core.o
diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
new file mode 100644
index 0000000..1cfd6a7
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,818 @@
+/*
+ * smaf-core.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard <benjamin.gaignard@linaro.org> for Linaro.
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * Secure Memory Allocator Framework (SMAF) allow to register memory
+ * allocators and a secure module under a common API.
+ * Multiple allocators can be registered to fit with hardwrae devices
+ * requirement. Each allocator must provide a match() function to check
+ * it capaticity to handle the devices attached (like defined by dmabuf).
+ * Only one secure module can be registered since it dedicated to one
+ * hardware platform.
+ */
+
+#include <linux/cpu.h>
+#include <linux/device.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;
+	atomic_t 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 long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
+
+static const struct file_operations smaf_fops = {
+	.unlocked_ioctl = smaf_ioctl,
+};
+
+static struct smaf_device smaf_dev = {
+	.misc_dev.minor = MISC_DYNAMIC_MINOR,
+	.misc_dev.name  = "smaf",
+	.misc_dev.fops  = &smaf_fops,
+};
+
+static bool have_secure_module(void)
+{
+	return !!smaf_dev.secure;
+}
+
+/**
+ * smaf_grant_access - return true if the specified device can get access
+ * to the memory area
+ *
+ * This function must be called with smaf_dev.lock set
+ */
+static bool smaf_grant_access(struct smaf_handle *handle, struct device *dev,
+			      dma_addr_t addr, size_t size,
+			      enum dma_data_direction dir)
+{
+	if (!atomic_read(&handle->is_secure))
+		return true;
+
+	if (!have_secure_module())
+		return false;
+
+	return smaf_dev.secure->grant_access(handle->secure_ctx,
+					     dev, addr, size, dir);
+}
+
+/**
+ * smaf_revoke_access
+ * This function must be called with smaf_dev.lock set
+ */
+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 (!atomic_read(&handle->is_secure))
+		return;
+
+	if (!have_secure_module())
+		return;
+
+	smaf_dev.secure->revoke_access(handle->secure_ctx,
+				       dev, addr, size, dir);
+}
+
+static int smaf_secure_handle(struct smaf_handle *handle)
+{
+	void *ctx;
+
+	if (atomic_read(&handle->is_secure))
+		return 0;
+
+	if (!have_secure_module())
+		return -EINVAL;
+
+	ctx = smaf_dev.secure->create_ctx();
+
+	if (!ctx)
+		return -EINVAL;
+
+	handle->secure_ctx = ctx;
+
+	atomic_set(&handle->is_secure, 1);
+	return 0;
+}
+
+static int smaf_unsecure_handle(struct smaf_handle *handle)
+{
+	if (!atomic_read(&handle->is_secure))
+		return 0;
+
+	if (!have_secure_module())
+		return -EINVAL;
+
+	if (smaf_dev.secure->destroy_ctx(handle->secure_ctx))
+		return -EINVAL;
+
+	handle->secure_ctx = NULL;
+	atomic_set(&handle->is_secure, 0);
+	return 0;
+}
+
+int smaf_register_secure(struct smaf_secure *s)
+{
+	/* make sure that secure module have all required functions
+	 * to avoid test them each time later
+	 */
+	if (!s || !s->create_ctx || !s->destroy_ctx ||
+	    !s->grant_access || !s->revoke_access)
+		return -EINVAL;
+
+	mutex_lock(&smaf_dev.lock);
+	smaf_dev.secure = s;
+	mutex_unlock(&smaf_dev.lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(smaf_register_secure);
+
+void smaf_unregister_secure(struct smaf_secure *s)
+{
+	mutex_lock(&smaf_dev.lock);
+	if (smaf_dev.secure == s)
+		smaf_dev.secure = NULL;
+	mutex_unlock(&smaf_dev.lock);
+}
+EXPORT_SYMBOL(smaf_unregister_secure);
+
+static struct smaf_allocator *smaf_find_allocator(struct dma_buf *dmabuf)
+{
+	struct smaf_allocator *alloc;
+
+	list_for_each_entry(alloc, &smaf_dev.head, list_node) {
+		if (alloc->match(dmabuf))
+			return alloc;
+	}
+
+	return NULL;
+}
+
+static struct smaf_allocator *smaf_get_first_allocator(struct dma_buf *dmabuf)
+{
+	/* the first allocator of the list is the preferred allocator */
+	return list_first_entry(&smaf_dev.head, struct smaf_allocator,
+			list_node);
+}
+
+static int smaf_allocate(struct smaf_handle *handle, struct dma_buf *dmabuf)
+{
+	/* try to find an allocator */
+	if (!handle->allocator) {
+		struct smaf_allocator *alloc;
+
+		mutex_lock(&smaf_dev.lock);
+		if (list_empty(&dmabuf->attachments)) {
+			/* no devices attached by default select the first
+			 * allocator
+			 */
+			alloc = smaf_get_first_allocator(dmabuf);
+		} else {
+			alloc = smaf_find_allocator(dmabuf);
+		}
+		mutex_unlock(&smaf_dev.lock);
+
+		/* still no allocator ? */
+		if (!alloc)
+			return -EINVAL;
+
+		handle->allocator = alloc;
+	}
+
+	/* allocate memory */
+	if (!handle->db_alloc) {
+		struct dma_buf *db_alloc;
+
+		db_alloc = handle->allocator->allocate(dmabuf, handle->length);
+		if (!db_alloc)
+			return -EINVAL;
+
+		handle->db_alloc = db_alloc;
+	}
+
+	return 0;
+}
+
+static int smaf_allocator_compare(void *priv,
+				  struct list_head *lh_a,
+				  struct list_head *lh_b)
+{
+	struct smaf_allocator *a = list_entry(lh_a,
+					      struct smaf_allocator, list_node);
+	struct smaf_allocator *b = list_entry(lh_b,
+					      struct smaf_allocator, list_node);
+	int diff;
+
+	diff = b->ranking - a->ranking;
+	if (diff)
+		return diff;
+
+	return strcmp(a->name, b->name);
+}
+
+int smaf_register_allocator(struct smaf_allocator *alloc)
+{
+	if (!alloc || !alloc->match || !alloc->allocate || !alloc->name)
+		return -EINVAL;
+
+	mutex_lock(&smaf_dev.lock);
+	INIT_LIST_HEAD(&alloc->list_node);
+	list_add(&alloc->list_node, &smaf_dev.head);
+	list_sort(NULL, &smaf_dev.head, smaf_allocator_compare);
+	mutex_unlock(&smaf_dev.lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(smaf_register_allocator);
+
+void smaf_unregister_allocator(struct smaf_allocator *alloc)
+{
+	mutex_lock(&smaf_dev.lock);
+	list_del(&alloc->list_node);
+	mutex_unlock(&smaf_dev.lock);
+}
+EXPORT_SYMBOL(smaf_unregister_allocator);
+
+static struct dma_buf_attachment *smaf_find_attachment(struct dma_buf *db_alloc,
+						       struct device *dev)
+{
+	struct dma_buf_attachment *attach_obj;
+
+	list_for_each_entry(attach_obj, &db_alloc->attachments, node) {
+		if (attach_obj->dev == dev)
+			return attach_obj;
+	}
+
+	return NULL;
+}
+
+static struct sg_table *smaf_map_dma_buf(struct dma_buf_attachment *attachment,
+					 enum dma_data_direction direction)
+{
+	struct dma_buf_attachment *db_attachment;
+	struct dma_buf *dmabuf = attachment->dmabuf;
+	struct smaf_handle *handle = dmabuf->priv;
+	struct sg_table *sgt;
+	unsigned int count_done, count;
+	struct scatterlist *sg;
+
+	if (smaf_allocate(handle, dmabuf))
+		return NULL;
+
+	db_attachment = smaf_find_attachment(handle->db_alloc, attachment->dev);
+	sgt = dma_buf_map_attachment(db_attachment, direction);
+
+	if (!sgt)
+		return NULL;
+
+	if (!atomic_read(&handle->is_secure))
+		return sgt;
+
+	mutex_lock(&smaf_dev.lock);
+
+	/* now secure the data */
+	for_each_sg(sgt->sgl, sg, sgt->nents, count_done) {
+		if (!smaf_grant_access(handle, db_attachment->dev,
+				       sg_phys(sg), sg->length, direction))
+			goto failed;
+	}
+
+	mutex_unlock(&smaf_dev.lock);
+	return sgt;
+
+failed:
+	for_each_sg(sgt->sgl, sg, count_done, count) {
+		smaf_revoke_access(handle, db_attachment->dev,
+				   sg_phys(sg), sg->length, direction);
+	}
+
+	mutex_unlock(&smaf_dev.lock);
+
+	sg_free_table(sgt);
+	kfree(sgt);
+	return NULL;
+}
+
+static void smaf_unmap_dma_buf(struct dma_buf_attachment *attachment,
+			       struct sg_table *sgt,
+			       enum dma_data_direction direction)
+{
+	struct dma_buf_attachment *db_attachment;
+	struct dma_buf *dmabuf = attachment->dmabuf;
+	struct smaf_handle *handle = dmabuf->priv;
+	struct scatterlist *sg;
+	unsigned int count;
+
+	if (!handle->db_alloc)
+		return;
+
+	db_attachment = smaf_find_attachment(handle->db_alloc, attachment->dev);
+	if (!db_attachment)
+		return;
+
+	if (atomic_read(&handle->is_secure)) {
+		mutex_lock(&smaf_dev.lock);
+		for_each_sg(sgt->sgl, sg, sgt->nents, count) {
+			smaf_revoke_access(handle, db_attachment->dev,
+					   sg_phys(sg), sg->length, direction);
+		}
+		mutex_unlock(&smaf_dev.lock);
+	}
+
+	dma_buf_unmap_attachment(db_attachment, sgt, direction);
+}
+
+static void smaf_vm_close(struct vm_area_struct *vma)
+{
+	struct smaf_handle *handle = vma->vm_private_data;
+	enum dma_data_direction dir;
+
+	if (vma->vm_flags == VM_READ)
+		dir = DMA_TO_DEVICE;
+
+	if (vma->vm_flags == VM_WRITE)
+		dir = DMA_FROM_DEVICE;
+
+	if (vma->vm_flags == (VM_READ | VM_WRITE))
+		dir = DMA_BIDIRECTIONAL;
+
+	mutex_lock(&smaf_dev.lock);
+	smaf_revoke_access(handle, get_cpu_device(0), 0, handle->length, dir);
+	mutex_unlock(&smaf_dev.lock);
+}
+
+static const struct vm_operations_struct smaf_vma_ops = {
+	.close = smaf_vm_close,
+};
+
+static int smaf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+	bool ret;
+	enum dma_data_direction dir;
+
+	if (smaf_allocate(handle, dmabuf))
+		return -EINVAL;
+
+	vma->vm_private_data = handle;
+	vma->vm_ops = &smaf_vma_ops;
+
+	if (vma->vm_flags == VM_READ)
+		dir = DMA_TO_DEVICE;
+
+	if (vma->vm_flags == VM_WRITE)
+		dir = DMA_FROM_DEVICE;
+
+	if (vma->vm_flags == (VM_READ | VM_WRITE))
+		dir = DMA_BIDIRECTIONAL;
+
+	mutex_lock(&smaf_dev.lock);
+	ret = smaf_grant_access(handle, get_cpu_device(0), 0,
+				handle->length, dir);
+	mutex_unlock(&smaf_dev.lock);
+
+	if (!ret)
+		return -EINVAL;
+
+	return dma_buf_mmap(handle->db_alloc, vma, 0);
+}
+
+static void smaf_dma_buf_release(struct dma_buf *dmabuf)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (handle->db_alloc)
+		dma_buf_put(handle->db_alloc);
+
+	mutex_lock(&smaf_dev.lock);
+	smaf_unsecure_handle(handle);
+	mutex_unlock(&smaf_dev.lock);
+
+	kfree(handle);
+}
+
+static int smaf_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+					 enum dma_data_direction dir)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+	bool ret;
+
+	if (!handle->db_alloc)
+		return -EINVAL;
+
+	mutex_lock(&smaf_dev.lock);
+	ret = smaf_grant_access(handle,
+				get_cpu_device(0), 0, handle->length, dir);
+	mutex_unlock(&smaf_dev.lock);
+
+	if (!ret)
+		return -EINVAL;
+
+	return dma_buf_begin_cpu_access(handle->db_alloc, dir);
+}
+
+static int smaf_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
+				       enum dma_data_direction dir)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+	int ret;
+
+	if (!handle->db_alloc)
+		return -EINVAL;
+
+	ret = dma_buf_end_cpu_access(handle->db_alloc, dir);
+
+	mutex_lock(&smaf_dev.lock);
+	smaf_revoke_access(handle, get_cpu_device(0), 0, handle->length, dir);
+	mutex_unlock(&smaf_dev.lock);
+
+	return ret;
+}
+
+static void *smaf_dma_buf_kmap_atomic(struct dma_buf *dmabuf,
+				      unsigned long offset)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (!handle->db_alloc)
+		return NULL;
+
+	return dma_buf_kmap_atomic(handle->db_alloc, offset);
+}
+
+static void smaf_dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
+				       unsigned long offset, void *ptr)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (!handle->db_alloc)
+		return;
+
+	dma_buf_kunmap_atomic(handle->db_alloc, offset, ptr);
+}
+
+static void *smaf_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (!handle->db_alloc)
+		return NULL;
+
+	return dma_buf_kmap(handle->db_alloc, offset);
+}
+
+static void smaf_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
+				void *ptr)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (!handle->db_alloc)
+		return;
+
+	dma_buf_kunmap(handle->db_alloc, offset, ptr);
+}
+
+static void *smaf_dma_buf_vmap(struct dma_buf *dmabuf)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (!handle->db_alloc)
+		return NULL;
+
+	return dma_buf_vmap(handle->db_alloc);
+}
+
+static void smaf_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (!handle->db_alloc)
+		return;
+
+	dma_buf_vunmap(handle->db_alloc, vaddr);
+}
+
+static int smaf_attach(struct dma_buf *dmabuf, struct device *dev,
+		       struct dma_buf_attachment *attach)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+	struct dma_buf_attachment *db_attach;
+
+	if (!handle->db_alloc)
+		return 0;
+
+	db_attach = dma_buf_attach(handle->db_alloc, dev);
+
+	return IS_ERR(db_attach);
+}
+
+static void smaf_detach(struct dma_buf *dmabuf,
+			struct dma_buf_attachment *attach)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+	struct dma_buf_attachment *db_attachment;
+
+	if (!handle->db_alloc)
+		return;
+
+	db_attachment = smaf_find_attachment(handle->db_alloc, attach->dev);
+	dma_buf_detach(handle->db_alloc, db_attachment);
+}
+
+static const struct dma_buf_ops smaf_dma_buf_ops = {
+	.attach = smaf_attach,
+	.detach = smaf_detach,
+	.map_dma_buf = smaf_map_dma_buf,
+	.unmap_dma_buf = smaf_unmap_dma_buf,
+	.mmap = smaf_mmap,
+	.release = smaf_dma_buf_release,
+	.begin_cpu_access = smaf_dma_buf_begin_cpu_access,
+	.end_cpu_access = smaf_dma_buf_end_cpu_access,
+	.kmap_atomic = smaf_dma_buf_kmap_atomic,
+	.kunmap_atomic = smaf_dma_buf_kunmap_atomic,
+	.kmap = smaf_dma_buf_kmap,
+	.kunmap = smaf_dma_buf_kunmap,
+	.vmap = smaf_dma_buf_vmap,
+	.vunmap = smaf_dma_buf_vunmap,
+};
+
+static bool is_smaf_dmabuf(struct dma_buf *dmabuf)
+{
+	return dmabuf->ops == &smaf_dma_buf_ops;
+}
+
+bool smaf_is_secure(struct dma_buf *dmabuf)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+
+	if (!is_smaf_dmabuf(dmabuf))
+		return false;
+
+	return atomic_read(&handle->is_secure);
+}
+EXPORT_SYMBOL(smaf_is_secure);
+
+int smaf_set_secure(struct dma_buf *dmabuf, bool secure)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+	int ret;
+
+	if (!is_smaf_dmabuf(dmabuf))
+		return -EINVAL;
+
+	mutex_lock(&smaf_dev.lock);
+	if (secure)
+		ret = smaf_secure_handle(handle);
+	else
+		ret = smaf_unsecure_handle(handle);
+	mutex_unlock(&smaf_dev.lock);
+
+	return ret;
+}
+EXPORT_SYMBOL(smaf_set_secure);
+
+static int smaf_select_allocator_by_name(struct dma_buf *dmabuf, char *name)
+{
+	struct smaf_handle *handle = dmabuf->priv;
+	struct smaf_allocator *alloc;
+
+	if (!is_smaf_dmabuf(dmabuf))
+		return -EINVAL;
+
+	if (handle->allocator)
+		return -EINVAL;
+
+	mutex_lock(&smaf_dev.lock);
+
+	list_for_each_entry(alloc, &smaf_dev.head, list_node) {
+		if (!strncmp(alloc->name, name, MAX_NAME_LENGTH)) {
+			handle->allocator = alloc;
+			handle->db_alloc = NULL;
+		}
+	}
+
+	mutex_unlock(&smaf_dev.lock);
+
+	if (!handle->allocator)
+		return -EINVAL;
+
+	return 0;
+}
+
+static struct smaf_handle *smaf_create_handle(size_t length, unsigned int flags)
+{
+	struct smaf_handle *handle;
+
+	DEFINE_DMA_BUF_EXPORT_INFO(info);
+
+	handle = kzalloc(sizeof(*handle), GFP_KERNEL);
+	if (!handle)
+		return NULL;
+
+	info.ops = &smaf_dma_buf_ops;
+	info.size = round_up(length, PAGE_SIZE);
+	info.flags = flags;
+	info.priv = handle;
+
+	handle->dmabuf = dma_buf_export(&info);
+	if (IS_ERR(handle->dmabuf)) {
+		kfree(handle);
+		return NULL;
+	}
+
+	handle->length = info.size;
+	handle->flags = flags;
+
+	return handle;
+}
+
+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;
+
+		if (data.version != 0)
+			return -EINVAL;
+
+		if (data.flags & ~(SMAF_RDWR | SMAF_CLOEXEC))
+			return -EINVAL;
+
+		handle = smaf_create_handle(data.length, data.flags);
+		if (!handle)
+			return -EINVAL;
+
+		if (data.name[0]) {
+			data.name[MAX_NAME_LENGTH - 1] = 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;
+
+		if (data.version != 0)
+			return -EINVAL;
+
+		if (data.fd == -1)
+			return -EINVAL;
+
+		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;
+
+		if (data.version != 0)
+			return -EINVAL;
+
+		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;
+	}
+	case SMAF_IOC_GET_INFO:
+	{
+		struct smaf_info info;
+		struct smaf_allocator *alloc;
+
+		if (copy_from_user(&info, (void __user *)arg, _IOC_SIZE(cmd)))
+			return -EFAULT;
+
+		if (info.version != 0)
+			return -EINVAL;
+
+		info.count = 0;
+		list_for_each_entry(alloc,  &smaf_dev.head, list_node) {
+			if (info.count++ == info.index) {
+				strncpy(info.name, alloc->name,
+					MAX_NAME_LENGTH);
+				info.name[MAX_NAME_LENGTH - 1] = 0;
+			}
+		}
+
+		if (info.index >= info.count)
+			return -EINVAL;
+
+		if (copy_to_user((void __user *)arg, &info, _IOC_SIZE(cmd)))
+			return -EFAULT;
+		break;
+	}
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int __init smaf_init(void)
+{
+	int ret;
+
+	ret = misc_register(&smaf_dev.misc_dev);
+	if (ret < 0)
+		return ret;
+
+	mutex_init(&smaf_dev.lock);
+	INIT_LIST_HEAD(&smaf_dev.head);
+
+	return ret;
+}
+module_init(smaf_init);
+
+static void __exit smaf_deinit(void)
+{
+	misc_deregister(&smaf_dev.misc_dev);
+}
+module_exit(smaf_deinit);
+
+MODULE_DESCRIPTION("Secure Memory Allocation Framework");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@linaro.org>");
diff --git a/include/linux/smaf-allocator.h b/include/linux/smaf-allocator.h
new file mode 100644
index 0000000..ec9a0e1
--- /dev/null
+++ b/include/linux/smaf-allocator.h
@@ -0,0 +1,45 @@
+/*
+ * smaf-allocator.h
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard <benjamin.gaignard@linaro.org> for Linaro.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _SMAF_ALLOCATOR_H_
+#define _SMAF_ALLOCATOR_H_
+
+#include <linux/dma-buf.h>
+#include <linux/list.h>
+
+/**
+ * struct smaf_allocator - implement dma_buf_ops like functions
+ *
+ * @match: match function to check if allocator can accept the devices
+ *	   attached to dmabuf
+ * @allocate: allocate memory with the given length and flags
+ *	      return a dma_buf handle
+ * @name: allocator name
+ * @ranking: allocator ranking (bigger is better)
+ */
+struct smaf_allocator {
+	struct list_head list_node;
+	bool (*match)(struct dma_buf *dmabuf);
+	struct dma_buf *(*allocate)(struct dma_buf *dmabuf, size_t length);
+	const char *name;
+	int ranking;
+};
+
+/**
+ * smaf_register_allocator - register an allocator to be used by SMAF
+ * @alloc: smaf_allocator structure
+ */
+int smaf_register_allocator(struct smaf_allocator *alloc);
+
+/**
+ * smaf_unregister_allocator - unregister alloctor
+ * @alloc: smaf_allocator structure
+ */
+void smaf_unregister_allocator(struct smaf_allocator *alloc);
+
+#endif
diff --git a/include/linux/smaf-secure.h b/include/linux/smaf-secure.h
new file mode 100644
index 0000000..84347a7
--- /dev/null
+++ b/include/linux/smaf-secure.h
@@ -0,0 +1,65 @@
+/*
+ * smaf-secure.h
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard <benjamin.gaignard@linaro.org> for Linaro.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _SMAF_SECURE_H_
+#define _SMAF_SECURE_H_
+
+#include <linux/dma-buf.h>
+#include <linux/dma-mapping.h>
+
+/**
+ * struct smaf_secure
+ * @create_ctx:		create a context for one dmabuf.
+ *			If success return an opaque pointer on secure context
+ *			either return NULL.
+ * @destroy_ctx:	destroy context.
+ * @grant_access:	check and provide access to memory area for a specific
+ *			device. Return true if the request is valid.
+ * @revoke_access:	remove device access rights.
+ */
+struct smaf_secure {
+	void *(*create_ctx)(void);
+	int (*destroy_ctx)(void *ctx);
+	bool (*grant_access)(void *ctx,
+			     struct device *dev,
+			     size_t addr, size_t size,
+			     enum dma_data_direction direction);
+	void (*revoke_access)(void *ctx,
+			      struct device *dev,
+			      size_t addr, size_t size,
+			      enum dma_data_direction direction);
+};
+
+/**
+ * smaf_register_secure - register secure module helper
+ * Secure module helper should be platform specific so only one can be
+ * registered.
+ *
+ * @sec: secure module to be registered
+ */
+int smaf_register_secure(struct smaf_secure *sec);
+
+/**
+ * smaf_unregister_secure - unregister secure module helper
+ */
+void smaf_unregister_secure(struct smaf_secure *sec);
+
+/**
+ * smaf_is_secure - test is a dma_buf handle has been secured by SMAF
+ * @dmabuf: dma_buf handle to be tested
+ */
+bool smaf_is_secure(struct dma_buf *dmabuf);
+
+/**
+ * smaf_set_secure - change dma_buf handle secure status
+ * @dmabuf: dma_buf handle to be change
+ * @secure: if true secure dma_buf handle
+ */
+int smaf_set_secure(struct dma_buf *dmabuf, bool secure);
+
+#endif
diff --git a/include/uapi/linux/smaf.h b/include/uapi/linux/smaf.h
new file mode 100644
index 0000000..b453307
--- /dev/null
+++ b/include/uapi/linux/smaf.h
@@ -0,0 +1,85 @@
+/*
+ * smaf.h
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard <benjamin.gaignard@linaro.org> for Linaro.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _UAPI_SMAF_H_
+#define _UAPI_SMAF_H_
+
+#include <linux/ioctl.h>
+#include <linux/types.h>
+
+#define MAX_NAME_LENGTH 64
+
+#define SMAF_RDWR O_RDWR
+#define SMAF_CLOEXEC O_CLOEXEC
+
+/**
+ * struct smaf_create_data - allocation parameters
+ * @version:	structure version (must be set to 0)
+ * @length:	size of the requested buffer
+ * @flags:	mode flags for the file like SMAF_RDWR or SMAF_CLOEXEC
+ * @fd:		returned file descriptor
+ * @name:	name of the allocator to be selected
+ *		when NULL smaf will iterate over allocator to find
+ *		one matching with devices constraints.
+ */
+struct smaf_create_data {
+	__u64 version;
+	__u64 length;
+	__u32 flags;
+	__u32 reserved1;
+	__s32 fd;
+	__u32 reserved2;
+	__u8 name[MAX_NAME_LENGTH];
+	__u8 reserved3[32];
+};
+
+/**
+ * struct smaf_secure_flag - set/get secure flag
+ * @version:	structure version (must be set to 0)
+ * @fd:		file descriptor
+ * @secure:	secure flag value (set or get)
+ */
+struct smaf_secure_flag {
+	__u64 version;
+	__s32 fd;
+	__u32 reserved1;
+	__u32 secure;
+	__u8 reserved2[44];
+};
+
+/**
+ * struct smaf_info - get registered allocator name per index
+ * @version:	structure version (must be set to 0)
+ * @index:	allocator's index
+ * @count:	return number of registered allocators
+ * @name:	return allocator name
+ */
+struct smaf_info {
+	__u64 version;
+	__u32 index;
+	__u32 reserved1;
+	__u32 count;
+	__u32 reserved2;
+	__u8 name[MAX_NAME_LENGTH];
+	__u8 reserved3[40];
+};
+
+#define SMAF_IOC_MAGIC	'S'
+
+#define SMAF_IOC_CREATE		 _IOWR(SMAF_IOC_MAGIC, 0, \
+				       struct smaf_create_data)
+
+#define SMAF_IOC_GET_SECURE_FLAG _IOWR(SMAF_IOC_MAGIC, 1, \
+				       struct smaf_secure_flag)
+
+#define SMAF_IOC_SET_SECURE_FLAG _IOWR(SMAF_IOC_MAGIC, 2, \
+				       struct smaf_secure_flag)
+
+#define SMAF_IOC_GET_INFO	 _IOWR(SMAF_IOC_MAGIC, 3, struct smaf_info)
+
+#endif
-- 
1.9.1

[PATCH v10 2/3] SMAF: add CMA allocator

[Benjamin Gaignard]

SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.

match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).

For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to be compatible with ARM 64bits architecture

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
 drivers/smaf/Kconfig    |   6 ++
 drivers/smaf/Makefile   |   1 +
 drivers/smaf/smaf-cma.c | 186 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 193 insertions(+)
 create mode 100644 drivers/smaf/smaf-cma.c

diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index d36651a..cfdfffd 100644
--- a/drivers/smaf/Kconfig
+++ b/drivers/smaf/Kconfig
@@ -3,3 +3,9 @@ config SMAF
 	depends on DMA_SHARED_BUFFER
 	help
 	  Choose this option to enable Secure Memory Allocation Framework
+
+config SMAF_CMA
+	tristate "SMAF CMA allocator"
+	depends on SMAF
+	help
+	  Choose this option to enable CMA allocation within SMAF
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 40cd882..05bab01b 100644
--- a/drivers/smaf/Makefile
+++ b/drivers/smaf/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_SMAF) += smaf-core.o
+obj-$(CONFIG_SMAF_CMA) += smaf-cma.o
diff --git a/drivers/smaf/smaf-cma.c b/drivers/smaf/smaf-cma.c
new file mode 100644
index 0000000..6c9840b
--- /dev/null
+++ b/drivers/smaf/smaf-cma.c
@@ -0,0 +1,186 @@
+/*
+ * smaf-cma.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard <benjamin.gaignard@linaro.org> for Linaro.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/smaf-allocator.h>
+
+struct smaf_cma_buffer_info {
+	struct device *dev;
+	size_t size;
+	void *vaddr;
+	dma_addr_t paddr;
+};
+
+/**
+ * find_matching_device - iterate over the attached devices to find one
+ * with coherent_dma_mask correctly set to DMA_BIT_MASK(32).
+ * Matching device (if any) will be used to aim CMA area.
+ */
+static struct device *find_matching_device(struct dma_buf *dmabuf)
+{
+	struct dma_buf_attachment *attach_obj;
+
+	list_for_each_entry(attach_obj, &dmabuf->attachments, node) {
+		if (attach_obj->dev->coherent_dma_mask == DMA_BIT_MASK(32))
+			return attach_obj->dev;
+	}
+
+	return NULL;
+}
+
+/**
+ * smaf_cma_match - return true if at least one device has been found
+ */
+static bool smaf_cma_match(struct dma_buf *dmabuf)
+{
+	return !!find_matching_device(dmabuf);
+}
+
+static void smaf_cma_release(struct dma_buf *dmabuf)
+{
+	struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+	dma_free_attrs(info->dev, info->size, info->vaddr,
+		       info->paddr, DMA_ATTR_WRITE_COMBINE);
+
+	kfree(info);
+}
+
+static struct sg_table *smaf_cma_map(struct dma_buf_attachment *attachment,
+				     enum dma_data_direction direction)
+{
+	struct smaf_cma_buffer_info *info = attachment->dmabuf->priv;
+	struct sg_table *sgt;
+	int ret;
+
+	sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+	if (!sgt)
+		return NULL;
+
+	ret = dma_get_sgtable(info->dev, sgt, info->vaddr,
+			      info->paddr, info->size);
+	if (ret < 0)
+		goto out;
+
+	sg_dma_address(sgt->sgl) = info->paddr;
+	return sgt;
+
+out:
+	kfree(sgt);
+	return NULL;
+}
+
+static void smaf_cma_unmap(struct dma_buf_attachment *attachment,
+			   struct sg_table *sgt,
+			   enum dma_data_direction direction)
+{
+	/* do nothing */
+}
+
+static int smaf_cma_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+	struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+	if (info->size < vma->vm_end - vma->vm_start)
+		return -EINVAL;
+
+	vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+	return dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
+			      info->size, DMA_ATTR_WRITE_COMBINE);
+}
+
+static void *smaf_cma_vmap(struct dma_buf *dmabuf)
+{
+	struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+	return info->vaddr;
+}
+
+static void *smaf_kmap_atomic(struct dma_buf *dmabuf, unsigned long offset)
+{
+	struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+	return (void *)info->vaddr + offset;
+}
+
+static const struct dma_buf_ops smaf_cma_ops = {
+	.map_dma_buf = smaf_cma_map,
+	.unmap_dma_buf = smaf_cma_unmap,
+	.mmap = smaf_cma_mmap,
+	.release = smaf_cma_release,
+	.kmap_atomic = smaf_kmap_atomic,
+	.kmap = smaf_kmap_atomic,
+	.vmap = smaf_cma_vmap,
+};
+
+static struct dma_buf *smaf_cma_allocate(struct dma_buf *dmabuf, size_t length)
+{
+	struct dma_buf_attachment *attach_obj;
+	struct smaf_cma_buffer_info *info;
+	struct dma_buf *cma_dmabuf;
+
+	DEFINE_DMA_BUF_EXPORT_INFO(export);
+
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
+	if (!info)
+		return NULL;
+
+	info->dev = find_matching_device(dmabuf);
+	info->size = length;
+	info->vaddr = dma_alloc_attrs(info->dev, info->size, &info->paddr,
+				      GFP_KERNEL | __GFP_NOWARN,
+				      DMA_ATTR_WRITE_COMBINE);
+	if (!info->vaddr)
+		goto alloc_error;
+
+	export.ops = &smaf_cma_ops;
+	export.size = info->size;
+	export.priv = info;
+
+	cma_dmabuf = dma_buf_export(&export);
+	if (IS_ERR(cma_dmabuf))
+		goto export_error;
+
+	list_for_each_entry(attach_obj, &dmabuf->attachments, node) {
+		dma_buf_attach(cma_dmabuf, attach_obj->dev);
+	}
+
+	return cma_dmabuf;
+
+export_error:
+	dma_free_attrs(info->dev, info->size, &info->paddr,
+		       GFP_KERNEL | __GFP_NOWARN, DMA_ATTR_WRITE_COMBINE);
+alloc_error:
+	kfree(info);
+	return NULL;
+}
+
+static struct smaf_allocator smaf_cma = {
+	.match = smaf_cma_match,
+	.allocate = smaf_cma_allocate,
+	.name = "smaf-cma",
+	.ranking = 0,
+};
+
+static int __init smaf_cma_init(void)
+{
+	return smaf_register_allocator(&smaf_cma);
+}
+module_init(smaf_cma_init);
+
+static void __exit smaf_cma_deinit(void)
+{
+	smaf_unregister_allocator(&smaf_cma);
+}
+module_exit(smaf_cma_deinit);
+
+MODULE_DESCRIPTION("SMAF CMA module");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@linaro.org>");
-- 
1.9.1

[PATCH v10 3/3] SMAF: add test secure module

[Benjamin Gaignard]

This module is allow testing secure calls of SMAF.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
 drivers/smaf/Kconfig           |  6 +++
 drivers/smaf/Makefile          |  1 +
 drivers/smaf/smaf-testsecure.c | 90 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 97 insertions(+)
 create mode 100644 drivers/smaf/smaf-testsecure.c

diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index cfdfffd..73f2ebf 100644
--- a/drivers/smaf/Kconfig
+++ b/drivers/smaf/Kconfig
@@ -9,3 +9,9 @@ config SMAF_CMA
 	depends on SMAF
 	help
 	  Choose this option to enable CMA allocation within SMAF
+
+config SMAF_TEST_SECURE
+	tristate "SMAF secure module for test"
+	depends on SMAF
+	help
+	  Choose this option to enable secure module for test purpose
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 05bab01b..bca6b9c 100644
--- a/drivers/smaf/Makefile
+++ b/drivers/smaf/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_SMAF) += smaf-core.o
 obj-$(CONFIG_SMAF_CMA) += smaf-cma.o
+obj-$(CONFIG_SMAF_TEST_SECURE) += smaf-testsecure.o
diff --git a/drivers/smaf/smaf-testsecure.c b/drivers/smaf/smaf-testsecure.c
new file mode 100644
index 0000000..823d0dc
--- /dev/null
+++ b/drivers/smaf/smaf-testsecure.c
@@ -0,0 +1,90 @@
+/*
+ * smaf-testsecure.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard <benjamin.gaignard@linaro.org> for Linaro.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/smaf-secure.h>
+
+#define MAGIC 0xDEADBEEF
+
+struct test_private {
+	int magic;
+};
+
+#define to_priv(x) (struct test_private *)(x)
+
+static void *smaf_testsecure_create(void)
+{
+	struct test_private *priv;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return NULL;
+
+	priv->magic = MAGIC;
+
+	return priv;
+}
+
+static int smaf_testsecure_destroy(void *ctx)
+{
+	struct test_private *priv = to_priv(ctx);
+
+	WARN_ON(!priv || (priv->magic != MAGIC));
+	kfree(priv);
+
+	return 0;
+}
+
+static bool smaf_testsecure_grant_access(void *ctx,
+					 struct device *dev,
+					 size_t addr, size_t size,
+					 enum dma_data_direction direction)
+{
+	struct test_private *priv = to_priv(ctx);
+
+	WARN_ON(!priv || (priv->magic != MAGIC));
+	pr_debug("grant requested by device %s\n",
+		 dev->driver ? dev->driver->name : "cpu");
+
+	return priv->magic == MAGIC;
+}
+
+static void smaf_testsecure_revoke_access(void *ctx,
+					  struct device *dev,
+					  size_t addr, size_t size,
+					  enum dma_data_direction direction)
+{
+	struct test_private *priv = to_priv(ctx);
+
+	WARN_ON(!priv || (priv->magic != MAGIC));
+	pr_debug("revoke requested by device %s\n",
+		 dev->driver ? dev->driver->name : "cpu");
+}
+
+static struct smaf_secure test = {
+	.create_ctx = smaf_testsecure_create,
+	.destroy_ctx = smaf_testsecure_destroy,
+	.grant_access = smaf_testsecure_grant_access,
+	.revoke_access = smaf_testsecure_revoke_access,
+};
+
+static int __init smaf_testsecure_init(void)
+{
+	return smaf_register_secure(&test);
+}
+module_init(smaf_testsecure_init);
+
+static void __exit smaf_testsecure_deinit(void)
+{
+	smaf_unregister_secure(&test);
+}
+module_exit(smaf_testsecure_deinit);
+
+MODULE_DESCRIPTION("SMAF secure module for test purpose");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@linaro.org>");
-- 
1.9.1

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[Daniel Vetter]

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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[Benjamin Gaignard]

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@ffwll.ch>:
> 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@lists.freedesktop.org
>> 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

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[Daniel Vetter]

On Wed, Oct 05, 2016 at 03:40:14PM +0200, Benjamin Gaignard 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.

And how does that work? Atm there's no interfaces at all in the kernel to
allocate a buffer suitable for 2 devices at the same time. Seems
incomplete if this is the direction you want to go to. Also, it's against
the direction we all discussed ad XDC, where the clear consensus was to
have most of that haggling in userspace (with the kernel exporting a
little bit more information to userspace than what it does now).
-Daniel

> 
> Benjamin
> 
> 
> 2016-10-05 15:19 GMT+02:00 Daniel Vetter <daniel@ffwll.ch>:
> > 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@lists.freedesktop.org
> >> 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[Benjamin Gaignard]

When using dmabuf the devices have to attach themselves on the buffer
before map it
so you can know which devices will use the buffer before allocate it
when the first
dma_buf_map_attachment() is called (defered allocation)
Split dmabuf attach/map_attachment is not really done in drm or v4l2
but patch like this one
are going in this direction:
http://www.spinics.net/lists/linux-media/msg104480.html

I agree that device constraint enumeration is still missing, for smaf
I have just to test
by using device dma_coherent_mask field to check if cma allocator can
be used for
allocation. I guess that if you can export more device information to
userland we can
get access to them in kernel too.


2016-10-05 15:43 GMT+02:00 Daniel Vetter <daniel@ffwll.ch>:
> On Wed, Oct 05, 2016 at 03:40:14PM +0200, Benjamin Gaignard 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.
>
> And how does that work? Atm there's no interfaces at all in the kernel to
> allocate a buffer suitable for 2 devices at the same time. Seems
> incomplete if this is the direction you want to go to. Also, it's against
> the direction we all discussed ad XDC, where the clear consensus was to
> have most of that haggling in userspace (with the kernel exporting a
> little bit more information to userspace than what it does now).
> -Daniel
>
>>
>> Benjamin
>>
>>
>> 2016-10-05 15:19 GMT+02:00 Daniel Vetter <daniel@ffwll.ch>:
>> > 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@lists.freedesktop.org
>> >> 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@lists.freedesktop.org
>> 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

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[Rob Clark]

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@linaro.org> 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@ffwll.ch>:
>> 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@lists.freedesktop.org
>>> 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[Benjamin Gaignard]

Rob,

how do you know which devices are concerned when listing the constraints ?
Does combine_capabilities is done from each allocation or can it be cached ?

Regards,
Benjmain

2016-10-06 18:54 GMT+02:00 Rob Clark <robdclark@gmail.com>:
> 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@linaro.org> 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@ffwll.ch>:
>>> 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@lists.freedesktop.org
>>>> 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@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[Rob Clark]

probably should keep the discussion on github (USAGE.md was updated a
bit more and merged into https://github.com/cubanismo/allocator so
look there for the latest)..

but briefly:

1) my expectation is if the user is implementing some use-case, it
knows what devices and APIs are involved, otherwise it wouldn't be
able to pass a buffer to that device/API..

2) if assertion/usage/devices haven't changed, you can re-use the
merged caps for however many buffer allocations

BR,
-R

On Fri, Oct 7, 2016 at 9:54 AM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> wrote:
> Rob,
>
> how do you know which devices are concerned when listing the constraints ?
> Does combine_capabilities is done from each allocation or can it be cached ?
>
> Regards,
> Benjmain
>
> 2016-10-06 18:54 GMT+02:00 Rob Clark <robdclark@gmail.com>:
>> 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@linaro.org> 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@ffwll.ch>:
>>>> 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@lists.freedesktop.org
>>>>> 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@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Study Group
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

[John Einar Reitan]

On Fri, Oct 07, 2016 at 10:42:17AM -0400, Rob Clark wrote:
> probably should keep the discussion on github (USAGE.md was updated a
> bit more and merged into https://github.com/cubanismo/allocator so
> look there for the latest)..
> 
> but briefly:
> 
> 1) my expectation is if the user is implementing some use-case, it
> knows what devices and APIs are involved, otherwise it wouldn't be
> able to pass a buffer to that device/API..

As I described at Linaro Connect late-connected devices could cause new
constrains to appear. I.e. some (additonal) HDMI connection or WiFi Display etc.
Including all the might-happen devices might lead to unoptimal buffers
just to be able to handle some rarely-happen events.

I guess the easy resolve here is for the user to do a reallocation with
the new constraints added and replace the buffer(s) in question, but
with a slight lag in enabling the new device.

John