Tee-dev August 2019

tee-dev@lists.linaro.org

10 participants
10 discussions

[PATCH] optee: allow to work without static shared memory

by Volodymyr Babchuk

From: Volodymyr Babchuk <vlad.babchuk(a)gmail.com> On virtualized systems it is possible that OP-TEE will provide only dynamic shared memory support. So it is fine to boot without static SHM enabled if dymanic one is supported. Signed-off-by: Volodymyr Babchuk <vlad.babchuk(a)gmail.com> --- drivers/tee/optee/core.c | 83 ++++++++++++++++++++++++++++-------------------- 1 file changed, 49 insertions(+), 34 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 4a2c420..d80da29 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -420,9 +420,35 @@ static bool optee_msg_exchange_capabilities(optee_invoke_fn *invoke_fn, return true; } +static struct tee_shm_pool *optee_config_dyn_shm(void) +{ + struct tee_shm_pool_mgr *priv_mgr; + struct tee_shm_pool_mgr *dmabuf_mgr; + void *rc; + + rc = optee_shm_pool_alloc_pages(); + if (IS_ERR(rc)) + return rc; + priv_mgr = rc; + + rc = optee_shm_pool_alloc_pages(); + if (IS_ERR(rc)) { + tee_shm_pool_mgr_destroy(priv_mgr); + return rc; + } + dmabuf_mgr = rc; + + rc = tee_shm_pool_alloc(priv_mgr, dmabuf_mgr); + if (IS_ERR(rc)) { + tee_shm_pool_mgr_destroy(priv_mgr); + tee_shm_pool_mgr_destroy(dmabuf_mgr); + } + + return rc; +} + static struct tee_shm_pool * -optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm, - u32 sec_caps) +optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm) { union { struct arm_smccc_res smccc; @@ -437,10 +463,11 @@ optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm, struct tee_shm_pool_mgr *priv_mgr; struct tee_shm_pool_mgr *dmabuf_mgr; void *rc; + const int sz = OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE; invoke_fn(OPTEE_SMC_GET_SHM_CONFIG, 0, 0, 0, 0, 0, 0, 0, &res.smccc); if (res.result.status != OPTEE_SMC_RETURN_OK) { - pr_info("shm service not available\n"); + pr_err("static shm service not available\n"); return ERR_PTR(-ENOENT); } @@ -466,28 +493,15 @@ optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm, } vaddr = (unsigned long)va; - /* - * If OP-TEE can work with unregistered SHM, we will use own pool - * for private shm - */ - if (sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) { - rc = optee_shm_pool_alloc_pages(); - if (IS_ERR(rc)) - goto err_memunmap; - priv_mgr = rc; - } else { - const size_t sz = OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE; - - rc = tee_shm_pool_mgr_alloc_res_mem(vaddr, paddr, sz, - 3 /* 8 bytes aligned */); - if (IS_ERR(rc)) - goto err_memunmap; - priv_mgr = rc; - - vaddr += sz; - paddr += sz; - size -= sz; - } + rc = tee_shm_pool_mgr_alloc_res_mem(vaddr, paddr, sz, + 3 /* 8 bytes aligned */); + if (IS_ERR(rc)) + goto err_memunmap; + priv_mgr = rc; + + vaddr += sz; + paddr += sz; + size -= sz; rc = tee_shm_pool_mgr_alloc_res_mem(vaddr, paddr, size, PAGE_SHIFT); if (IS_ERR(rc)) @@ -553,7 +567,7 @@ static optee_invoke_fn *get_invoke_func(struct device_node *np) static struct optee *optee_probe(struct device_node *np) { optee_invoke_fn *invoke_fn; - struct tee_shm_pool *pool; + struct tee_shm_pool *pool = ERR_PTR(-EINVAL); struct optee *optee = NULL; void *memremaped_shm = NULL; struct tee_device *teedev; @@ -582,13 +596,17 @@ static struct optee *optee_probe(struct device_node *np) } /* - * We have no other option for shared memory, if secure world - * doesn't have any reserved memory we can use we can't continue. + * Try to use dynamic shared memory if possible */ - if (!(sec_caps & OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM)) - return ERR_PTR(-EINVAL); + if (sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) + pool = optee_config_dyn_shm(); + + /* + * If dynamic shared memory is not available or failed - try static one + */ + if (IS_ERR(pool) && (sec_caps & OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM)) + pool = optee_config_shm_memremap(invoke_fn, &memremaped_shm); - pool = optee_config_shm_memremap(invoke_fn, &memremaped_shm, sec_caps); if (IS_ERR(pool)) return (void *)pool; @@ -632,9 +650,6 @@ static struct optee *optee_probe(struct device_node *np) optee_enable_shm_cache(optee); - if (optee->sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) - pr_info("dynamic shared memory is enabled\n"); - pr_info("initialized driver\n"); return optee; err: -- 2.7.4

5 years

[PATCH v7 0/5] TEE mediator (and OP-TEE) support in XEN

by Volodymyr Babchuk

Hello community, Please find new version of OP-TEE patch series. This is the kind of follow-up for the previous version, as most of the patches of the previous version were commited. This series includes leftovers of the prev. version and three new patches. One of the new patches adds a way to detect if OP-TEE were build with virtualization support and two others bear cosmetic changes to Kconfig files. This patches also can be pulled from [4] == Changes in v7: - 8 of 10 patches were commited - New patch "xen/arm: tee: place OP-TEE Kconfig option right after TEE" places options in menuconfig in more natural way - New patch "xen/arm: optee: check if OP-TEE is virtualization-aware" ensues that OP-TEE is virtualization-aware - New patch "xen/arm: optee: document OPTEE option in tee/Kconfig" add short description of OP-TEE mediator - Documentation in "tools/arm: tee: add "tee" option for xl.cfg" was updated === Changes in v6: - Series rebased to staging branch instead of master one. - OP-TEE protocol headers was taken from OP-TEE tree instead of Linux one - Added acked-by tags - Fixed (and tested) issue when XEN would not boot if it is build with CONFIG_TEE=n ==== Changes in v5: - Substantial rework of OP-TEE mediator. Now it tries to return meaningful error codes back to the guest. - OP-TEE mediator does not use struct cpu_user_regs as a storage for parameters and return values when calling OP-TEE. This makes it compatbile with requirement from SMCCC. - tee=native option replaced with tee=optee - Authorship and s-o-b tag reset to my EPAM mail address ==== Changes in v4: - Patch "arm: add tee_enabled flag to xen_arch_domainconfig" was squashed into "xen/arm: add generic TEE mediator framework" - I implemented more elaborate error repoting to a guest. Now guest will get meaningful error codes instead of generic ARM_SMCCC_ERR_UNKNOWN_FUNCTION. ==== Changes in v3: - Use domain flags insted of domctl interface to enable optee for guests - Remove patch "libxc: add xc_dom_tee_enable(...) function" because of previous change - Mediator now stores own context in arch part of struct domain, so I removed patch "optee: add domain contexts" ==== Changes in v2: This is v2 of patch series for OP-TEE mediator support in XEN. Changes from v1: - Added domctl interface, so now xl decides what domain should work with TEE - Removed XSM support due to change described above - Patch with OP-TEE mediator was splited to 7 separate patches - Removed patch with call_smccc() function. Now this series depend on Julien Grall's series "xen/arm: SMCCC fixup and improvement" [3] ===== v1: This is follow for patch series [1]. There was lots of discussions for that series and I tried to address all of them in this new patchset. Currently, I had a working solution for OP-TEE virtualization and it is being upstreamed right now ([2]). So, I think it is a good time to introduce support in XEN as well. This series include generic TEE mediator framework and full-scale OP-TEE mediator which is working with mentioned chages in OP-TEE. So, multiple domains can work simultaneously with OP-TEE. I added XSM support, so now it is possible to control which domains can work with TEEs. Also I changed way how TEE discovery is done. Now it is very generic and should support any platform. [1] https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg01451.html [2] https://github.com/OP-TEE/optee_os/pull/2370 [3] https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02138.html [4] https://github.com/lorc/xen/tree/optee_v7 Volodymyr Babchuk (5): tools/arm: tee: add "tee" option for xl.cfg tools/arm: optee: create optee firmware node in DT if tee=optee xen/arm: tee: place OP-TEE Kconfig option right after TEE xen/arm: optee: check if OP-TEE is virtualization-aware xen/arm: optee: document OPTEE option in tee/Kconfig docs/man/xl.cfg.5.pod.in | 29 +++++++++++++++++++++++++ tools/libxl/libxl.h | 5 +++++ tools/libxl/libxl_arm.c | 42 +++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_types.idl | 6 ++++++ tools/xl/xl_parse.c | 9 ++++++++ xen/arch/arm/Kconfig | 4 ++-- xen/arch/arm/tee/Kconfig | 5 +++++ xen/arch/arm/tee/optee.c | 10 +++++++++ 8 files changed, 108 insertions(+), 2 deletions(-) -- 2.21.0

5 years, 2 months

[PATCH 0/5] arch/arm: optee: fix TODOs and remove "experimental" status

by Volodymyr Babchuk

Hello, This patch series fixes various unfinished items in the OP-TEE mediator. Mostly this is about limiting resources that guest can consume. This includes both memory and time - how many buffers guest can share with OP-TEE (this uses Xen memory) and when mediator should preempt itself, to make sure that guest does not stress scheduling. Apart from this, there were one case, when mediator's actions might lead to memory leak in a good-behaving guest. To fix this issue I had to extend mediator logic, so now it can issue RPC requests to guest in the same way, as OP-TEE does this. This is useful feature, because it allows to preempt mediator during long operations. So, in the future it will be possible to remove shared buffer size limitation, because mediator can preempt self during buffer translation. This patch series can be pulled from [1]. [1] https://github.com/lorc/xen/tree/optee3_v1 Volodymyr Babchuk (5): xen/arm: optee: impose limit on shared buffer size xen/arm: optee: check for preemption while freeing shared buffers xen/arm: optee: limit number of shared buffers xen/arm: optee: handle share buffer translation error xen/arm: optee: remove experimental status xen/arch/arm/Kconfig | 2 +- xen/arch/arm/tee/Kconfig | 2 +- xen/arch/arm/tee/optee.c | 237 ++++++++++++++++++++++++++++++--------- 3 files changed, 184 insertions(+), 57 deletions(-) -- 2.22.0

5 years, 2 months

[RFC/RFT v4 0/5] Add generic trusted keys framework/subsystem

by Sumit Garg

This patch-set is an outcome of discussion here [1]. It has evolved very much since v1 to create, consolidate and generalize trusted keys subsystem. This framework has been tested with trusted keys support provided via TEE but I wasn't able to test it with a TPM device as I don't possess one. It would be really helpful if others could test this patch-set using a TPM device. [1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg30591.html Changes in v4: 1. Separate patch for export of tpm_buf code to include/linux/tpm.h 2. Change TPM1.x trusted keys code to use common tpm_buf 3. Keep module name as trusted.ko only Changes in v3: Move TPM2 trusted keys code to trusted keys subsystem. Changes in v2: Split trusted keys abstraction patch for ease of review. Sumit Garg (5): tpm: move tpm_buf code to include/linux/ KEYS: trusted: use common tpm_buf for TPM1.x code KEYS: trusted: create trusted keys subsystem KEYS: trusted: move tpm2 trusted keys code KEYS: trusted: Add generic trusted keys framework crypto/asymmetric_keys/asym_tpm.c | 2 +- drivers/char/tpm/tpm-chip.c | 1 + drivers/char/tpm/tpm-interface.c | 56 --- drivers/char/tpm/tpm.h | 230 ----------- drivers/char/tpm/tpm2-cmd.c | 308 +-------------- include/keys/trusted-type.h | 45 +++ include/keys/{trusted.h => trusted_tpm.h} | 61 +-- include/linux/tpm.h | 270 ++++++++++++- security/keys/Makefile | 2 +- security/keys/trusted-keys/Makefile | 9 + security/keys/trusted-keys/trusted-common.c | 343 ++++++++++++++++ .../keys/{trusted.c => trusted-keys/trusted-tpm.c} | 437 +++++---------------- security/keys/trusted-keys/trusted-tpm2.c | 378 ++++++++++++++++++ 13 files changed, 1141 insertions(+), 1001 deletions(-) rename include/keys/{trusted.h => trusted_tpm.h} (64%) create mode 100644 security/keys/trusted-keys/Makefile create mode 100644 security/keys/trusted-keys/trusted-common.c rename security/keys/{trusted.c => trusted-keys/trusted-tpm.c} (72%) create mode 100644 security/keys/trusted-keys/trusted-tpm2.c -- 2.7.4

5 years, 2 months

[PATCH v5 0/4] Create and consolidate trusted keys subsystem

by Sumit Garg

This patch-set does restructuring of trusted keys code to create and consolidate trusted keys subsystem. Changes in v5: 1. Drop 5/5 patch as its more relavant along with TEE patch-set. 2. Add Reviewed-by tag for patch #2. 3. Fix build failure when "CONFIG_HEADER_TEST" and "CONFIG_KERNEL_HEADER_TEST" config options are enabled. 4. Misc changes to rename files. Changes in v4: 1. Separate patch for export of tpm_buf code to include/linux/tpm.h 2. Change TPM1.x trusted keys code to use common tpm_buf 3. Keep module name as trusted.ko only Changes in v3: Move TPM2 trusted keys code to trusted keys subsystem. Changes in v2: Split trusted keys abstraction patch for ease of review. Sumit Garg (4): tpm: move tpm_buf code to include/linux/ KEYS: trusted: use common tpm_buf for TPM1.x code KEYS: trusted: create trusted keys subsystem KEYS: trusted: move tpm2 trusted keys code crypto/asymmetric_keys/asym_tpm.c | 2 +- drivers/char/tpm/tpm-chip.c | 1 + drivers/char/tpm/tpm-interface.c | 56 --- drivers/char/tpm/tpm.h | 230 ------------- drivers/char/tpm/tpm2-cmd.c | 308 +---------------- include/Kbuild | 1 - include/keys/{trusted.h => trusted_tpm.h} | 49 +-- include/linux/tpm.h | 270 ++++++++++++++- security/keys/Makefile | 2 +- security/keys/trusted-keys/Makefile | 8 + .../{trusted.c => trusted-keys/trusted_tpm1.c} | 92 +++-- security/keys/trusted-keys/trusted_tpm2.c | 378 +++++++++++++++++++++ 12 files changed, 697 insertions(+), 700 deletions(-) rename include/keys/{trusted.h => trusted_tpm.h} (77%) create mode 100644 security/keys/trusted-keys/Makefile rename security/keys/{trusted.c => trusted-keys/trusted_tpm1.c} (94%) create mode 100644 security/keys/trusted-keys/trusted_tpm2.c -- 2.7.4

5 years, 2 months

[RFC/RFT v3 0/3] KEYS: trusted: Add generic trusted keys framework

by Sumit Garg

This patch-set is an outcome of discussion here [1]. I have tested this framework with trusted keys support provided via TEE but I wasn't able to test it with a TPM device as I don't possess one. It would be really helpful if others could test this patch-set using a TPM device. [1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg30591.html Changes in v3: Move TPM2 trusted keys code to trusted keys subsystem. Changes in v2: Split trusted keys abstraction patch for ease of review. Sumit Garg (3): KEYS: trusted: create trusted keys subsystem KEYS: trusted: move tpm2 trusted keys code KEYS: trusted: Add generic trusted keys framework crypto/asymmetric_keys/asym_tpm.c | 2 +- drivers/char/tpm/tpm-interface.c | 56 --- drivers/char/tpm/tpm.h | 224 ------------ drivers/char/tpm/tpm2-cmd.c | 307 ----------------- include/keys/trusted-type.h | 45 +++ include/keys/{trusted.h => trusted_tpm.h} | 42 +-- include/linux/tpm.h | 264 +++++++++++++- security/keys/Makefile | 2 +- security/keys/trusted-keys/Makefile | 8 + .../keys/{trusted.c => trusted-keys/trusted-tpm.c} | 363 ++++---------------- security/keys/trusted-keys/trusted-tpm2.c | 378 +++++++++++++++++++++ security/keys/trusted-keys/trusted.c | 343 +++++++++++++++++++ 12 files changed, 1109 insertions(+), 925 deletions(-) rename include/keys/{trusted.h => trusted_tpm.h} (72%) create mode 100644 security/keys/trusted-keys/Makefile rename security/keys/{trusted.c => trusted-keys/trusted-tpm.c} (76%) create mode 100644 security/keys/trusted-keys/trusted-tpm2.c create mode 100644 security/keys/trusted-keys/trusted.c -- 2.7.4

5 years, 3 months

[RFC v2 0/6] Introduce TEE based Trusted Keys support

by Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality to seal and unseal trusted keys using hardware unique key. Also, this is an alternative in case platform doesn't possess a TPM device. This series also adds some TEE features like: Patch #1, #2 enables support for registered kernel shared memory with TEE. Patch #3 enables support for private kernel login method required for cases like trusted keys where we don't wan't user-space to directly access TEE service to retrieve trusted key contents. Rest of the patches from #4 to #6 adds support for TEE based trusted keys. This patch-set has been tested with OP-TEE based pseudo TA which can be found here [1]. Also, this patch-set is dependent on generic Trusted Keys framework patch-set [2]. [1] https://github.com/OP-TEE/optee_os/pull/3082 [2] https://lkml.org/lkml/2019/7/18/284 Changes in v2: 1. Add reviewed-by tags for patch #1 and #2. 2. Incorporate comments from Jens for patch #3. 3. Switch to use generic trusted keys framework. Sumit Garg (6): tee: optee: allow kernel pages to register as shm tee: enable support to register kernel memory tee: add private login method for kernel clients KEYS: trusted: Introduce TEE based Trusted Keys doc: keys: Document usage of TEE based Trusted Keys MAINTAINERS: Add entry for TEE based Trusted Keys Documentation/security/keys/index.rst | 1 + Documentation/security/keys/tee-trusted.rst | 93 +++++++++ MAINTAINERS | 9 + drivers/tee/optee/call.c | 7 + drivers/tee/tee_core.c | 6 + drivers/tee/tee_shm.c | 16 +- include/keys/trusted-type.h | 3 + include/keys/trusted_tee.h | 66 +++++++ include/linux/tee_drv.h | 1 + include/uapi/linux/tee.h | 8 + security/keys/Kconfig | 3 + security/keys/trusted-keys/Makefile | 3 +- security/keys/trusted-keys/trusted-tee.c | 282 ++++++++++++++++++++++++++++ security/keys/trusted-keys/trusted.c | 3 + 14 files changed, 498 insertions(+), 3 deletions(-) create mode 100644 Documentation/security/keys/tee-trusted.rst create mode 100644 include/keys/trusted_tee.h create mode 100644 security/keys/trusted-keys/trusted-tee.c -- 2.7.4

5 years, 3 months

shared memory with kernel client interface

by Stuart Yoder

Hi Jens, In the kernel internal client interface that you added last year one client function not added was one to register shared memory. Was there any reason in particular that a tee_client_shm_register() was not included? Was going to experiment with that but wanted to check first whether there was some known complexity or difficulty I'm going to run into. Thanks, Stuart

5 years, 3 months

[PATCH v8 0/2] fTPM: firmware TPM running in TEE

by Sasha Levin

Changes from v7: - Address Jarkko's comments. Sasha Levin (2): fTPM: firmware TPM running in TEE fTPM: add documentation for ftpm driver Documentation/security/tpm/index.rst | 1 + Documentation/security/tpm/tpm_ftpm_tee.rst | 27 ++ drivers/char/tpm/Kconfig | 5 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_ftpm_tee.c | 350 ++++++++++++++++++++ drivers/char/tpm/tpm_ftpm_tee.h | 40 +++ 6 files changed, 424 insertions(+) create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h -- 2.20.1

5 years, 3 months

[RFC/RFT v2 0/2] KEYS: trusted: Add generic trusted keys framework

by Sumit Garg

This patch-set is an outcome of discussion here [1]. I have tested this framework with trusted keys support provided via TEE but I wasn't able to test it with a TPM device as I don't possess one. It would be really helpful if others could test this patch-set using a TPM device. [1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg30591.html Changes in v2: Split trusted keys abstraction patch for ease of review. Sumit Garg (2): KEYS: trusted: create trusted keys subsystem KEYS: trusted: Add generic trusted keys framework crypto/asymmetric_keys/asym_tpm.c | 2 +- include/keys/trusted-type.h | 45 +++ include/keys/{trusted.h => trusted_tpm.h} | 19 +- security/keys/Makefile | 2 +- security/keys/trusted-keys/Makefile | 7 + .../keys/{trusted.c => trusted-keys/trusted-tpm.c} | 347 ++++----------------- security/keys/trusted-keys/trusted.c | 343 ++++++++++++++++++++ 7 files changed, 458 insertions(+), 307 deletions(-) rename include/keys/{trusted.h => trusted_tpm.h} (85%) create mode 100644 security/keys/trusted-keys/Makefile rename security/keys/{trusted.c => trusted-keys/trusted-tpm.c} (77%) create mode 100644 security/keys/trusted-keys/trusted.c -- 2.7.4

5 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev August 2019