Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework
There is an API to do the same operation on kernel side than on userland.
You can get an dmabuf handle, select the allocator if required, and
secure it on kernel side.
Your question makes me realize that I have forget to add an
EXPORT_SYMBOL for smaf_create_handle function, I will fix that.
Benjamin
2015-07-28 4:22 GMT+02:00 Xiaoquan Li :
> Hi Benjamin,
>
> It looks like this framework only allows user space client to talk with trust
> application, it there a plan to provide kernel side APIs for kernel space
> client?
>
> Please correct me if my understanding is wrong.
>
> Thanks
>
> Xiaoquan
>
> -Original Message-
> From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf
> Of Benjamin Gaignard
> Sent: Monday, July 27, 2015 6:12 PM
> To: linux-me...@vger.kernel.org; Linux Kernel Mailing List;
> dri-de...@lists.freedesktop.org; Hans Verkuil; Laurent Pinchart; Daniel
> Vetter; Rob Clark; Thierry Reding; Sumit Semwal; Tom Cooksey; Daniel Stone
> Cc: Linaro MM SIG Mailman List
> Subject: Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation
> Framework
>
> Hi all,
>
> This thread doesn't get any feedback...
>
> What would be great is to know if this framework proposal fir with
> your platform needs.
>
> Maybe I haven't copy the good mailing lists so if you think there is
> better ones do not hesitate to forward.
>
> Regards,
> Benjamin
>
>
> 2015-07-10 14:28 GMT+02:00 Benjamin Gaignard :
>> version 3 changes:
>> - Remove ioctl for allocator selection instead provide the name of
>>the targeted allocator with allocation request.
>>Selecting allocator from userland isn't the prefered way of working
>>but is needed when the first user of the buffer is a software component.
>> - Fix issues in case of error while creating smaf handle.
>> - Fix module license.
>> - Update libsmaf and tests to care of the SMAF API evolution
>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>
>> version 2 changes:
>> - Add one ioctl to allow allocator selection from userspace.
>>This is required for the uses case where the first user of
>>the buffer is a software IP which can't perform dma_buf attachement.
>> - Add name and ranking to allocator structure to be able to sort them.
>> - Create a tiny library to test SMAF:
>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>> - Fix one issue when try to secure buffer without secure module registered
>>
>> The outcome of the previous RFC about how do secure data path was the need
>> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>>
>> SMAF goal is to provide a framework that allow allocating and securing
>> memory by using dma_buf. Each platform have it own way to perform those two
>> features so SMAF design allow to register helper modules to perform them.
>>
>> To be sure to select the best allocation method for devices SMAF implement
>> deferred allocation mechanism: memory allocation is only done when the first
>> device effectively required it.
>> Allocator modules have to implement a match() to let SMAF know if they are
>> compatibles with devices needs.
>> This patch set provide an example of allocator module which use
>> dma_{alloc/free/mmap}_attrs() and check if at least one device have
>> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
>> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
>> a better name could be found for this file.
>>
>> Secure modules are responsibles of granting and revoking devices access
>> rights
>> on the memory. Secure module is also called to check if CPU map memory into
>> kernel and user address spaces.
>> An example of secure module implementation can be found here:
>> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
>> This code isn't yet part of the patch set because it depends on generic TEE
>> which is still under discussion (https://lwn.net/Articles/644646/)
>>
>> For allocation part of SMAF code I get inspirated by Sumit Semwal work about
>> constraint aware allocator.
>>
>> Benjamin Gaignard (2):
>> create SMAF module
>> SMAF: add CMA allocator
>>
>> drivers/Kconfig| 2 +
>> drivers/Makefile | 1 +
>> drivers/smaf/Kconfig | 11 +
>> drivers/smaf/Makefile | 2 +
>> drivers/smaf/smaf-cma.c| 200 +++
>> drivers/smaf/smaf-core.c | 735
>> +
>> include/linux/smaf-allocator.
Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework
There is an API to do the same operation on kernel side than on userland.
You can get an dmabuf handle, select the allocator if required, and
secure it on kernel side.
Your question makes me realize that I have forget to add an
EXPORT_SYMBOL for smaf_create_handle function, I will fix that.
Benjamin
2015-07-28 4:22 GMT+02:00 Xiaoquan Li xiaoquan...@vivantecorp.com:
Hi Benjamin,
It looks like this framework only allows user space client to talk with trust
application, it there a plan to provide kernel side APIs for kernel space
client?
Please correct me if my understanding is wrong.
Thanks
Xiaoquan
-Original Message-
From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf
Of Benjamin Gaignard
Sent: Monday, July 27, 2015 6:12 PM
To: linux-me...@vger.kernel.org; Linux Kernel Mailing List;
dri-de...@lists.freedesktop.org; Hans Verkuil; Laurent Pinchart; Daniel
Vetter; Rob Clark; Thierry Reding; Sumit Semwal; Tom Cooksey; Daniel Stone
Cc: Linaro MM SIG Mailman List
Subject: Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation
Framework
Hi all,
This thread doesn't get any feedback...
What would be great is to know if this framework proposal fir with
your platform needs.
Maybe I haven't copy the good mailing lists so if you think there is
better ones do not hesitate to forward.
Regards,
Benjamin
2015-07-10 14:28 GMT+02:00 Benjamin Gaignard benjamin.gaign...@linaro.org:
version 3 changes:
- Remove ioctl for allocator selection instead provide the name of
the targeted allocator with allocation request.
Selecting allocator from userland isn't the prefered way of working
but is needed when the first user of the buffer is a software component.
- Fix issues in case of error while creating smaf handle.
- Fix module license.
- Update libsmaf and tests to care of the SMAF API evolution
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a tiny library to test SMAF:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- Fix one issue when try to secure buffer without secure module registered
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access
rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c| 200 +++
drivers/smaf/smaf-core.c | 735
+
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 52 +++
9 files changed, 1119 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
--
1.9.1
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro
RE: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework
Hi Benjamin,
It looks like this framework only allows user space client to talk with trust
application, it there a plan to provide kernel side APIs for kernel space
client?
Please correct me if my understanding is wrong.
Thanks
Xiaoquan
-Original Message-
From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf
Of Benjamin Gaignard
Sent: Monday, July 27, 2015 6:12 PM
To: linux-me...@vger.kernel.org; Linux Kernel Mailing List;
dri-de...@lists.freedesktop.org; Hans Verkuil; Laurent Pinchart; Daniel Vetter;
Rob Clark; Thierry Reding; Sumit Semwal; Tom Cooksey; Daniel Stone
Cc: Linaro MM SIG Mailman List
Subject: Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation
Framework
Hi all,
This thread doesn't get any feedback...
What would be great is to know if this framework proposal fir with
your platform needs.
Maybe I haven't copy the good mailing lists so if you think there is
better ones do not hesitate to forward.
Regards,
Benjamin
2015-07-10 14:28 GMT+02:00 Benjamin Gaignard :
> version 3 changes:
> - Remove ioctl for allocator selection instead provide the name of
>the targeted allocator with allocation request.
>Selecting allocator from userland isn't the prefered way of working
>but is needed when the first user of the buffer is a software component.
> - Fix issues in case of error while creating smaf handle.
> - Fix module license.
> - Update libsmaf and tests to care of the SMAF API evolution
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>
> version 2 changes:
> - Add one ioctl to allow allocator selection from userspace.
>This is required for the uses case where the first user of
>the buffer is a software IP which can't perform dma_buf attachement.
> - Add name and ranking to allocator structure to be able to sort them.
> - Create a tiny library to test SMAF:
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
> - Fix one issue when try to secure buffer without secure module registered
>
> The outcome of the previous RFC about how do secure data path was the need
> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>
> SMAF goal is to provide a framework that allow allocating and securing
> memory by using dma_buf. Each platform have it own way to perform those two
> features so SMAF design allow to register helper modules to perform them.
>
> To be sure to select the best allocation method for devices SMAF implement
> deferred allocation mechanism: memory allocation is only done when the first
> device effectively required it.
> Allocator modules have to implement a match() to let SMAF know if they are
> compatibles with devices needs.
> This patch set provide an example of allocator module which use
> dma_{alloc/free/mmap}_attrs() and check if at least one device have
> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
> a better name could be found for this file.
>
> Secure modules are responsibles of granting and revoking devices access rights
> on the memory. Secure module is also called to check if CPU map memory into
> kernel and user address spaces.
> An example of secure module implementation can be found here:
> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
> This code isn't yet part of the patch set because it depends on generic TEE
> which is still under discussion (https://lwn.net/Articles/644646/)
>
> For allocation part of SMAF code I get inspirated by Sumit Semwal work about
> constraint aware allocator.
>
> Benjamin Gaignard (2):
> create SMAF module
> SMAF: add CMA allocator
>
> drivers/Kconfig| 2 +
> drivers/Makefile | 1 +
> drivers/smaf/Kconfig | 11 +
> drivers/smaf/Makefile | 2 +
> drivers/smaf/smaf-cma.c| 200 +++
> drivers/smaf/smaf-core.c | 735
> +
> include/linux/smaf-allocator.h | 54 +++
> include/linux/smaf-secure.h| 62
> include/uapi/linux/smaf.h | 52 +++
> 9 files changed, 1119 insertions(+)
> create mode 100644 drivers/smaf/Kconfig
> create mode 100644 drivers/smaf/Makefile
> create mode 100644 drivers/smaf/smaf-cma.c
> create mode 100644 drivers/smaf/smaf-core.c
> create mode 100644 include/linux/smaf-allocator.h
> create mode 100644 include/linux/smaf-secure.h
> create mode 100644 include/uapi/linux/smaf.h
>
> --
> 1.9.1
>
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
RE: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework
Hi Benjamin,
It looks like this framework only allows user space client to talk with trust
application, it there a plan to provide kernel side APIs for kernel space
client?
Please correct me if my understanding is wrong.
Thanks
Xiaoquan
-Original Message-
From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf
Of Benjamin Gaignard
Sent: Monday, July 27, 2015 6:12 PM
To: linux-me...@vger.kernel.org; Linux Kernel Mailing List;
dri-de...@lists.freedesktop.org; Hans Verkuil; Laurent Pinchart; Daniel Vetter;
Rob Clark; Thierry Reding; Sumit Semwal; Tom Cooksey; Daniel Stone
Cc: Linaro MM SIG Mailman List
Subject: Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation
Framework
Hi all,
This thread doesn't get any feedback...
What would be great is to know if this framework proposal fir with
your platform needs.
Maybe I haven't copy the good mailing lists so if you think there is
better ones do not hesitate to forward.
Regards,
Benjamin
2015-07-10 14:28 GMT+02:00 Benjamin Gaignard benjamin.gaign...@linaro.org:
version 3 changes:
- Remove ioctl for allocator selection instead provide the name of
the targeted allocator with allocation request.
Selecting allocator from userland isn't the prefered way of working
but is needed when the first user of the buffer is a software component.
- Fix issues in case of error while creating smaf handle.
- Fix module license.
- Update libsmaf and tests to care of the SMAF API evolution
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a tiny library to test SMAF:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- Fix one issue when try to secure buffer without secure module registered
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c| 200 +++
drivers/smaf/smaf-core.c | 735
+
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 52 +++
9 files changed, 1119 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
--
1.9.1
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
