Re: [PATCH v5 1/3] create SMAF module

2015-10-21 Thread Benjamin Gaignard
2015-10-21 16:32 GMT+02:00 James Morris :
> On Wed, 21 Oct 2015, Benjamin Gaignard wrote:
>
>> 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.
>>
>
> This documentation is highly inadequate.

If you give hints I will try to complete it and make it acceptable.

>
> What does "allocate memory that can be securing" mean?

Maybe I could re-phrase it like that:
"Secure Memory Allocation Framework goal is to be able to allocate
memory that the platform can secure."

I'm trying to be generic here because each could have it own method to
secure buffers.

>
>
> --
> James Morris
> 
>



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 1/3] create SMAF module

2015-10-21 Thread James Morris
On Wed, 21 Oct 2015, Benjamin Gaignard wrote:

> 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.
> 

This documentation is highly inadequate.

What does "allocate memory that can be securing" mean?


-- 
James Morris


--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v5 1/3] create SMAF module

2015-10-21 Thread 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 
---
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/smaf/Kconfig   |   5 +
 drivers/smaf/Makefile  |   1 +
 drivers/smaf/smaf-core.c   | 753 +
 include/linux/smaf-allocator.h |  54 +++
 include/linux/smaf-secure.h|  75 
 include/uapi/linux/smaf.h  |  52 +++
 8 files changed, 943 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 46b4a8e..a488c20 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -188,4 +188,6 @@ source "drivers/nvdimm/Kconfig"
 
 source "drivers/nvmem/Kconfig"
 
+source "drivers/smaf/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index b250b36..693390b 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -167,3 +167,4 @@ obj-$(CONFIG_THUNDERBOLT)   += thunderbolt/
 obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
 obj-$(CONFIG_ANDROID)  += android/
 obj-$(CONFIG_NVMEM)+= nvmem/
+obj-$(CONFIG_SMAF) += smaf/
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
new file mode 100644
index 000..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 000..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 000..1d9a55e
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,753 @@
+/*
+ * smaf.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard  for Linaro.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+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 struct smaf_device smaf_dev;
+
+static bool have_secure_module(void)
+{
+   return !!smaf_dev.secure;
+}
+
+/**
+ * smaf_allow_cpu_access return true if CPU can access to memory
+ * if their is no secure module associated to SMAF assume that CPU can get
+ * access to the memory.
+ */
+static bool smaf_allow_cpu_access(struct smaf_handle *handle,
+ unsigned long flags)
+{
+   bool ret = true;
+
+   if (!atomic_read(&handle->is_secure))
+   return true;
+
+   mutex_lock(&smaf_dev.lock);
+
+   if (!have_secure_module())
+   goto unlock;
+
+   ret = smaf_dev.secure->allow_cpu_access(handle->secure_ctx, flags);
+
+unlock:
+   mutex_unlock(&smaf_dev.lock);
+   return ret;
+}
+
+/**
+ * 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)
+{