mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xiaoquan Li <xiaoquan.li@vivantecorp.com>
To: Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Rob Clark <robdclark@gmail.com>,
	Thierry Reding <treding@nvidia.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	Tom Cooksey <tom.cooksey@arm.com>,
	"Daniel Stone" <daniel.stone@collabora.com>
Cc: Linaro MM SIG Mailman List <linaro-mm-sig@lists.linaro.org>
Subject: RE: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework
Date: Tue, 28 Jul 2015 02:22:37 +0000	[thread overview]
Message-ID: <da0dde9a302342e5a13ce7ac3069419e@MBX05B-IAD3.mex08.mlsrvr.com> (raw)
In-Reply-To: <CA+M3ks7X++to23mXjRaB_wUJUo0TDLFh2hMbziEGeMDkVBx-7w@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5009 bytes --]

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-bounces@lists.linaro.org] On Behalf Of Benjamin Gaignard
Sent: Monday, July 27, 2015 6:12 PM
To: linux-media@vger.kernel.org; Linux Kernel Mailing List; dri-devel@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.gaignard@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-sig@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  reply	other threads:[~2015-07-28  2:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 12:28 Benjamin Gaignard
2015-07-10 12:28 ` [PATCH v3 1/2] create SMAF module Benjamin Gaignard
2015-07-10 12:28 ` [PATCH v3 2/2] SMAF: add CMA allocator Benjamin Gaignard
2015-07-27 10:12 ` [PATCH v3 0/2] RFC: Secure Memory Allocation Framework Benjamin Gaignard
2015-07-28  2:22   ` Xiaoquan Li [this message]
2015-07-28  7:56     ` [Linaro-mm-sig] " Benjamin Gaignard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da0dde9a302342e5a13ce7ac3069419e@MBX05B-IAD3.mex08.mlsrvr.com \
    --to=xiaoquan.li@vivantecorp.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=daniel.stone@collabora.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=robdclark@gmail.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tom.cooksey@arm.com \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®