Tee-dev

tee-dev@lists.linaro.org

1 participants
293 discussions

what are the technical challenges for people developing TEEs and TEE apps?

by Simon Hughes

Hi A number of people are getting interested in developing trusted applications for TEEs (not just for OPTEE) and they want to understand the development and technical challenges that will be encountered. They're looking for technical foresight. I thought we could draw on our OPTEE expertise and look to whether we can develop insights applicable across all TEEs. Practical information about limitations may provide insights. It's a broad question and I don't want to limit the scope to the following list, but here's some guidance on possible key technical factors causing limitations to arise: - Memory footprint. o What's the impact both for volatile and non-volatile? - Code size. o This is a massive issue for the IoT space, less so for edge devices. Does aarch64 v aarch32 have a big impact? How big? What other factors. - Portability. - Software Stack o UEFI/BIOS support for security? o TEE software update mechanism? o Convergence on a standardized bootchain? o Adoption/deployment of Global Platform interface? o Bootloader impact (generally), ATF, u-boot, kernel. - Toolchain support/Developing in languages other than C. o I know OPTEE doesn't support C++. Why? Is there partial support? o I read somewhere GOlang has aarch64 issues for normal world OS. - Normal World OS interworking. o Any standardisation of interfacing to a tee? - Certification/Testing. o Is there a standard toolchain for conformance testing? - Device support. o TPMs. o eSims. - Anything else? Best Simon IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 7 months

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

by Sasha Levin

Changes from v4: - Don't show an error message while waiting for OP-TEE to come up. 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 | 31 ++ drivers/char/tpm/Kconfig | 5 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_ftpm_tee.c | 382 ++++++++++++++++++++ drivers/char/tpm/tpm_ftpm_tee.h | 40 ++ 6 files changed, 460 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

6 years, 7 months

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

by Sasha Levin

Changes since v3: - Address comments by Jarkko Sakkinen - Address comments by Igor Opaniuk 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 | 31 ++ drivers/char/tpm/Kconfig | 5 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_ftpm_tee.c | 380 ++++++++++++++++++++ drivers/char/tpm/tpm_ftpm_tee.h | 40 +++ 6 files changed, 458 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

6 years, 7 months

[PATCH v5 00/10] TEE mediator (and OP-TEE) support in XEN

by Volodymyr Babchuk

Hello community, This is the fifth version of OP-TEE mediator in XEN. OP-TEE 3.5.0 was released when I worked on this version of the pathes. This is the first release where virtualization support is available. This release includes both original virtualization patches and new SMC that retrevies number of threads from OP-TEE. Many thanks to both OP-TEE and Xen communities for reviewing and helping with my changes to the both projects. Global changes from v4: - 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 Overall changes from v3: - 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. Per-patch changes are described in corresponding emails. Changes from v2: - 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" Per-patch changes are described in corresponding emails. ==== 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 Volodymyr Babchuk (10): xen/arm: add generic TEE mediator framework xen/arm: optee: add OP-TEE header files xen/arm: optee: add OP-TEE mediator skeleton xen/arm: optee: add fast calls handling xen/arm: optee: add std call handling xen/arm: optee: add support for RPC SHM buffers xen/arm: optee: add support for arbitrary shared memory xen/arm: optee: add support for RPC commands tools/arm: tee: add "tee" option for xl.cfg tools/arm: optee: create optee firmware node in DT if tee=optee MAINTAINERS | 6 + docs/man/xl.cfg.5.pod.in | 19 + 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 | 9 + xen/arch/arm/Makefile | 1 + xen/arch/arm/domain.c | 19 + xen/arch/arm/setup.c | 2 + xen/arch/arm/tee/Kconfig | 4 + xen/arch/arm/tee/Makefile | 2 + xen/arch/arm/tee/optee.c | 1536 +++++++++++++++++++++++++++ xen/arch/arm/tee/tee.c | 93 ++ xen/arch/arm/vsmc.c | 5 + xen/arch/arm/xen.lds.S | 7 + xen/include/asm-arm/domain.h | 4 + xen/include/asm-arm/tee/optee_msg.h | 444 ++++++++ xen/include/asm-arm/tee/optee_smc.h | 556 ++++++++++ xen/include/asm-arm/tee/tee.h | 109 ++ xen/include/public/arch-arm.h | 4 + 21 files changed, 2882 insertions(+) create mode 100644 xen/arch/arm/tee/Kconfig create mode 100644 xen/arch/arm/tee/Makefile create mode 100644 xen/arch/arm/tee/optee.c create mode 100644 xen/arch/arm/tee/tee.c create mode 100644 xen/include/asm-arm/tee/optee_msg.h create mode 100644 xen/include/asm-arm/tee/optee_smc.h create mode 100644 xen/include/asm-arm/tee/tee.h -- 2.21.0

6 years, 7 months

[PATCH] MAINTAINERS: Add mailing list for the TEE subsystem

by Sumit Garg

Add a mailing list for patch reviews and discussions related to TEE subsystem. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 920a0a1..c05dff7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11556,11 +11556,13 @@ F: drivers/scsi/st.h OP-TEE DRIVER M: Jens Wiklander <jens.wiklander(a)linaro.org> +L: tee-dev(a)lists.linaro.org S: Maintained F: drivers/tee/optee/ OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER M: Sumit Garg <sumit.garg(a)linaro.org> +L: tee-dev(a)lists.linaro.org S: Maintained F: drivers/char/hw_random/optee-rng.c @@ -15312,6 +15314,7 @@ F: include/media/i2c/tw9910.h TEE SUBSYSTEM M: Jens Wiklander <jens.wiklander(a)linaro.org> +L: tee-dev(a)lists.linaro.org S: Maintained F: include/linux/tee_drv.h F: include/uapi/linux/tee.h -- 2.7.4

6 years, 8 months

SRAM support for crypto keys storage without CFG_WITH_PAGER

by Kostya Porotchkin

Hello, My platform (armada7k8k) does not have a native ("true") SRAM, but a part of CPU last level cache (LLC) could be switched into SRAM mode. The resulting SRAM is quite small and is not immediately available at OP-TEE OS entry point, thus could not contain the OP-TEE OS code itself. However I would like to keep cryptographic keys there (the SRAM is located on the CPU die) instead of using external (unencrypted) TZ DRAM. As far as I can see from the OS core code, the TZSRAM_* definitions are only taken into account when the pager is enabled. Which part of the OP-TEE OS core should be reviewed for the required changes? How do I ensure that the memory for crypto keys is always allocated form the secure SRAM pull? I prefer to use the existing OS infrastructure instead of adding proprietary memory and key management code. Thank you for your help! Konstantin

6 years, 8 months

Re: [Tee-dev] [PATCH v3 0/2] ftpm: a firmware based TPM driver

by Sumit Garg

+ TEE ML Hi Sasha, Firstly apologies for my comments here as I recently joined linux-integrity ML so I don't have other patches in my inbox. Also, it would be nice if you could cc TEE ML in future patches, so that people are aware of such interesting use-cases and may provide some feedback. On Tue, 7 May 2019 at 23:10, Sasha Levin <sashal(a)kernel.org> wrote: > > On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > >From: "Sasha Levin (Microsoft)" <sashal(a)kernel.org> > > > >Changes since v2: > > > > - Drop the devicetree bindings patch (we don't add any new ones). > > - More code cleanups based on Jason Gunthorpe's review. > > > >Sasha Levin (2): > > ftpm: firmware TPM running in TEE > > ftpm: add documentation for ftpm driver > > Ping? Does anyone have any objections to this? > >From [PATCH v3 1/2] ftpm: firmware TPM running in TEE: > +static const struct of_device_id of_ftpm_tee_ids[] = { > + { .compatible = "microsoft,ftpm" }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids); > + > +static struct platform_driver ftpm_tee_driver = { > + .driver = { > + .name = DRIVER_NAME, > + .of_match_table = of_match_ptr(of_ftpm_tee_ids), > + }, > + .probe = ftpm_tee_probe, > + .remove = ftpm_tee_remove, > +}; > + > +module_platform_driver(ftpm_tee_driver); Here this fTPM driver (seems to communicate with OP-TEE based TA) should register on TEE bus [1] rather than platform bus as its actual dependency is on TEE driver rather than using deferred probe to meet its dependency. Have a look at OP-TEE based RNG driver here [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -Sumit > -- > Thanks, > Sasha

6 years, 9 months

OP-TEE 3.5.0-rc1 in 10 days

by Jerome Forissier

[Sent to all e-mail addresses found in optee_os/MAINTAINERS] Dear OP-TEE users and contributors, FYI, the next OP-TEE release (3.5.0) is scheduled for April 26. As usual, I will create the -rc1 tag one week before. In the meantime, please update your pending pull requests, help review patches on GitHub, run some tests on master etc. I will let you know when the -rc1 tag is ready for testing, at which point I will collect Tested-by tags in pull request #2937 [1], and merge only bug fixes into master. Thanks for your continued help and support! [2] https://github.com/OP-TEE/optee_os/pull/2937 Regards, -- Jerome

6 years, 9 months

[PATCH v4 00/10] TEE mediator (and OP-TEE) support in XEN

by Volodymyr Babchuk

From: Volodymyr Babchuk <vlad.babchuk(a)gmail.com> Hello all, This is the 4th version of TEE mediator patch series. In the meantime virtualization support were merged into OP-TEE mainline. Last time our mail server changed order of messages in the mail thread. I hope, this time it will send them in the right way. But, please pay attention to the patch number in the subject just in case. Overall changes from 3: - 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. Per-patch changes are described in corresponding emails. Changes from v2: - 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" Per-patch changes are described in corresponding emails. ==== 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 Volodymyr Babchuk (10): xen/arm: add generic TEE mediator framework xen/arm: optee: add OP-TEE header files xen/arm: optee: add OP-TEE mediator skeleton xen/arm: optee: add fast calls handling xen/arm: optee: add std call handling xen/arm: optee: add support for RPC SHM buffers xen/arm: optee: add support for arbitrary shared memory xen/arm: optee: add support for RPC commands tools/arm: tee: add "tee" option for xl.cfg tools/arm: optee: create optee firmware node in DT if tee=native MAINTAINERS | 6 + docs/man/xl.cfg.5.pod.in | 12 + 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 | 9 + xen/arch/arm/Makefile | 1 + xen/arch/arm/domain.c | 14 + xen/arch/arm/setup.c | 8 + xen/arch/arm/tee/Kconfig | 4 + xen/arch/arm/tee/Makefile | 2 + xen/arch/arm/tee/optee.c | 1395 +++++++++++++++++++++++++++ xen/arch/arm/tee/tee.c | 79 ++ xen/arch/arm/vsmc.c | 5 + xen/arch/arm/xen.lds.S | 7 + xen/include/asm-arm/domain.h | 4 + xen/include/asm-arm/tee/optee_msg.h | 444 +++++++++ xen/include/asm-arm/tee/optee_smc.h | 569 +++++++++++ xen/include/asm-arm/tee/tee.h | 106 ++ xen/include/public/arch-arm.h | 4 + 21 files changed, 2731 insertions(+) create mode 100644 xen/arch/arm/tee/Kconfig create mode 100644 xen/arch/arm/tee/Makefile create mode 100644 xen/arch/arm/tee/optee.c create mode 100644 xen/arch/arm/tee/tee.c create mode 100644 xen/include/asm-arm/tee/optee_msg.h create mode 100644 xen/include/asm-arm/tee/optee_smc.h create mode 100644 xen/include/asm-arm/tee/tee.h -- 2.21.0

6 years, 10 months

Crypto library in OP-TEE

by Jens Wiklander

Hi, We have an ongoing action to integrate mbedtls in OP-TEE to be used in OP-TEE core via the <crypto/crypto.h> interface. Then there's also a library developed by NXP to take advantage of CAAM for crypto acceleration. The way we're dealing with different crypto algorithms today isn't very modular. I think we can disregard the asymmetric algorithms for now. We've already put the algorithms in different groups, hashes, macs, ciphers (which includes modes like CBC, CTR etc), and authenc (authenticated encryption). This was good enough for our initial libtomcrypt integration, but I think it has been a bit painful for the ongoing mbedtls integration. With CAAM it was solved by using an entire new wrapper layer to work with libtomcrypt. Cedric has shown benchmark that the new wrapping didn't cause any noticeable degradation in performance. To try a more fine grained modular approach I've converted the authenc algorithms to use a struct crypto_authenc_ops internally to call the needed functions [1]. This makes it easier to replace one implementation with another, it's just a matter of calling the correct crypto_aes_gcm_alloc_ctx() function for AES-GCM and the rest of the implementation will be selected automatically. The different functions allocating an AEC-GCM context should probably have different names instead of using the same as in [1], but that doesn't have to be decided right now. With the approach in [1] applied on hashes, macs and ciphers too I think it would be much easier to integrate any crypto library. For paging we'll still have special interfaces to do SHA-256 or AES-GCM, this is needed in order minimize the dependency graph for unpaged code and also make sure that it's always callable from abort mode (doesn't cause deadlock or whatever). What do you think? Is this too much, too little? Cheers, Jens [1] https://github.com/OP-TEE/optee_os/pull/2862

6 years, 11 months

← Newer
1
...
13
14
15
16
17
18
19
...
30
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev