Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1568876 > unrolled thread

[PATCH v15 0/5] generic TEE subsystem

Started byJens Wiklander <jens.wiklander@linaro.org>
First post2017-01-28 13:30 +0100
Last post2017-01-30 15:00 +0100
Articles 5 — 1 participant

Back to article view | Back to linux.kernel

Contents

  [PATCH v15 0/5] generic TEE subsystem Jens Wiklander <jens.wiklander@linaro.org> - 2017-01-28 13:30 +0100
    [PATCH v15 1/5] dt/bindings: add bindings for optee Jens Wiklander <jens.wiklander@linaro.org> - 2017-01-28 13:30 +0100
    [PATCH v15 4/5] Documentation: tee subsystem and op-tee driver Jens Wiklander <jens.wiklander@linaro.org> - 2017-01-28 13:30 +0100
    [PATCH v15 5/5] arm64: dt: hikey: Add optee node Jens Wiklander <jens.wiklander@linaro.org> - 2017-01-28 13:40 +0100
    Re: [PATCH v15 2/5] tee: generic TEE subsystem Jens Wiklander <jens.wiklander@linaro.org> - 2017-01-30 15:00 +0100

#1568876 — [PATCH v15 0/5] generic TEE subsystem

FromJens Wiklander <jens.wiklander@linaro.org>
Date2017-01-28 13:30 +0100
Subject[PATCH v15 0/5] generic TEE subsystem
Message-ID<t4AiJ-1nM-3@gated-at.bofh.it>
Hi,

This patch set introduces a generic TEE subsystem. These patches are used
on HiKey in AOSP. It's currently supported by roughly 20 platforms
(https://github.com/OP-TEE/optee_os#3-platforms-supported), to name a few,
Renesas RCAR H3, Sequitur Labs CoreTEE, Wind River VxWorks etc.

The TEE subsystem will contain drivers for various TEE implementations. A
TEE (Trusted Execution Environment) is a trusted OS running in some secure
environment, for example, TrustZone on ARM CPUs, or a separate secure
co-processor etc.

Regarding use cases, TrustZone has traditionally been used for
offloading secure tasks to the secure world. Examples include: 
- Secure key handling where the OS may or may not have direct access to key
  material.
- E-commerce and payment technologies. Credentials, credit card numbers etc
  could be stored in a more secure environment.
- Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
  etc.
- Secure boot to ensure that loaded binaries haven’t been tampered with.
  It’s not strictly needed for secure boot, but you could enhance security
  by leveraging a TEE during boot.
- Digital Rights Management (DRM), the studios provides content with
  different resolution depending on the security of the device. Higher
  security means higher resolution.

A TEE could also be used in existing and new technologies. For example IMA
(Integrity Measurement Architecture) which has been in the kernel for quite
a while. Today you can enhance security by using a TPM-chip to sign the IMA
measurement list. This is something that also has been done in practical
systems by leveraging a TEE.

Another example could be in 2-factor authentication which is becoming
increasingly more important. FIDO (https://fidoalliance.org) for example
are using public key cryptography in their 2-factor authentication standard
(U2F). With FIDO, a private and public key pair will be generated for every
site you visit and the private key should never leave the local device.
This is an example where you could use secure storage in a TEE for the
private key.

Today you will find a quite a few different out of tree implementations of
TEE drivers which tends to fragment the TEE ecosystem and development. We
think it would be a good idea to have a generic TEE driver integrated in
the kernel which would serve as a base for several different TEE solutions,
no matter if they are on-chip like TrustZone or if they are on a separate
crypto co-processor.

To develop this TEE subsystem we have been using the open source TEE called
OP-TEE (https://www.op-tee.org/) and therefore this would be the first TEE
solution supported by this new subsystem. OP-TEE is a GlobalPlatform
compliant TEE, however this TEE subsystem is not limited to only
GlobalPlatform TEEs, instead we have tried to design it so that it should
work with other TEE solutions also. Since the first version (2015 April) of
this patchset we’ve talked about it at Linaro Connect, GlobalPlatform
annual TEE conference and last time at Linux Plumbers, so we think there
has been both exposure and plenty of time to be able to get involved in
this work.

"tee: generic TEE subsystem" brings in the generic TEE subsystem which
helps when writing a driver for a specific TEE, for example, OP-TEE.

"tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
its work.

This patch set has been prepared in cooperation with Javier González who
proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
https://lwn.net/Articles/623380/ . We've since then changed the scope to
TEE instead of TrustZone.

We have discussed the design on tee-dev@lists.linaro.org (archive at
https://lists.linaro.org/pipermail/tee-dev/) with people from other
companies, including Valentin Manea <valentin.manea@huawei.com>,
Emmanuel MICHEL <emmanuel.michel@st.com>,
Jean-michel DELORME <jean-michel.delorme@st.com>,
and Joakim Bech <joakim.bech@linaro.org>. Our main concern has been to
agree on something that is generic enough to support many different
TEEs while still keeping the interface together.

v15:
* Rebased on v4.10-rc5
* Addressed review comments from Arnd Bergmann, with these hightligts:
  - Remove the platform device in OP-TEE driver
  - Comment on optee call queue wait functions to make it easier to see
    the purpose
  - Replace calls to ioremap_cache() with calls to memremap()
  - Remove OPTEE_MSG_OS_OPTEE_REVISION_*, that aren't used or kept up to date
  - Extend description of OPTEE_MSG_RPC_CMD_WAIT_QUEUE
  - Remove OPTEE_MSG_GET_PARAMS instead have a struct optee_msg_param params[]
    at the end of struct optee_msg_arg
  - get rid of union in struct tee_ioctl_param
  - add params[] to struct tee_ioctl_open_session_arg, struct
    tee_iocl_supp_recv_arg and struct tee_iocl_supp_send_arg
* "arm64: dt: hikey: Add optee node"
  Acked-by: Wei Xu <xuwei5@hisilicon.com>
* Tested-by: Scott Branden <scott.branden@broadcom.com>

v14:
* Rebased on v4.10-rc4
* Fixed checkpatch warning in OPTEE_SMC_RETURN_IS_RPC() macro

v13:
* Rebased on v4.9-rc5
* Added Hikey DT patch
* Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
* Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (RCAR H3)
* Tested-by: Andrew F. Davis <afd@ti.com> 

v12-resend:
* Rebased on v4.9-rc2

v12:
* Rebased on v4.8-rc5
* Addressed review comments from Andrew F. Davis
* Removed Acked-by: Andreas Dannenberg <dannenberg@ti.com> as the
  mail bounces
* Bugfix possible null dereference in error cleanup path of
  optee_probe().
* Bugfix optee_from_msg_param() when calculating offset of memref
  into a shared memory object

v11:
* Rebased on v4.8-rc3
* Addressed review comments from Nishanth Menon
* Made the TEE framework available as a loadable module.
* Reviewed-by: Javier González <javier@javigon.com>
* Zeroes shared memory on allocation to avoid information leakage
* Links shared memory objects to context to avoid stealing of shared memory
  object from an unrelated process
* Allow RPC interruption if supplicant is unavailable

v10:
* Rebased on v4.7-rc1
* Addressed private review comments from Nishanth Menon
* Optee driver only accepts one supplicant process on the privileged device
* Optee driver avoids long delayed releases of shm objects
* Added more comments on functions and structs

v9:
* Rebased on v4.6-rc1
* Acked-by: Andreas Dannenberg <dannenberg@ti.com>
* Addressed comments from Al Viro how file descriptors are passed to
  user space
* Addressed comments from Randy Dunlap on documentation
* Changed license for include/uapi/linux/tee.h

v8:
* Rebased on v4.5-rc3
* dt/bindings: add bindings for optee
  Acked-by: Rob Herring <robh@kernel.org>
* Fixes build error for X86
* Fixes spell error in "dt/bindings: add bindings for optee"

v7:
* Rebased on v4.5-rc2
* Moved the ARM SMC Calling Convention support into a separate patch
  set, which is now merged

v6:
* Rebased on v4.3-rc7
* Changed smccc interface to let the compiler marshal most of the
  parameters
* Added ARCH64 capability for smccc interface
* Changed the PSCI firmware calls (both arm and arm64) to use the new
  generic smccc interface instead instead of own assembly functions.
* Move optee DT bindings to below arm/firmware
* Defines method for OP-TEE driver to call secure world in DT, smc or hvc
* Exposes implementation id of a TEE driver in sysfs
  to easily spawn corresponding tee-supplicant when device is ready
* Update OP-TEE Message Protocol to better cope with fragmented physical
  memory
* Read time directly from OP-TEE driver instead of forwarding the RPC
  request to tee-supplicant

v5:
* Replaced kref reference counting for the device with a size_t instead as
  the counter is always protected by a mutex

v4:
* Rebased on 4.1
* Redesigned the synchronization around entry exit of normal SMC
* Replaced rwsem on the driver instance with kref and completion since
  rwsem wasn't intended to be used in this way
* Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
  future additional parameter types
* Documents TEE subsystem and OP-TEE driver
* Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
  TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
* DT bindings in a separate patch
* Assembly parts moved to arch/arm and arch/arm64 respectively, in a
  separate patch
* Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
* Removed CMA usage to limit the scope of the patch set

v3:
* Rebased on 4.1-rc3 (dma_buf_export() API change)
* A couple of small sparse fixes
* Documents bindings for OP-TEE driver
* Updated MAINTAINERS

v2:
* Replaced the stubbed OP-TEE driver with a real OP-TEE driver
* Removed most APIs not needed by OP-TEE in current state
* Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
* Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
* Moved tee.h into include/uapi/linux/
* Redefined tee.h IOCTL macros to be directly based on _IOR and friends
* Removed version info on the API to user space, a data blob which
  can contain an UUID is left for user space to be able to tell which
  protocol to use in TEE_IOC_CMD
* Changed user space exposed structures to only have types with __ prefix
* Dropped THIS_MODULE from tee_fops
* Reworked how the driver is registered and ref counted:
  - moved from using an embedded struct miscdevice to an embedded struct
    device.
  - uses an struct rw_semaphore as synchronization for driver detachment
  - uses alloc/register pattern from TPM

Thanks,
Jens



Jens Wiklander (4):
  dt/bindings: add bindings for optee
  tee: generic TEE subsystem
  tee: add OP-TEE driver
  Documentation: tee subsystem and op-tee driver

Jerome Forissier (1):
  arm64: dt: hikey: Add optee node

 Documentation/00-INDEX                             |   2 +
 .../bindings/arm/firmware/linaro,optee-tz.txt      |  31 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 Documentation/ioctl/ioctl-number.txt               |   1 +
 Documentation/tee.txt                              | 118 +++
 MAINTAINERS                                        |  13 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   7 +
 drivers/Kconfig                                    |   2 +
 drivers/Makefile                                   |   1 +
 drivers/tee/Kconfig                                |  18 +
 drivers/tee/Makefile                               |   5 +
 drivers/tee/optee/Kconfig                          |   7 +
 drivers/tee/optee/Makefile                         |   5 +
 drivers/tee/optee/call.c                           | 444 ++++++++++
 drivers/tee/optee/core.c                           | 603 ++++++++++++++
 drivers/tee/optee/optee_msg.h                      | 418 ++++++++++
 drivers/tee/optee/optee_private.h                  | 183 +++++
 drivers/tee/optee/optee_smc.h                      | 450 +++++++++++
 drivers/tee/optee/rpc.c                            | 396 +++++++++
 drivers/tee/optee/supp.c                           | 273 +++++++
 drivers/tee/tee_core.c                             | 891 +++++++++++++++++++++
 drivers/tee/tee_private.h                          | 129 +++
 drivers/tee/tee_shm.c                              | 357 +++++++++
 drivers/tee/tee_shm_pool.c                         | 156 ++++
 include/linux/tee_drv.h                            | 276 +++++++
 include/uapi/linux/tee.h                           | 346 ++++++++
 26 files changed, 5133 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
 create mode 100644 Documentation/tee.txt
 create mode 100644 drivers/tee/Kconfig
 create mode 100644 drivers/tee/Makefile
 create mode 100644 drivers/tee/optee/Kconfig
 create mode 100644 drivers/tee/optee/Makefile
 create mode 100644 drivers/tee/optee/call.c
 create mode 100644 drivers/tee/optee/core.c
 create mode 100644 drivers/tee/optee/optee_msg.h
 create mode 100644 drivers/tee/optee/optee_private.h
 create mode 100644 drivers/tee/optee/optee_smc.h
 create mode 100644 drivers/tee/optee/rpc.c
 create mode 100644 drivers/tee/optee/supp.c
 create mode 100644 drivers/tee/tee_core.c
 create mode 100644 drivers/tee/tee_private.h
 create mode 100644 drivers/tee/tee_shm.c
 create mode 100644 drivers/tee/tee_shm_pool.c
 create mode 100644 include/linux/tee_drv.h
 create mode 100644 include/uapi/linux/tee.h

-- 
2.7.4

[toc] | [next] | [standalone]

#1568878 — [PATCH v15 1/5] dt/bindings: add bindings for optee

FromJens Wiklander <jens.wiklander@linaro.org>
Date2017-01-28 13:30 +0100
Subject[PATCH v15 1/5] dt/bindings: add bindings for optee
Message-ID<t4AiK-1nM-11@gated-at.bofh.it>
In reply to#1568876
Introduces linaro prefix and adds bindings for ARM TrustZone based OP-TEE
implementation.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
 .../bindings/arm/firmware/linaro,optee-tz.txt      | 31 ++++++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt

diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
new file mode 100644
index 000000000000..d38834c67dff
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
@@ -0,0 +1,31 @@
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip.
+
+We're using "linaro" as the first part of the compatible property for
+the reference implementation maintained by Linaro.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible     : should contain "linaro,optee-tz"
+
+- method         : The method of calling the OP-TEE Trusted OS. Permitted
+                   values are:
+
+                   "smc" : SMC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+                   "hvc" : HVC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+
+
+Example:
+	firmware {
+		optee {
+			compatible = "linaro,optee-tz";
+			method = "smc";
+		};
+	};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e7f5d1..4b1192bb4224 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -161,6 +161,7 @@ lacie	LaCie
 lantiq	Lantiq Semiconductor
 lenovo	Lenovo Group Ltd.
 lg	LG Corporation
+linaro	Linaro Limited
 linux	Linux-specific binding
 lltc	Linear Technology Corporation
 lsi	LSI Corp. (LSI Logic)
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1568879 — [PATCH v15 4/5] Documentation: tee subsystem and op-tee driver

FromJens Wiklander <jens.wiklander@linaro.org>
Date2017-01-28 13:30 +0100
Subject[PATCH v15 4/5] Documentation: tee subsystem and op-tee driver
Message-ID<t4AiJ-1nM-5@gated-at.bofh.it>
In reply to#1568876
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
 Documentation/00-INDEX |   2 +
 Documentation/tee.txt  | 118 +++++++++++++++++++++++++++++++++++++++++++++++++
 MAINTAINERS            |   1 +
 3 files changed, 121 insertions(+)
 create mode 100644 Documentation/tee.txt

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index c8a8eb1a2b11..fc6a3cb83d97 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -412,6 +412,8 @@ sysctl/
 	- directory with info on the /proc/sys/* files.
 target/
 	- directory with info on generating TCM v4 fabric .ko modules
+tee.txt
+	- info on the TEE subsystem and drivers
 this_cpu_ops.txt
 	- List rationale behind and the way to use this_cpu operations.
 thermal/
diff --git a/Documentation/tee.txt b/Documentation/tee.txt
new file mode 100644
index 000000000000..718599357596
--- /dev/null
+++ b/Documentation/tee.txt
@@ -0,0 +1,118 @@
+TEE subsystem
+This document describes the TEE subsystem in Linux.
+
+A TEE (Trusted Execution Environment) is a trusted OS running in some
+secure environment, for example, TrustZone on ARM CPUs, or a separate
+secure co-processor etc. A TEE driver handles the details needed to
+communicate with the TEE.
+
+This subsystem deals with:
+
+- Registration of TEE drivers
+
+- Managing shared memory between Linux and the TEE
+
+- Providing a generic API to the TEE
+
+The TEE interface
+=================
+
+include/uapi/linux/tee.h defines the generic interface to a TEE.
+
+User space (the client) connects to the driver by opening /dev/tee[0-9]* or
+/dev/teepriv[0-9]*.
+
+- TEE_IOC_SHM_ALLOC allocates shared memory and returns a file descriptor
+  which user space can mmap. When user space doesn't need the file
+  descriptor any more, it should be closed. When shared memory isn't needed
+  any longer it should be unmapped with munmap() to allow the reuse of
+  memory.
+
+- TEE_IOC_VERSION lets user space know which TEE this driver handles and
+  the its capabilities.
+
+- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application.
+
+- TEE_IOC_INVOKE invokes a function in a Trusted Application.
+
+- TEE_IOC_CANCEL may cancel an ongoing TEE_IOC_OPEN_SESSION or TEE_IOC_INVOKE.
+
+- TEE_IOC_CLOSE_SESSION closes a session to a Trusted Application.
+
+There are two classes of clients, normal clients and supplicants. The latter is
+a helper process for the TEE to access resources in Linux, for example file
+system access. A normal client opens /dev/tee[0-9]* and a supplicant opens
+/dev/teepriv[0-9].
+
+Much of the communication between clients and the TEE is opaque to the
+driver. The main job for the driver is to receive requests from the
+clients, forward them to the TEE and send back the results. In the case of
+supplicants the communication goes in the other direction, the TEE sends
+requests to the supplicant which then sends back the result.
+
+OP-TEE driver
+=============
+
+The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
+TrustZone based OP-TEE solution that is supported.
+
+Lowest level of communication with OP-TEE builds on ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
+[3] used internally by the driver. Stacked on top of that is OP-TEE Message
+Protocol [4].
+
+OP-TEE SMC interface provides the basic functions required by SMCCC and some
+additional functions specific for OP-TEE. The most interesting functions are:
+
+- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
+  which is then returned by TEE_IOC_VERSION
+
+- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
+  to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
+  separate secure co-processor.
+
+- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
+
+- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
+  range to used for shared memory between Linux and OP-TEE.
+
+The GlobalPlatform TEE Client API [5] is implemented on top of the generic
+TEE API.
+
+Picture of the relationship between the different components in the
+OP-TEE architecture.
+
+    User space                  Kernel                   Secure world
+    ~~~~~~~~~~                  ~~~~~~                   ~~~~~~~~~~~~
+ +--------+                                             +-------------+
+ | Client |                                             | Trusted     |
+ +--------+                                             | Application |
+    /\                                                  +-------------+
+    || +----------+                                           /\
+    || |tee-      |                                           ||
+    || |supplicant|                                           \/
+    || +----------+                                     +-------------+
+    \/      /\                                          | TEE Internal|
+ +-------+  ||                                          | API         |
+ + TEE   |  ||            +--------+--------+           +-------------+
+ | Client|  ||            | TEE    | OP-TEE |           | OP-TEE      |
+ | API   |  \/            | subsys | driver |           | Trusted OS  |
+ +-------+----------------+----+-------+----+-----------+-------------+
+ |      Generic TEE API        |       |     OP-TEE MSG               |
+ |      IOCTL (TEE_IOC_*)      |       |     SMCCC (OPTEE_SMC_CALL_*) |
+ +-----------------------------+       +------------------------------+
+
+RPC (Remote Procedure Call) are requests from secure world to kernel driver
+or tee-supplicant. An RPC is identified by a special range of SMCCC return
+values from OPTEE_SMC_CALL_WITH_ARG. RPC messages which are intended for the
+kernel are handled by the kernel driver. Other RPC messages will be forwarded to
+tee-supplicant without further involvement of the driver, except switching
+shared memory buffer representation.
+
+References:
+[1] https://github.com/OP-TEE/optee_os
+[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+[3] drivers/tee/optee/optee_smc.h
+[4] drivers/tee/optee/optee_msg.h
+[5] http://www.globalplatform.org/specificationsdevice.asp look for
+    "TEE Client API Specification v1.0" and click download.
diff --git a/MAINTAINERS b/MAINTAINERS
index bc9c2086f19b..a55d5228b10f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10902,6 +10902,7 @@ S:	Maintained
 F:	include/linux/tee_drv.h
 F:	include/uapi/linux/tee.h
 F:	drivers/tee/
+F:	Documentation/tee.txt
 
 THUNDERBOLT DRIVER
 M:	Andreas Noever <andreas.noever@gmail.com>
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1568881 — [PATCH v15 5/5] arm64: dt: hikey: Add optee node

FromJens Wiklander <jens.wiklander@linaro.org>
Date2017-01-28 13:40 +0100
Subject[PATCH v15 5/5] arm64: dt: hikey: Add optee node
Message-ID<t4Asq-1sP-15@gated-at.bofh.it>
In reply to#1568876
From: Jerome Forissier <jerome.forissier@linaro.org>

Acked-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c131c62c..89c15399bec2 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -406,6 +406,13 @@
 			};
 		};
 	};
+
+	firmware {
+		optee {
+			compatible = "linaro,optee-tz";
+			method = "smc";
+		};
+	};
 };
 
 &uart2 {
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1569753 — Re: [PATCH v15 2/5] tee: generic TEE subsystem

FromJens Wiklander <jens.wiklander@linaro.org>
Date2017-01-30 15:00 +0100
SubjectRe: [PATCH v15 2/5] tee: generic TEE subsystem
Message-ID<t5kEW-4Ed-35@gated-at.bofh.it>
In reply to#1568876
On Mon, Jan 30, 2017 at 09:02:49AM +0000, Benjamin GAIGNARD wrote:
> 
> 
> On 01/28/2017 01:19 PM, Jens Wiklander wrote:
[...]
> > +/**
> > + * tee_shm_alloc() - Allocate shared memory
> > + * @ctx:	Context that allocates the shared memory
> > + * @size:	Requested size of shared memory
> > + * @flags:	Flags setting properties for the requested shared memory.
> > + *
> > + * Memory allocated as global shared memory is automatically freed when the
> > + * TEE file pointer is closed. The @flags field uses the bits defined by
> > + * TEE_SHM_* in <linux/tee_drv.h>. TEE_SHM_MAPPED must currently always be
> > + * set. If TEE_SHM_DMA_BUF global shared memory will be allocated and
> > + * associated with a dma-buf handle, else driver private memory.
> > + */
> > +struct tee_shm *tee_shm_alloc(struct tee_context *ctx, size_t size, u32 flags)
> > +{
> > +	struct tee_device *teedev = ctx->teedev;
> > +	struct tee_shm_pool_mgr *poolm = NULL;
> > +	struct tee_shm *shm;
> > +	void *ret;
> > +	int rc;
> > +
> > +	if (!(flags & TEE_SHM_MAPPED)) {
> > +		dev_err(teedev->dev.parent,
> > +			"only mapped allocations supported\n");
> > +		return ERR_PTR(-EINVAL);
> > +	}
> > +
> > +	if ((flags & ~(TEE_SHM_MAPPED | TEE_SHM_DMA_BUF))) {
> > +		dev_err(teedev->dev.parent, "invalid shm flags 0x%x", flags);
> > +		return ERR_PTR(-EINVAL);
> > +	}
> > +
> > +	if (!tee_device_get(teedev))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	if (!teedev->pool) {
> > +		/* teedev has been detached from driver */
> > +		ret = ERR_PTR(-EINVAL);
> > +		goto err_dev_put;
> > +	}
> > +
> > +	shm = kzalloc(sizeof(*shm), GFP_KERNEL);
> > +	if (!shm) {
> > +		ret = ERR_PTR(-ENOMEM);
> > +		goto err_dev_put;
> > +	}
> > +
> > +	shm->flags = flags;
> > +	shm->teedev = teedev;
> > +	shm->ctx = ctx;
> > +	if (flags & TEE_SHM_DMA_BUF)
> > +		poolm = &teedev->pool->dma_buf_mgr;
> > +	else
> > +		poolm = &teedev->pool->private_mgr;
> > +
> > +	rc = poolm->ops->alloc(poolm, shm, size);
> > +	if (rc) {
> > +		ret = ERR_PTR(rc);
> > +		goto err_kfree;
> > +	}
> > +
> > +	mutex_lock(&teedev->mutex);
> > +	shm->id = idr_alloc(&teedev->idr, shm, 1, 0, GFP_KERNEL);
> > +	mutex_unlock(&teedev->mutex);
> > +	if (shm->id < 0) {
> > +		ret = ERR_PTR(shm->id);
> > +		goto err_pool_free;
> > +	}
> > +
> > +	if (flags & TEE_SHM_DMA_BUF) {
> > +		DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> > +
> > +		exp_info.ops = &tee_shm_dma_buf_ops;
> > +		exp_info.size = shm->size;
> > +		exp_info.flags = O_RDWR;
> > +		exp_info.priv = shm;
> > +
> > +		shm->dmabuf = dma_buf_export(&exp_info);
> > +		if (IS_ERR(shm->dmabuf)) {
> > +			ret = ERR_CAST(shm->dmabuf);
> > +			goto err_rem;
> > +		}
> > +	}
> why not always use dmabuf ? with dma_buf_fd() you have a file descriptor
> which is also an integer.
> Like this you may can remove shm->id and TEE_SHM_DMA_BUF

In the early patch sets (v8 and earlier) it was a bit like you propose
(except that we only used dmabuf on the same object as today). Then I
got https://lkml.org/lkml/2016/2/11/861 where Al Viro says (among other
things) "struct containing descriptor *is* a bad ABI design". Al also
mentioned the problem with cleaning up allocated file descriptors on
errors. I choose the safe path to only allocate and return a file
descriptor when no error cleanup is needed because the descriptor is in
the return value.

Another reason is that there are shared memory objects which never are
supposed to be mapped in user space. They are only a thing between the
kernel and secure world, when carrying the struct optee_msg_arg for
instance.

> > +	mutex_lock(&teedev->mutex);
> > +	list_add_tail(&shm->link, &ctx->list_shm);
> > +	mutex_unlock(&teedev->mutex);
> > +
> > +	return shm;
> > +err_rem:
> > +	mutex_lock(&teedev->mutex);
> > +	idr_remove(&teedev->idr, shm->id);
> > +	mutex_unlock(&teedev->mutex);
> > +err_pool_free:
> > +	poolm->ops->free(poolm, shm);
> > +err_kfree:
> > +	kfree(shm);
> > +err_dev_put:
> > +	tee_device_put(teedev);
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(tee_shm_alloc);
[...]

> > +/**
> > + * tee_shm_get_from_id() - Find shared memory object and increase referece count
> referece -> reference

I'll fix.

> > + * @ctx:	Context owning the shared memory
> > + * @id:		Id of shared memory object
> > + * @returns a pointer to 'struct tee_shm' on success or an ERR_PTR on failure
> > + */
> > +struct tee_shm *tee_shm_get_from_id(struct tee_context *ctx, int id)
> > +{
> > +	struct tee_device *teedev;
> > +	struct tee_shm *shm;
> > +
> > +	if (!ctx)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	teedev = ctx->teedev;
> > +	mutex_lock(&teedev->mutex);
> > +	shm = idr_find(&teedev->idr, id);
> > +	if (!shm || shm->ctx != ctx)
> > +		shm = ERR_PTR(-EINVAL);
> > +	else if (shm->flags & TEE_SHM_DMA_BUF)
> > +		get_dma_buf(shm->dmabuf);
> > +	mutex_unlock(&teedev->mutex);
> > +	return shm;
> > +}
> > +EXPORT_SYMBOL_GPL(tee_shm_get_from_id);

[...]

> > +/**
> > + * tee_shm_get_from_id() - Find shared memory object and increase referece count
> referece -> reference

I'll fix.

> > + * @ctx:	Context owning the shared memory
> > + * @id:		Id of shared memory object
> > + * @returns a pointer to 'struct tee_shm' on success or an ERR_PTR on failure
> > + */
> > +struct tee_shm *tee_shm_get_from_id(struct tee_context *ctx, int id);
> > +
> > +#endif /*__TEE_DRV_H*/

Thanks,
Jens

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web