Hi,
On Mon, Nov 23, 2020 at 8:10 AM gaoyusong wrote:
>
> The memmap options in tee_shm_op_mmap were not being checked for all
> sets of possible crazy values. Fix this up by properly check tee_shm
> buffer offsets.
>
> Signed-off-by: gaoyusong
> ---
> drivers/tee/tee_shm.c | 10 ++
> 1
;optee_shm_unregister()->check_mem_type() uses provided
> user pointers for vma lookups (via __check_mem_type()), which can only by
> done with untagged pointers.
>
> Untag user pointers in this function.
>
> Signed-off-by: Andrey Konovalov
Acked-by: Jens Wiklander
> ---
>
, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Jens Wiklander
> Signed-off-by: John Hubbard
> ---
> drivers/tee/tee_shm.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
Acked-by: Jens Wiklan
Hi Olivier,
On Fri, Aug 12, 2022 at 4:31 PM Olivier Masse wrote:
>
> Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a
> shared memory from a dmabuf file descriptor.
> This new ioctl will allow the Linux Kernel to register a buffer
> to be used by the Secure Data Path OPTEE OS feature.
On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
>
> Signed-off-by: Daniel Vetter
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Jens Wiklander
> Cc: tee-...@lists.linaro.org
> --
> Ack for merging
st%2Fsdp_ba
> >>> sic.c%23L153&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C9ff962fb58f640
> >>> 1c597808db05e2a64b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63811
> >>> 0243232457377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>
> >> >>> Kernel version 5.11 and higher. the userland allocation could be find
> >> >>> here:
> >> >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >> >>> git%2F&data=05%7C01%7Ccyrille.fleury%40nxp.
gt;
> There is some helpful background in [2]: basically, this is a small
> part of fixing a long-standing disconnect between pinning pages, and
> file systems' use of those pages.
>
> [1] Documentation/core-api/pin_user_pages.rst
>
> [2] "Explicit pinning of user-
On Tue, Aug 25, 2020 at 10:54 AM John Hubbard wrote:
>
> On 8/25/20 1:32 AM, Jens Wiklander wrote:
> > On Mon, Aug 24, 2020 at 02:11:25PM -0700, John Hubbard wrote:
> ...
> >> OK, one more try, this time actually handling the _USER_MAPPED vs.
> >> _KERNEL_MAPPED p
gt; [2] "Explicit pinning of user-space pages":
> https://lwn.net/Articles/807108/
>
> Cc: Jens Wiklander
> Cc: Sumit Semwal
> Cc: tee-...@lists.linaro.org
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.lina
On Wed, May 15, 2024 at 1:25 PM Yong Wu wrote:
>
> Add a MediaTek restricted heap which uses TEE service call to restrict
> buffer. Currently this restricted heap is NULL, Prepare for the later
> patch. Mainly there are two changes:
> a) Add a heap_init ops since TEE probe late than restricted hea
uot;secure" with "restricted" where applicable
Etienne Carriere (1):
tee: new ioctl to a register tee_shm from a dmabuf file descriptor
Jens Wiklander (2):
dma-buf: heaps: restricted_heap: add no_map attribute
dma-buf: heaps: add Linaro restricted dmabuf heap support
Olivier
identify tee_shm objects built from a registered
dmabuf, TEE_SHM_DMA_BUF.
Signed-off-by: Etienne Carriere
Signed-off-by: Olivier Masse
Signed-off-by: Jens Wiklander
---
drivers/tee/tee_core.c | 38 ++
drivers/tee/tee_shm.c| 104 +--
include/linux
Add a no_map attribute to struct restricted_heap_attachment and struct
restricted_heap to skip the call to dma_map_sgtable() if set. This
avoids trying to map a dma-buf that doens't refer to memory accessible
by the kernel.
Signed-off-by: Jens Wiklander
---
drivers/dma-buf/
From: Olivier Masse
DMABUF reserved memory definition for OP-TEE secure data path feature.
Signed-off-by: Olivier Masse
Signed-off-by: Jens Wiklander
---
.../linaro,restricted-heap.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
with the TEE subsystem for later use
via Trusted Applications in the secure world.
Co-developed-by: Olivier Masse
Signed-off-by: Olivier Masse
Signed-off-by: Jens Wiklander
---
drivers/dma-buf/heaps/Kconfig | 10 ++
drivers/dma-buf/heaps/Makefile| 1 +
.../dma
On Fri, Aug 30, 2024 at 10:20 AM Krzysztof Kozlowski wrote:
>
> On Fri, Aug 30, 2024 at 09:03:50AM +0200, Jens Wiklander wrote:
> > From: Olivier Masse
> >
> > DMABUF reserved memory definition for OP-TEE secure data path feature.
> >
> > Signed-off-by: Ol
On Tue, Sep 3, 2024 at 7:50 PM T.J. Mercier wrote:
>
> On Fri, Aug 30, 2024 at 12:04 AM Jens Wiklander
> wrote:
> >
> > Add a Linaro restricted heap using the linaro,restricted-heap bindings
> > implemented based on the generic restricted heap.
> >
> > T
On Tue, Sep 3, 2024 at 7:50 PM T.J. Mercier wrote:
>
> On Fri, Aug 30, 2024 at 12:04 AM Jens Wiklander
> wrote:
> >
> > From: Etienne Carriere
> >
> > Enable userspace to create a tee_shm object that refers to a dmabuf
> > reference.
> >
> > U
On Fri, Aug 30, 2024 at 10:47 AM Christian König
wrote:
>
> Am 30.08.24 um 09:03 schrieb Jens Wiklander:
> > Add a no_map attribute to struct restricted_heap_attachment and struct
> > restricted_heap to skip the call to dma_map_sgtable() if set. This
> > avoids tryi
Hi,
On Wed, Jul 10, 2024 at 1:17 AM Amirreza Zarrabi
wrote:
>
>
>
> On 7/3/2024 9:36 PM, Dmitry Baryshkov wrote:
> > On Tue, Jul 02, 2024 at 10:57:35PM GMT, Amirreza Zarrabi wrote:
> >> Qualcomm TEE hosts Trusted Applications (TAs) and services that run in
> >> the secure world. Access to these r
On Wed, Sep 4, 2024 at 11:42 PM T.J. Mercier wrote:
>
> On Wed, Sep 4, 2024 at 2:44 AM Jens Wiklander
> wrote:
> >
> > On Tue, Sep 3, 2024 at 7:50 PM T.J. Mercier wrote:
> > >
> > > On Fri, Aug 30, 2024 at 12:04 AM Jens Wiklander
> > > wrote:
&g
On Tue, Sep 10, 2024 at 5:08 PM T.J. Mercier wrote:
>
> On Mon, Sep 9, 2024 at 11:06 PM Jens Wiklander
> wrote:
> >
> > On Wed, Sep 4, 2024 at 11:42 PM T.J. Mercier wrote:
> > >
> > > On Wed, Sep 4, 2024 at 2:44 AM Jens Wiklander
> > > wrote:
&g
ng Wu's post [1] where much of dma-buf handling is done in
the generic restricted heap
* Simplifications and cleanup
* New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap
support"
* Replaced the word "secure" with "restricted" where app
Data Path or Trusted UI where certain hardware
devices can access the memory.
Signed-off-by: Jens Wiklander
---
drivers/tee/Makefile | 1 +
drivers/tee/tee_core.c | 33 +-
drivers/tee/tee_private.h | 2 +
drivers/tee/tee_rstmem.c | 200
.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/core.c | 21 +++
drivers/tee/optee/optee_private.h | 6 +
drivers/tee/optee/optee_smc.h | 35
drivers/tee/optee/smc_abi.c | 45 ---
4 files changed, 104
On Thu, Oct 17, 2024 at 12:46 PM Sumit Garg wrote:
>
> Hi Jens,
>
> On Tue, 15 Oct 2024 at 15:47, Jens Wiklander
> wrote:
> >
> > Hi,
> >
> > This patch set allocates the restricted DMA-bufs via the TEE subsystem.
> > This a complete rewrite comp
Hi Sumit,
On Thu, Oct 17, 2024 at 1:00 PM Sumit Garg wrote:
>
> Hi Jens,
>
> On Tue, 15 Oct 2024 at 15:47, Jens Wiklander
> wrote:
> >
> > Add support in the OP-TEE backend driver for restricted memory
> > allocation. The support is limited to only the SMC ABI
On Mon, Sep 23, 2024 at 09:33:29AM +0300, Dmitry Baryshkov wrote:
> Hi,
>
> On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote:
> > Hi,
> >
> > This patch set is based on top of Yong Wu's restricted heap patch set [1].
> > It's also a contin
Hi,
On Tue, Sep 24, 2024 at 01:13:18PM -0500, Andrew Davis wrote:
> On 9/23/24 1:33 AM, Dmitry Baryshkov wrote:
> > Hi,
> >
> > On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote:
> > > Hi,
> > >
> > > This patch set is based
> >> On Tue, Sep 24, 2024 at 01:13:18PM GMT, Andrew Davis wrote:
> >>
> >> On 9/23/24 1:33 AM, Dmitry Baryshkov wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote:
> >>
>
On Wed, Sep 25, 2024 at 1:41 PM Dmitry Baryshkov
wrote:
>
> On Wed, Sep 25, 2024 at 09:15:04AM GMT, Jens Wiklander wrote:
> > On Mon, Sep 23, 2024 at 09:33:29AM +0300, Dmitry Baryshkov wrote:
> > > Hi,
> > >
> > > On Fri, Aug 30, 2024 at 09:03:47A
x27;t support the requested use-case
of restricted memory.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/Makefile| 1 +
drivers/tee/optee/core.c | 1 +
drivers/tee/optee/ffa_abi.c | 135 ++-
drivers/tee/optee/optee_private.h | 33 ++-
drivers/tee/optee/rst
and cleanup
* New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap
support"
* Replaced the word "secure" with "restricted" where applicable
Jens Wiklander (4):
tee: add restricted memory allocation
optee: account for direction while conve
Update the header files describing the secure world ABI, both with and
without FF-A. The ABI is extended to deal with restricted memory, but as
usual backward compatible.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/optee_ffa.h | 27 ++---
drivers/tee/optee/optee_msg.h | 65
st be copied.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/call.c | 10 ++--
drivers/tee/optee/ffa_abi.c | 43 +
drivers/tee/optee/optee_private.h | 42 +++--
drivers/tee/optee/rpc.c | 31 +
drivers/tee/optee/smc_abi.c
Playback, Trusted UI, or Secure Video Recording where certain
hardware devices can access the memory.
More use-cases can be added in userspace ABI, but it's up to the backend
drivers to provide the implementation.
Signed-off-by: Jens Wiklander
---
drivers/tee/Makefile | 1 +
driver
Hi Sumit,
On Tue, Dec 3, 2024 at 9:27 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Thu, 28 Nov 2024 at 20:39, Jens Wiklander
> wrote:
> >
> > The OP-TEE backend driver has two internal function pointers to convert
> > between the subsystem type struct tee
On Tue, Dec 3, 2024 at 11:35 AM Sumit Garg wrote:
>
> On Tue, 3 Dec 2024 at 15:58, Jens Wiklander wrote:
> >
> > Hi Sumit,
> >
> > On Tue, Dec 3, 2024 at 9:27 AM Sumit Garg wrote:
> > >
> > > Hi Jens,
> > >
> > > On Thu, 28 Nov 2
Hi Sumit,
On Tue, Dec 3, 2024 at 9:19 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Thu, 28 Nov 2024 at 20:39, Jens Wiklander
> wrote:
> >
> > Add support in the OP-TEE backend driver for restricted memory
> > allocation.
> >
> > The restricted memory
Video Playback, Trusted UI, or Secure Video Recording where certain
hardware devices can access the memory.
More use-cases can be added in userspace ABI, but it's up to the backend
drivers to provide the implementation.
Signed-off-by: Jens Wiklander
---
drivers/tee/Makefile
st be copied.
This is needed in a later patch where it might get confusing when
converting back in from_msg_param() callback since an allocated
restricted SHM can be using the sec_world_id of the used restricted
memory pool and that doesn't translate back well.
Signed-off-by: Jens Wiklander
--
Update the header files describing the secure world ABI, both with and
without FF-A. The ABI is extended to deal with restricted memory, but as
usual backward compatible.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/optee_ffa.h | 27 ++---
drivers/tee/optee/optee_msg.h | 65
.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/Makefile| 1 +
drivers/tee/optee/core.c | 1 +
drivers/tee/optee/optee_private.h | 23 ++
drivers/tee/optee/rstmem.c| 76 +++
drivers/tee/optee/smc_abi.c | 69
Add support in the OP-TEE backend driver for dynamic restricted memory
allocation using the SMC ABI.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/smc_abi.c | 74 +++--
1 file changed, 71 insertions(+), 3 deletions(-)
diff --git a/drivers/tee/optee
icted
memory.
Restricted memory pools based on a static carveout or dynamic allocation
can coexist for different use-cases. We use only dynamic allocation with
FF-A.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/ffa_abi.c | 135 -
drivers/tee/optee/optee_private.h
neric restricted heap
* Simplifications and cleanup
* New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap
support"
* Replaced the word "secure" with "restricted" where applicable
Jens Wiklander (6):
tee: add restricted memory allocation
optee: a
Hi Sumit,
On Tue, Dec 3, 2024 at 8:58 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Thu, 28 Nov 2024 at 20:39, Jens Wiklander
> wrote:
> >
> > Add restricted memory allocation to the TEE subsystem. Restricted memory
> > is not be accessible by kernel during normal
On Wed, Jan 8, 2025 at 5:54 PM Simona Vetter wrote:
>
> On Tue, Dec 17, 2024 at 11:07:37AM +0100, Jens Wiklander wrote:
> > Add restricted memory allocation to the TEE subsystem.
> >
> > Restricted memory refers to memory buffers behind a hardware enforced
> > fir
Hi,
On Thu, Feb 13, 2025 at 7:42 AM Sumit Garg wrote:
>
> Hi Boris,
>
> On Thu, 13 Feb 2025 at 01:26, Boris Brezillon
> wrote:
> >
> > +Florent, who's working on protected-mode support in Panthor.
> >
> > Hi Jens,
> >
> > On T
Hi,
On Tue, Mar 18, 2025 at 7:38 PM Nicolas Dufresne wrote:
>
> Le mardi 04 mars 2025 à 13:15 +0530, Sumit Garg a écrit :
> > On Tue, Mar 04, 2025 at 08:17:23AM +0100, Jens Wiklander wrote:
> > > Hi Daniel,
> > >
> > > On Fri, Feb 21, 2025 at 3:12 PM Daniel
On Tue, Mar 25, 2025 at 6:56 AM Sumit Garg wrote:
>
> On Thu, Mar 20, 2025 at 02:00:57PM +0100, Jens Wiklander wrote:
> > Hi Sumit,
> >
> > On Thu, Mar 20, 2025 at 10:25 AM Sumit Garg wrote:
> > >
> > > Hi Jens,
> > >
> > > On
Hi Sumit,
On Thu, Mar 13, 2025 at 11:41 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Wed, Mar 05, 2025 at 02:04:09PM +0100, Jens Wiklander wrote:
> > The OP-TEE backend driver has two internal function pointers to convert
> > between the subsystem type struct tee_param an
Hi Sumit,
On Thu, Mar 20, 2025 at 10:25 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Mon, Mar 17, 2025 at 08:42:01AM +0100, Jens Wiklander wrote:
> > Hi Sumit,
> >
> > On Thu, Mar 13, 2025 at 11:41 AM Sumit Garg wrote:
> > >
> > > Hi Jens,
> >
Hi Sumit,
On Tue, Mar 25, 2025 at 7:33 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Wed, Mar 05, 2025 at 02:04:11PM +0100, Jens Wiklander wrote:
> > Implement DMA heap for restricted DMA-buf allocation in the TEE
> > subsystem.
> >
> > Restricted memory refers
Hi Sumit,
On Tue, Mar 25, 2025 at 7:50 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Wed, Mar 05, 2025 at 02:04:12PM +0100, Jens Wiklander wrote:
> > From: Etienne Carriere
> >
> > Enable userspace to create a tee_shm object that refers to a dmabuf
> > refere
Hi Sumit,
On Tue, Mar 25, 2025 at 8:42 AM Sumit Garg wrote:
>
> On Wed, Mar 05, 2025 at 02:04:15PM +0100, Jens Wiklander wrote:
> > Add support in the OP-TEE backend driver dynamic restricted memory
> > allocation with FF-A.
> >
> > The restricted memory pools for
Hi,
On Wed, Mar 5, 2025 at 2:06 PM Jens Wiklander wrote:
>
> Hi,
>
> This patch set allocates the restricted DMA-bufs from a DMA-heap
> instantiated from the TEE subsystem.
>
> The TEE subsystem handles the DMA-buf allocations since it is the TEE
> (OP-TEE, AMD-TEE, TS-
Hi Sumit,
On Tue, Mar 25, 2025 at 7:20 AM Sumit Garg wrote:
>
> Hi Jens,
>
> It has taken a bit of time for me to review this patch-set as I am
> settling in my new role.
>
> On Wed, Mar 05, 2025 at 02:04:10PM +0100, Jens Wiklander wrote:
> > Update the header files
On Tue, Apr 8, 2025 at 11:14 AM Sumit Garg wrote:
>
> On Tue, Apr 01, 2025 at 10:33:04AM +0200, Jens Wiklander wrote:
> > On Tue, Apr 1, 2025 at 9:58 AM Sumit Garg wrote:
> > >
> > > On Tue, Mar 25, 2025 at 11:55:46AM +0100, Jens Wik
Hi Amirreza,
On Fri, Mar 28, 2025 at 3:48 AM Amirreza Zarrabi
wrote:
>
> For drivers that can transfer data to the TEE without using shared
> memory from client, it is necessary to receive the user address
> directly, bypassing any processing by the TEE subsystem. Introduce
> TEE_IOCTL_PARAM_ATTR
On Wed, Apr 9, 2025 at 2:50 PM Sumit Garg wrote:
>
> On Tue, Apr 08, 2025 at 03:28:45PM +0200, Jens Wiklander wrote:
> > On Tue, Apr 8, 2025 at 11:14 AM Sumit Garg wrote:
> > >
> > > On Tue, Apr 01, 2025 at 10:33:04AM +0200, Jens Wiklander wrote:
> > > >
On Tue, Apr 1, 2025 at 9:58 AM Sumit Garg wrote:
>
> On Tue, Mar 25, 2025 at 11:55:46AM +0100, Jens Wiklander wrote:
> > Hi Sumit,
> >
>
>
>
> >
> > >
> > > > +
> > > > +#include "tee_private.h"
> > > >
On Tue, Apr 1, 2025 at 9:45 AM Sumit Garg wrote:
>
> On Tue, Mar 25, 2025 at 09:50:35AM +0100, Jens Wiklander wrote:
> > On Tue, Mar 25, 2025 at 6:56 AM Sumit Garg wrote:
> > >
> > > On Thu, Mar 20, 2025 at 02:00:57PM +0100, Jens Wiklander wrote:
> > > >
On Tue, Apr 1, 2025 at 12:13 PM Sumit Garg wrote:
>
> + MM folks to seek guidance here.
>
> On Thu, Mar 27, 2025 at 09:07:34AM +0100, Jens Wiklander wrote:
> > Hi Sumit,
> >
> > On Tue, Mar 25, 2025 at 8:42 AM Sumit Garg wrote:
> > >
> > > On Wed,
Hi Amirreza,
On Wed, Apr 9, 2025 at 2:28 AM Amirreza Zarrabi
wrote:
>
> Hi jens,
>
> On 4/8/2025 10:19 PM, Jens Wiklander wrote:
>
> Hi Amirreza,
>
> On Fri, Mar 28, 2025 at 3:48 AM Amirreza Zarrabi
> wrote:
>
> For drivers that can transfer data to the TEE w
On Tue, Apr 8, 2025 at 11:20 AM Sumit Garg wrote:
>
> On Tue, Apr 01, 2025 at 02:26:59PM +0200, Jens Wiklander wrote:
> > On Tue, Apr 1, 2025 at 12:13 PM Sumit Garg wrote:
> > >
> > > + MM folks to seek guidance here.
> > >
> > > On Thu, Mar 27
Hi Amirreza,
On Fri, Mar 28, 2025 at 3:48 AM Amirreza Zarrabi
wrote:
>
> Introduce qcomtee_object, which represents an object in both QTEE and
> the kernel. QTEE clients can invoke an instance of qcomtee_object to
> access QTEE services. If this invocation produces a new object in QTEE,
> an inst
On Wed, Apr 9, 2025 at 9:20 AM Amirreza Zarrabi
wrote:
>
>
>
> On 4/9/2025 4:41 PM, Jens Wiklander wrote:
> > Hi Amirreza,
> >
> > On Wed, Apr 9, 2025 at 2:28 AM Amirreza Zarrabi
> > wrote:
> >>
> >> Hi jens,
> >>
> &g
Hi Amir,
On Fri, Mar 28, 2025 at 3:48 AM Amirreza Zarrabi
wrote:
>
> The tee_context can be used to manage TEE user resources, including
> those allocated by the driver for the TEE on behalf of the user.
> The release() callback is invoked only when all resources, such as
> tee_shm, are released
Hi,
On Fri, May 2, 2025 at 3:59 PM Robin Murphy wrote:
>
> On 02/05/2025 10:59 am, Jens Wiklander wrote:
> > Implement DMA heap for protected DMA-buf allocation in the TEE
> > subsystem.
> >
> > Restricted memory refers to memory buffers behind a hardware en
Hi,
On Fri, May 2, 2025 at 3:11 PM Robin Murphy wrote:
>
> On 02/05/2025 10:59 am, Jens Wiklander wrote:
> > Export the global variable dma_contiguous_default_area so
> > dev_get_cma_area() can be called a module.
>
> What dma_map_ops implementation is in a module? Withou
Hi,
On Fri, May 2, 2025 at 5:50 PM Matthew Wilcox wrote:
>
> On Fri, May 02, 2025 at 11:59:23AM +0200, Jens Wiklander wrote:
> > Export the two functions cma_alloc() and cma_release().
>
> Why? This is clearly part of a larger series, but you've given those of
> us w
Hi,
On Fri, May 2, 2025 at 3:36 PM Robin Murphy wrote:
>
> On 02/05/2025 10:59 am, Jens Wiklander wrote:
> > If a parent device is supplied to tee_device_alloc(), copy the dma_mask
> > field into the new device. This avoids future warnings when mapping a
> > DMA-buf for t
Hi Rouven,
On Fri, Apr 25, 2025 at 3:36 PM Rouven Czerwinski
wrote:
>
> Hi,
>
> On Fri, 4 Apr 2025 at 16:31, Jens Wiklander wrote:
> >
> > Update the header files describing the secure world ABI, both with and
> > without FF-A. The ABI is extended to deal with prot
Add tee_shm_alloc_cma_phys_mem() to allocate a physical memory using
from the default CMA pool. The memory is represented by a tee_shm object
using the new flag TEE_SHM_CMA_BUF to identify it as physical memory
from CMA.
Signed-off-by: Jens Wiklander
---
drivers/tee/tee_shm.c| 55
-off-by: Jens Wiklander
---
drivers/tee/optee/core.c| 1 +
drivers/tee/optee/smc_abi.c | 44 +++--
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index c75fddc83576..c7fd8040480e 100644
--- a
ected
memory.
Restricted memory pools based on a static carveout or dynamic allocation
can coexist for different use-cases. We use only dynamic allocation with
FF-A.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/Makefile| 1 +
drivers/tee/optee/ffa_abi.c
Break out the memref handling into a separate helper function.
No change in behavior.
Signed-off-by: Jens Wiklander
---
drivers/tee/tee_core.c | 94 --
1 file changed, 54 insertions(+), 40 deletions(-)
diff --git a/drivers/tee/tee_core.c b/drivers/tee
identify tee_shm objects built from a
registered dmabuf, TEE_SHM_DMA_BUF.
Signed-off-by: Etienne Carriere
Signed-off-by: Olivier Masse
Signed-off-by: Jens Wiklander
---
drivers/tee/tee_core.c| 63 +-
drivers/tee/tee_private.h | 10
drivers/tee/tee_shm.c | 111
Export the two functions cma_alloc() and cma_release().
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Jens Wiklander
---
mm/cma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 15632939f20a..c60901e73a26 100644
--- a
Export the global variable dma_contiguous_default_area so
dev_get_cma_area() can be called a module.
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: io...@lists.linux.dev
Signed-off-by: Jens Wiklander
---
kernel/dma/contiguous.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/dma
Add support in the OP-TEE backend driver for dynamic protected memory
allocation using the SMC ABI.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/smc_abi.c | 103 +---
1 file changed, 85 insertions(+), 18 deletions(-)
diff --git a/drivers/tee/optee
Update the header files describing the secure world ABI, both with and
without FF-A. The ABI is extended to deal with protected memory, but as
usual backward compatible.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/optee_ffa.h | 27 +---
drivers/tee/optee/optee_msg.h | 83
st be copied.
This is needed in a later patch where it might get confusing when
converting back in from_msg_param() callback since an allocated
restricted SHM can be using the sec_world_id of the used restricted
memory pool and that doesn't translate back well.
Signed-off-by: Jens Wiklander
--
Export the dma-buf heap functions declared in .
Signed-off-by: Jens Wiklander
---
drivers/dma-buf/dma-heap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 3cbe87d4a464..cdddf0e24dce 100644
--- a/drivers/dma-buf/dma-heap.c
where certain
hardware devices can access the memory.
The DMA-heaps are enabled explicitly by the TEE backend driver. The TEE
backend drivers needs to implement protected memory pool to manage the
protected memory.
Signed-off-by: Jens Wiklander
---
drivers/tee/Makefile | 1 +
drivers/tee
If a parent device is supplied to tee_device_alloc(), copy the dma_mask
field into the new device. This avoids future warnings when mapping a
DMA-buf for the device.
Signed-off-by: Jens Wiklander
Reviewed-by: Sumit Garg
---
drivers/tee/tee_core.c | 2 ++
1 file changed, 2 insertions(+)
diff
FFA_LEND
Changes since the V1 RFC:
* Based on v6.11
* Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC
Changes since Olivier's post [2]:
* Based on Yong Wu's post [1] where much of dma-buf handling is done in
the generic restricted heap
* Simplifications and clea
During probing of the OP-TEE driver, pass the parent device to
tee_device_alloc() so the dma_mask of the new devices can be updated
accordingly.
Signed-off-by: Jens Wiklander
Reviewed-by: Sumit Garg
---
drivers/tee/optee/ffa_abi.c | 8
drivers/tee/optee/smc_abi.c | 4 ++--
2 files
Video Playback, Trusted UI, or Secure Video Recording where certain
hardware devices can access the memory.
More use-cases can be added in userspace ABI, but it's up to the backend
drivers to provide the implementation.
Signed-off-by: Jens Wiklander
---
drivers/tee/Makefile
st be copied.
This is needed in a later patch where it might get confusing when
converting back in from_msg_param() callback since an allocated
restricted SHM can be using the sec_world_id of the used restricted
memory pool and that doesn't translate back well.
Signed-off-by: Jens Wiklander
--
.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/Makefile| 1 +
drivers/tee/optee/core.c | 1 +
drivers/tee/optee/optee_private.h | 23 ++
drivers/tee/optee/rstmem.c| 76 +++
drivers/tee/optee/smc_abi.c | 69
Update the header files describing the secure world ABI, both with and
without FF-A. The ABI is extended to deal with restricted memory, but as
usual backward compatible.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/optee_ffa.h | 27 ++---
drivers/tee/optee/optee_msg.h | 65
icted
memory.
Restricted memory pools based on a static carveout or dynamic allocation
can coexist for different use-cases. We use only dynamic allocation with
FF-A.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/ffa_abi.c | 136 -
drivers/tee/optee/optee_private.h
the generic restricted heap
* Simplifications and cleanup
* New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap
support"
* Replaced the word "secure" with "restricted" where applicable
Jens Wiklander (7):
tee: add restricted memory allocat
Add support in the OP-TEE backend driver for dynamic restricted memory
allocation using the SMC ABI.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/smc_abi.c | 76 +++--
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/drivers/tee/optee
Add TEE_IOC_RSTMEM_FD_INFO to retrieve information about a previously
allocated restricted memory dma-buf file descriptor. This is needed if
the file descriptor from a restricted memory allocation has been saved
due to limitations in the application.
Signed-off-by: Jens Wiklander
---
drivers
Hi Daniel,
On Fri, Feb 21, 2025 at 3:12 PM Daniel Stone wrote:
>
> Hi Sumit,
>
> On Fri, 21 Feb 2025 at 11:24, Sumit Garg wrote:
> > On Tue, 18 Feb 2025 at 21:52, Daniel Stone wrote:
> > > dma-heaps was created to solve the problem of having too many
> > > 'allocate $n bytes from $specialplace'
]:
* Based on Yong Wu's post [1] where much of dma-buf handling is done in
the generic restricted heap
* Simplifications and cleanup
* New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap
support"
* Replaced the word "secure" with "restricte
1 - 100 of 163 matches
Mail list logo
