- OP-TEE - lists.trustedfirmware.org

Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys

by Jerome Forissier

On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote: > On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote: >> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko(a)kernel.org> wrote: >>> >>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote: >>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote: >>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko(a)kernel.org> wrote: >>>>>> >>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote: >>>>>>> Hi Jarkko, >>>>>>> >>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko(a)kernel.org> wrote: >>>>>>>> >>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote: >>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality >>>>>>>>> to seal and unseal trusted keys using hardware unique key. >>>>>>>>> >>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE. >>>>>>>>> >>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> >>>>>>>> >>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces >>>>>>>> just a blank screen: >>>>>>>> >>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio >>>>>>>> >>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here: >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/ >>>>>>>> >>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will >>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then >>>>>>>> in the master branch. >>>>>>>> >>>>>>>> To create identical images you just need to >>>>>>>> >>>>>>>> $ make tpmdd_defconfig && make >>>>>>>> >>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this >>>>>>>> patch set, and in bigger picture I really need to have ready to run >>>>>>>> aarch64 environment available. >>>>>>> >>>>>>> I would rather suggest you to follow steps listed here [1] as to test >>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A, >>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build >>>>>>> system [2]. And then it would be easier to migrate them to your >>>>>>> buildroot environment as well. >>>>>>> >>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html >>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8 >>>>>>> >>>>>>> -Sumit >>>>>> >>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow. >>>>>> >>>>> >>>>> $ cat keyctl_change >>>>> diff --git a/common.mk b/common.mk >>>>> index aeb7b41..663e528 100644 >>>>> --- a/common.mk >>>>> +++ b/common.mk >>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR) >>>>> BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH) >>>>> BR2_PACKAGE_STRACE ?= y >>>>> BR2_TARGET_GENERIC_GETTY_PORT ?= $(if >>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0) >>>>> +BR2_PACKAGE_KEYUTILS := y >>>>> >>>>> # All BR2_* variables from the makefile or the environment are appended to >>>>> # ../out-br/extra.conf. All values are quoted "..." except y and n. >>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf >>>>> index 368c18a..832ab74 100644 >>>>> --- a/kconfigs/qemu.conf >>>>> +++ b/kconfigs/qemu.conf >>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y >>>>> CONFIG_9P_FS_POSIX_ACL=y >>>>> CONFIG_HW_RANDOM=y >>>>> CONFIG_HW_RANDOM_VIRTIO=y >>>>> +CONFIG_TRUSTED_KEYS=y >>>>> +CONFIG_ENCRYPTED_KEYS=y >>>>> >>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more >>>>>> version and CC the documentation patch to Elaine and Mini, and clearly >>>>>> remark in the commit message that TEE is a standard, with a link to the >>>>>> specification. >>>>>> >>>>> >>>>> Sure, I will roll out the next version after your testing. >>>> >>>> Thanks, I'll try this at instant, and give my feedback. >>> >>> I bump into this: >>> >>> $ make run-only >>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/ >>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory >>> make: *** [Makefile:194: run-only] Error 1 >>> >> >> Could you check if the following directory tree is built after >> executing the below command? >> >> $ make -j`nproc` >> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c >> >> $ tree out/bin/ >> out/bin/ >> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin >> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin >> ├── bl31.bin -> >> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin >> ├── bl32.bin -> >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin >> ├── bl32_extra1.bin -> >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin >> ├── bl32_extra2.bin -> >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin >> ├── bl33.bin -> >> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd >> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image >> └── rootfs.cpio.gz -> >> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz >> >> 0 directories, 9 files >> >> -Sumit > > I actually spotted a build error that was unnoticed last time: > > make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests' > /bin/sh: 1: python: not found > > I'd prefer not to install Python2. It has been EOL over a year. AFAIK, everything should build fine with Python3. On my Ubuntu 20.04 machine, this is accomplished by installing package "python-is-python3" (after uninstalling "python-is-python2" if need be). $ ls -l /usr/bin/python lrwxrwxrwx 1 root root 7 Apr 15 2020 /usr/bin/python -> python3 -- Jerome

4 years, 9 months

3
14
0 0

[PATCH 0/2] optee: fix OOM seen due to tee_shm_free()

by Allen Pais

From: Allen Pais <apais(a)linux.microsoft.com> The following out of memory errors are seen on kexec reboot from the optee core. [ 0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed [ 0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22 tee_shm_release() is not invoked on dma shm buffer. Implement .shutdown() in optee core as well as bnxt firmware driver to handle the release of the buffers correctly. More info: https://github.com/OP-TEE/optee_os/issues/3637 Allen Pais (2): optee: fix tee out of memory failure seen during kexec reboot firmware: tee_bnxt: implement shutdown method to handle kexec reboots drivers/firmware/broadcom/tee_bnxt_fw.c | 9 ++++ drivers/tee/optee/core.c | 69 ++++++++++++++++++------- 2 files changed, 58 insertions(+), 20 deletions(-) -- 2.25.1

4 years, 9 months

4
9
0 0

Linaro OP-TEE Contributions meeting February 2021

by Joakim Bech

Hi, LOC monthly meeting is planned to take place on Thursday February 25th @ 16.00 (UTC+1). We're looking for topics to discuss in general. Eventually we'll have a presentation from Achin Gupta from Arm talking about the FF-A spec. Meeting details: --------------- Date/time: Thursday Feb 25th(a)16.00 (UTC+1) https://everytimezone.com/s/c4e5d6a3 Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects/#LOC Regards, Joakim on behalf of the Linaro OP-TEE team

4 years, 9 months

1
1
0 0

Re: Possible OB1 bug in imx_csu.c

by Jerome Forissier

Hi Robert, On 2/22/21 11:01 AM, Robert Delien via OP-TEE wrote: > Hi, > > In imx_csu.c, the Central Security Unit's CSU_CSL*n* registers are set, > configuring access privileges for different peripherals. These registers > range from CSU_CSL0 (@ 0x021c0000) to CSU_CSL39 (@ 0x021c009c). > > The different i.MX6 platform variants each have their individual tables, > filled with sets of CSL index and register value, terminated by a sentinel > set with the index set to -1. (the reason for the parentheses around -1 > espaces me) > > in .../core/arch/arm/plat-imx/drivers/imx_csu.c:csu_init()@115, a while > loop runs through this aforementioned table, setting the CSL registers > according to the table. However, this loop loops on CSL index values > 0: > while (csu_setting->csu_index *>* 0) { > io_write32(csu_base + (csu_setting->csu_index * 4), > csu_setting->value); > > csu_setting++; > } > I think it should loop on CSL index values >= 0, because index 0 is a valid > index, utilized for the PWM peripherals. (I also think csl_index is a more > descriptive name, but that's besides the point). > > I have attached a patch for his. It does look like a genuine bug to me, but I will let the i.MX expert comment further. Unfortunately, the OP-TEE ML strips attachments. Would you mind creating a GitHub pull request [1] (preferred method), or send the patch inline? [1] https://github.com/OP-TEE/optee_os/pulls Thanks, -- Jerome

4 years, 9 months

1
0
0 0

Possible OB1 bug in imx_csu.c

by Robert Delien

Hi, In imx_csu.c, the Central Security Unit's CSU_CSL*n* registers are set, configuring access privileges for different peripherals. These registers range from CSU_CSL0 (@ 0x021c0000) to CSU_CSL39 (@ 0x021c009c). The different i.MX6 platform variants each have their individual tables, filled with sets of CSL index and register value, terminated by a sentinel set with the index set to -1. (the reason for the parentheses around -1 espaces me) in .../core/arch/arm/plat-imx/drivers/imx_csu.c:csu_init()@115, a while loop runs through this aforementioned table, setting the CSL registers according to the table. However, this loop loops on CSL index values > 0: while (csu_setting->csu_index *>* 0) { io_write32(csu_base + (csu_setting->csu_index * 4), csu_setting->value); csu_setting++; } I think it should loop on CSL index values >= 0, because index 0 is a valid index, utilized for the PWM peripherals. (I also think csl_index is a more descriptive name, but that's besides the point). I have attached a patch for his. With kind regards, Robert. -- DISCLAIMER De informatie, verzonden in of met dit e-mailbericht, is vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het gebruik van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging, verspreiding en|of verstrekking daarvan aan derden is niet toegestaan. Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt verboden. Aan deze informatie kunnen geen rechten worden ontleend. U wordt verzocht bij onjuiste adressering de afzender direct te informeren door het bericht te retourneren en het bericht uit uw computersysteem te verwijderen.

4 years, 9 months

1
0
0 0

[PATCH v8 0/4] 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 patch-set has been tested with OP-TEE based early TA which is already merged in upstream [1]. [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d… Changes in v8: 1. Added static calls support instead of indirect calls. 2. Documented trusted keys source module parameter. 3. Refined patch #1 commit message discription. 4. Addressed misc. comments on patch #2. 5. Added myself as Trusted Keys co-maintainer instead. 6. Rebased to latest tpmdd master. Changes in v7: 1. Added a trusted.source module parameter in order to enforce user's choice in case a particular platform posses both TPM and TEE. 2. Refine commit description for patch #1. Changes in v6: 1. Revert back to dynamic detection of trust source. 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. 3. Rebased to latest tpmdd/master. Changes in v5: 1. Drop dynamic detection of trust source and use compile time flags instead. 2. Rename trusted_common.c -> trusted_core.c. 3. Rename callback: cleanup() -> exit(). 4. Drop "tk" acronym. 5. Other misc. comments. 6. Added review tags for patch #3 and #4. Changes in v4: 1. Pushed independent TEE features separately: - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 2. Updated trusted-encrypted doc with TEE as a new trust source. 3. Rebased onto latest tpmdd/master. Changes in v3: 1. Update patch #2 to support registration of multiple kernel pages. 2. Incoporate dependency patch #4 in this patch-set: https://patchwork.kernel.org/patch/11091435/ 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 (4): KEYS: trusted: Add generic trusted keys framework KEYS: trusted: Introduce TEE based Trusted Keys doc: trusted-encrypted: updates with TEE as a new trust source MAINTAINERS: Add myself as Trusted Keys co-maintainer Documentation/admin-guide/kernel-parameters.txt | 12 + Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++-- MAINTAINERS | 2 + include/keys/trusted-type.h | 47 +++ include/keys/trusted_tee.h | 55 ++++ include/keys/trusted_tpm.h | 17 +- security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_core.c | 354 ++++++++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 278 +++++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 336 ++++---------------- 10 files changed, 979 insertions(+), 327 deletions(-) create mode 100644 include/keys/trusted_tee.h create mode 100644 security/keys/trusted-keys/trusted_core.c create mode 100644 security/keys/trusted-keys/trusted_tee.c -- 2.7.4

4 years, 10 months

6
36
0 0

Re: [Tee-dev] OpenVPN hardening with OP-TEE

by Jerome Forissier

Hi Kris, [CC op-tee(a)lists.trustedfirmware.org the newer ML for OP-TEE which is now under the TrustedFirmware.org umbrella] On 2/9/21 11:04 PM, Kris Kwiatkowski wrote: > Hello, > > I've recently been involved in producing PoC, which utilizes OP-TEE > to produce proof of a secret key possession. That is used during tunnel > establishment by OpenVPN. > > In case someone finds it interesting, for example as kind of "real-world" > use case of OP-TEE, then details are described here: > https://www.amongbytes.com/post/20210112-optee-openssl-engine/ Thanks for sharing! It is a well-written article, quite interesting to read IMO. I always like to see how OP-TEE is used in various scenarios. As upstream project maintainers we hear about bug reports and we review new contributions of course, but there is clearly a lot of activity going on downstream that we don't know much about. Yet, a bit of context certainly helps take the good decisions for the project going forward! > and code is here: > https://github.com/henrydcase/optee_eng > > The actual PoC used post-quantum schemes integrated into TEE OS and TF-A > (secure boot). Those two points are not described really described for brevity > (and probably there is low interest anyway). > > Kind regards, > Kris > _______________________________________________ > Tee-dev mailing list > Tee-dev(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/tee-dev Thanks, -- Jerome

4 years, 10 months

1
0
0 0

[PATCH v2] hwrng: optee: Use device-managed registration API

by Tian Tao

Use devm_hwrng_register to get rid of manual unregistration. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> --- v2:Fix up subject line as s/hwrng: optee -:/hwrng: optee:/ --- drivers/char/hw_random/optee-rng.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c index a99d829..135a825 100644 --- a/drivers/char/hw_random/optee-rng.c +++ b/drivers/char/hw_random/optee-rng.c @@ -243,7 +243,7 @@ static int optee_rng_probe(struct device *dev) if (err) goto out_sess; - err = hwrng_register(&pvt_data.optee_rng); + err = devm_hwrng_register(dev, &pvt_data.optee_rng); if (err) { dev_err(dev, "hwrng registration failed (%d)\n", err); goto out_sess; @@ -263,7 +263,6 @@ static int optee_rng_probe(struct device *dev) static int optee_rng_remove(struct device *dev) { - hwrng_unregister(&pvt_data.optee_rng); tee_client_close_session(pvt_data.ctx, pvt_data.session_id); tee_client_close_context(pvt_data.ctx); -- 2.7.4

4 years, 10 months

2
1
0 0

[GIT PULL] OP-TEE I2C simplification for v5.12

by Jens Wiklander

Hello arm-soc maintainers, Please pull this fix eliminating a stack frame size warning and also simplifying I2C access in the OP-TEE driver. Thanks, Jens The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-simplify-i2c-access_for-v5.12 for you to fetch changes up to 67bc809752796acb2641ca343cad5b45eef31d7c: optee: simplify i2c access (2021-02-08 13:42:31 +0100) ---------------------------------------------------------------- Simplify i2c acess in OP-TEE driver ---------------------------------------------------------------- Arnd Bergmann (1): optee: simplify i2c access drivers/tee/optee/rpc.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-)

4 years, 10 months

2
1
0 0

[PATCH] tee: optee: add invoke_fn tracepoints

by Jisheng Zhang

Add tracepoints to retrieve information about the invoke_fn. This would help to measure how many invoke_fn are triggered and how long it takes to complete one invoke_fn call. Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> --- drivers/tee/optee/call.c | 4 ++ drivers/tee/optee/optee_trace.h | 65 +++++++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+) create mode 100644 drivers/tee/optee/optee_trace.h diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 780d7c4fd756..9dbab10e7ac3 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -12,6 +12,8 @@ #include <linux/tee_drv.h> #include <linux/types.h> #include <linux/uaccess.h> +#define CREATE_TRACE_POINTS +#include "optee_trace.h" #include "optee_private.h" #include "optee_smc.h" @@ -138,9 +140,11 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) while (true) { struct arm_smccc_res res; + trace_optee_invoke_fn_begin(&param); optee->invoke_fn(param.a0, param.a1, param.a2, param.a3, param.a4, param.a5, param.a6, param.a7, &res); + trace_optee_invoke_fn_end(&param, &res); if (res.a0 == OPTEE_SMC_RETURN_ETHREAD_LIMIT) { /* diff --git a/drivers/tee/optee/optee_trace.h b/drivers/tee/optee/optee_trace.h new file mode 100644 index 000000000000..f209df7004c2 --- /dev/null +++ b/drivers/tee/optee/optee_trace.h @@ -0,0 +1,65 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * optee trace points + * + * Copyright (C) 2021 Synaptics Incorporated + * Author: Jisheng Zhang <jszhang(a)kernel.org> + */ + +#undef TRACE_SYSTEM +#define TRACE_SYSTEM optee + +#if !defined(_TRACE_OPTEE_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_OPTEE_H + +#include <linux/arm-smccc.h> +#include <linux/tracepoint.h> +#include "optee_private.h" + +TRACE_EVENT(optee_invoke_fn_begin, + TP_PROTO(struct optee_rpc_param *param), + TP_ARGS(param), + + TP_STRUCT__entry( + __field(void *, param) + __array(u32, args, 8) + ), + + TP_fast_assign( + __entry->param = param; + memcpy(__entry->args, param, sizeof(__entry->args)); + ), + + TP_printk("param=%p (%x, %x, %x, %x, %x, %x, %x, %x)", __entry->param, + __entry->args[0], __entry->args[1], __entry->args[2], + __entry->args[3], __entry->args[4], __entry->args[5], + __entry->args[6], __entry->args[7]) +); + +TRACE_EVENT(optee_invoke_fn_end, + TP_PROTO(struct optee_rpc_param *param, struct arm_smccc_res *res), + TP_ARGS(param, res), + + TP_STRUCT__entry( + __field(void *, param) + __array(unsigned long, rets, 4) + ), + + TP_fast_assign( + __entry->param = param; + memcpy(__entry->rets, res, sizeof(__entry->rets)); + ), + + TP_printk("param=%p ret (%lx, %lx, %lx, %lx)", __entry->param, + __entry->rets[0], __entry->rets[1], __entry->rets[2], + __entry->rets[3]) +); +#endif /* _TRACE_OPTEE_H */ + +#undef TRACE_INCLUDE_PATH +#define TRACE_INCLUDE_PATH . +#undef TRACE_INCLUDE_FILE +#define TRACE_INCLUDE_FILE optee_trace + +/* This part must be outside protection */ +#include <trace/define_trace.h> -- 2.30.0

4 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

OP-TEE