On Thu, Feb 11, 2016 at 06:14:33PM +0100, Jens Wiklander wrote: > Hi, > > This patch set introduces a generic TEE subsystem. 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 you also could do 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://github.com/OP-TEE/optee_os) 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. > > "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@xxxxxxxxxxxxxxxx (archive at > https://lists.linaro.org/pipermail/tee-dev/) with people from other > companies, including Valentin Manea <valentin.manea@xxxxxxxxxx>, > Emmanuel MICHEL <emmanuel.michel@xxxxxx>, > Jean-michel DELORME <jean-michel.delorme@xxxxxx>, > and Joakim Bech <joakim.bech@xxxxxxxxxx>. Our main concern has been to > agree on something that is generic enough to support many different > TEEs while still keeping the interface together. > > v8: > * Rebased on v4.5-rc3 > * dt/bindings: add bindings for optee > Acked-by: Rob Herring <robh@xxxxxxxxxx> > * Fixes build error for X86 > * Fixes spell error in "dt/bindings: add bindings for optee" Jens, thanks for the updated series and the continued work on this. I've recently starting testing/experimenting with this in the context of Kernel 4.4 (will try latest Kernel as a next step) and have not found any issues so far. This is an ongoing effort and I'll provide feedback as I encounter anything notable. But I also wanted to use this opportunity to express that from a TI and TI customer point of view (and probably beyond that) this TEE subsystem support is seen as an important building block for a number real-world use cases involving security. Acked-by: Andreas Dannenberg <dannenberg@xxxxxx> Regards, -- Andreas Dannenberg Texas Instruments Inc > > 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 > > 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 | 117 +++ > MAINTAINERS | 13 + > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/tee/Kconfig | 19 + > drivers/tee/Makefile | 4 + > drivers/tee/optee/Kconfig | 8 + > drivers/tee/optee/Makefile | 5 + > drivers/tee/optee/call.c | 400 ++++++++++ > drivers/tee/optee/core.c | 522 ++++++++++++ > drivers/tee/optee/optee_msg.h | 423 ++++++++++ > drivers/tee/optee/optee_private.h | 146 ++++ > drivers/tee/optee/optee_smc.h | 418 ++++++++++ > drivers/tee/optee/rpc.c | 322 ++++++++ > drivers/tee/optee/supp.c | 212 +++++ > drivers/tee/tee.c | 873 +++++++++++++++++++++ > drivers/tee/tee_private.h | 80 ++ > drivers/tee/tee_shm.c | 324 ++++++++ > drivers/tee/tee_shm_pool.c | 133 ++++ > include/linux/tee_drv.h | 299 +++++++ > include/uapi/linux/tee.h | 383 +++++++++ > 25 files changed, 4739 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.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 > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
