- OP-TEE - lists.trustedfirmware.org

Request for support opensource optee contribution guide line

by Yejerla, VeeraraghavuluX

Dear Sir, I would like to know that, if I want submit any patch for optee opensource features, could please guide me what are the guide line I have to follow it. Below are some information require . 1. What is the maximum patch size shall I submit? 2. What are the code guide line I have to follow it? 3. What are mail chain I have to include for patch review purpose? 4. Is there any open source link for post quarry ? Regards, Raghu

5 years, 3 months

1
0
0 0

Re: Linaro OP-TEE Contributions meeting February 2021

by Jérôme Forissier

Hi, On Thu, Feb 25, 2021 at 9:41 AM Joakim Bech via OP-TEE < op-tee(a)lists.trustedfirmware.org> wrote: > Hi Jorge, > > On Wed, 24 Feb 2021 at 18:14, Jorge Ramirez <jorge(a)foundries.io> wrote: > > > Sorry Joakim. > > I guess it is too late now but It would have been good to talk about the > > TEE strategy/direction with RNG. > > 1) how often do we seed the PRNG. > > 2) should we always use PRNG and only use HWRNG to seed if with a certain > > cadence. > > 3) how do we measure the quality of an RNG in OPTEE (how do we guarantee > > no regressions) > > this would be really an open discussion more than anything else (unless > > there is a matematician amongst us) > > > Yes, good suggestions. I'll add it to the next meeting (March 25:th). > And now that I think of it... there is this big OCALL contribution that has been mostly stalled for months... https://github.com/OP-TEE/optee_os/pull/3673 We should discuss what to do with it. Regards, -- Jerome

5 years, 3 months

1
0
0 0

Re: Linaro OP-TEE Contributions meeting February 2021

by Jorge Ramirez

Sorry Joakim. I guess it is too late now but It would have been good to talk about the TEE strategy/direction with RNG. 1) how often do we seed the PRNG. 2) should we always use PRNG and only use HWRNG to seed if with a certain cadence. 3) how do we measure the quality of an RNG in OPTEE (how do we guarantee no regressions) this would be really an open discussion more than anything else (unless there is a matematician amongst us) On Wed, Feb 24, 2021 at 9:18 AM Joakim Bech via OP-TEE < op-tee(a)lists.trustedfirmware.org> wrote: > Hi, > > Haven't received any suggestions for topics to discuss, so no agenda. No > agenda means no meeting and therefore I'm cancelling the LOC meeting that > was scheduled for tomorrow. > > Regards, > Joakim > > > On Wed, 17 Feb 2021 at 15:47, Joakim Bech <joakim.bech(a)linaro.org> wrote: > > > 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 > > >

5 years, 3 months

2
1
0 0

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

5 years, 3 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

5 years, 3 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

5 years, 3 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

5 years, 4 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.

5 years, 4 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

5 years, 4 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

5 years, 4 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

5 years, 4 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(-)

5 years, 4 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

5 years, 4 months

2
1
0 0

[PATCH] optee: simplify i2c access

by Arnd Bergmann

From: Arnd Bergmann <arnd(a)arndb.de> Storing a bogus i2c_client structure on the stack adds overhead and causes a compile-time warning: drivers/tee/optee/rpc.c:493:6: error: stack frame size of 1056 bytes in function 'optee_handle_rpc' [-Werror,-Wframe-larger-than=] void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, Change the implementation of handle_rpc_func_cmd_i2c_transfer() to open-code the i2c_transfer() call, which makes it easier to read and avoids the warning. Fixes: c05210ab9757 ("drivers: optee: allow op-tee to access devices on the i2c bus") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/tee/optee/rpc.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c index 1e3614e4798f..6cbb3643c6c4 100644 --- a/drivers/tee/optee/rpc.c +++ b/drivers/tee/optee/rpc.c @@ -54,8 +54,9 @@ static void handle_rpc_func_cmd_get_time(struct optee_msg_arg *arg) static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, struct optee_msg_arg *arg) { - struct i2c_client client = { 0 }; struct tee_param *params; + struct i2c_adapter *adapter; + struct i2c_msg msg = { }; size_t i; int ret = -EOPNOTSUPP; u8 attr[] = { @@ -85,48 +86,48 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, goto bad; } - client.adapter = i2c_get_adapter(params[0].u.value.b); - if (!client.adapter) + adapter = i2c_get_adapter(params[0].u.value.b); + if (!adapter) goto bad; if (params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT) { - if (!i2c_check_functionality(client.adapter, + if (!i2c_check_functionality(adapter, I2C_FUNC_10BIT_ADDR)) { - i2c_put_adapter(client.adapter); + i2c_put_adapter(adapter); goto bad; } - client.flags = I2C_CLIENT_TEN; + msg.flags = I2C_M_TEN; } - client.addr = params[0].u.value.c; - snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr); + msg.addr = params[0].u.value.c; + msg.buf = params[2].u.memref.shm->kaddr; + msg.len = params[2].u.memref.size; switch (params[0].u.value.a) { case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD: - ret = i2c_master_recv(&client, params[2].u.memref.shm->kaddr, - params[2].u.memref.size); + msg.flags |= I2C_M_RD; break; case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR: - ret = i2c_master_send(&client, params[2].u.memref.shm->kaddr, - params[2].u.memref.size); break; default: - i2c_put_adapter(client.adapter); + i2c_put_adapter(adapter); goto bad; } + ret = i2c_transfer(adapter, &msg, 1); + if (ret < 0) { arg->ret = TEEC_ERROR_COMMUNICATION; } else { - params[3].u.value.a = ret; + params[3].u.value.a = msg.len; if (optee_to_msg_param(arg->params, arg->num_params, params)) arg->ret = TEEC_ERROR_BAD_PARAMETERS; else arg->ret = TEEC_SUCCESS; } - i2c_put_adapter(client.adapter); + i2c_put_adapter(adapter); kfree(params); return; bad: -- 2.29.2

5 years, 4 months

3
9
0 0

[GIT PULL] TEE housekeeping for v5.12

by Jens Wiklander

Hello arm-soc maintainers, Please pull these patches fixing some comment typos and also a larger patch syncing some internal OP-TEE driver headers with OP-TEE OS. 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/tee-housekeeping-for-v5.12 for you to fetch changes up to 617d8e8b347edcee6da38df0aeb671fc9c9ba19c: optee: sync OP-TEE headers (2021-02-02 14:50:41 +0100) ---------------------------------------------------------------- TEE subsystem housekeeping - Fixes some comment typos in header files - Updates to use flexible-array member instead of zero-length array - Syncs internal OP-TEE headers with the ones from OP-TEE OS ---------------------------------------------------------------- Bjorn Helgaas (1): tee: optee: fix 'physical' typos Elvira Khabirova (1): tee: fix some comment typos in header files Jens Wiklander (1): optee: sync OP-TEE headers Tian Tao (1): drivers: optee: use flexible-array member instead of zero-length array drivers/tee/optee/optee_msg.h | 158 +++----------------------------------- drivers/tee/optee/optee_rpc_cmd.h | 103 +++++++++++++++++++++++++ drivers/tee/optee/optee_smc.h | 72 +++++++++++------ drivers/tee/optee/rpc.c | 39 +++++----- include/linux/tee_drv.h | 2 +- include/uapi/linux/tee.h | 2 +- 6 files changed, 183 insertions(+), 193 deletions(-) create mode 100644 drivers/tee/optee/optee_rpc_cmd.h

5 years, 4 months

2
1
0 0

[GIT PULL] OP-TEE fix for v5.12

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small fix removing an unnecessary call to need_resched() before cond_resched() while the OP-TEE driver is handing a RPC. 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-fix-cond-resched-call-for-v5.12 for you to fetch changes up to 958567600517fd15b7f35ca1a8be0104f0eb0686: tee: optee: remove need_resched() before cond_resched() (2021-02-03 08:11:11 +0100) ---------------------------------------------------------------- Remove unnecessary need_resched() before cond_resched() ---------------------------------------------------------------- Jens Wiklander (1): tee: optee: remove need_resched() before cond_resched() Rouven Czerwinski (1): tee: optee: replace might_sleep with cond_resched drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

5 years, 4 months

2
1
0 0

[PATCH] 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> --- 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

5 years, 4 months

2
1
0 0

[PATCH] tee: fix some comment typos in header files

by Elvira Khabirova

struct tee_param: revc -> recv. TEE_IOC_SUPPL_SEND: typo introduced by copy-pasting, replace invalid description with description from the according argument struct. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- include/linux/tee_drv.h | 2 +- include/uapi/linux/tee.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index d074302989dd..61557bc0e29f 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -85,7 +85,7 @@ struct tee_param { * @close_session: close a session * @invoke_func: invoke a trusted function * @cancel_req: request cancel of an ongoing invoke or open - * @supp_revc: called for supplicant to get a command + * @supp_recv: called for supplicant to get a command * @supp_send: called for supplicant to send a response * @shm_register: register shared memory buffer in TEE * @shm_unregister: unregister shared memory buffer in TEE diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h index b619f37ee03e..7546be5ed4f8 100644 --- a/include/uapi/linux/tee.h +++ b/include/uapi/linux/tee.h @@ -342,7 +342,7 @@ struct tee_iocl_supp_send_arg { }; /** - * TEE_IOC_SUPPL_SEND - Receive a request for a supplicant function + * TEE_IOC_SUPPL_SEND - Send a response to a received request * * Takes a struct tee_ioctl_buf_data which contains a struct * tee_iocl_supp_send_arg followed by any array of struct tee_param -- 2.28.0

5 years, 4 months

3
2
0 0

[PATCH] tee: optee: fix 'physical' typos

by Bjorn Helgaas

From: Bjorn Helgaas <bhelgaas(a)google.com> Fix misspellings of "physical". Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> --- drivers/tee/optee/optee_smc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 777ad54d4c2c..b52eb34b4237 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -139,7 +139,7 @@ struct optee_smc_call_get_os_revision_result { * optee_msg_arg. * OPTEE_SMC_RETURN_ETHREAD_LIMIT Number of Trusted OS threads exceeded, * try again later. - * OPTEE_SMC_RETURN_EBADADDR Bad physcial pointer to struct + * OPTEE_SMC_RETURN_EBADADDR Bad physical pointer to struct * optee_msg_arg. * OPTEE_SMC_RETURN_EBADCMD Bad/unknown cmd in struct optee_msg_arg * OPTEE_SMC_RETURN_IS_RPC() Call suspended by RPC call to normal -- 2.25.1

5 years, 4 months

2
1
0 0

Re: [PATCH] tee: optee: remove need_resched() before cond_resched()

by Jens Wiklander

Hi Rouven and Sumit, On Mon, Jan 25, 2021 at 10:58 AM Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hi Rouven and Sumit, > > On Mon, Jan 25, 2021 at 10:55 AM Jens Wiklander > <jens.wiklander(a)linaro.org> wrote: > > > > Testing need_resched() before cond_resched() is not needed as an > > equivalent test is done internally in cond_resched(). So drop the > > need_resched() test. > > > > Fixes: dcb3b06d9c34 ("tee: optee: replace might_sleep with cond_resched") > > Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> > > --- > > drivers/tee/optee/call.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > Can you please test to see that this works in your setups too? Does this work for you? I'd like to get this patch ready for v5.12. Thanks, Jens

5 years, 4 months

3
4
0 0

Re: [PATCH] optee: sync OP-TEE headers

by Sumit Garg

On Fri, 29 Jan 2021 at 19:13, Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Pulls in updates in the internal headers from OP-TEE OS [1]. A few > defines has been shortened, hence the changes in rpc.c. Defines not used > by the driver in tee_rpc_cmd.h has been filtered out. > > Note that this does not change the ABI. > > Link: [1] https://github.com/OP-TEE/optee_os > Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> > --- > drivers/tee/optee/optee_msg.h | 154 ++---------------------------- > drivers/tee/optee/optee_rpc_cmd.h | 103 ++++++++++++++++++++ > drivers/tee/optee/optee_smc.h | 70 +++++++++----- > drivers/tee/optee/rpc.c | 39 ++++---- > 4 files changed, 178 insertions(+), 188 deletions(-) > create mode 100644 drivers/tee/optee/optee_rpc_cmd.h > Looks good to me apart from the minor nit below. Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> > diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h > index 7b2d919da2ac..7c4723b66668 100644 > --- a/drivers/tee/optee/optee_msg.h > +++ b/drivers/tee/optee/optee_msg.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */ > /* > - * Copyright (c) 2015-2019, Linaro Limited > + * Copyright (c) 2015-2021, Linaro Limited > */ > #ifndef _OPTEE_MSG_H > #define _OPTEE_MSG_H > @@ -12,11 +12,9 @@ > * This file defines the OP-TEE message protocol used to communicate > * with an instance of OP-TEE running in secure world. > * > - * This file is divided into three sections. > + * This file is divided into two sections. > * 1. Formatting of messages. > * 2. Requests from normal world > - * 3. Requests from secure world, Remote Procedure Call (RPC), handled by > - * tee-supplicant. > */ > > /***************************************************************************** > @@ -54,8 +52,8 @@ > * Every entry in buffer should point to a 4k page beginning (12 least > * significant bits must be equal to zero). > * > - * 12 least significant bints of optee_msg_param.u.tmem.buf_ptr should hold page > - * offset of the user buffer. > + * 12 least significant bits of optee_msg_param.u.tmem.buf_ptr should hold > + * page offset of user buffer. > * > * So, entries should be placed like members of this structure: > * > @@ -176,17 +174,9 @@ struct optee_msg_param { > * @params: the parameters supplied to the OS Command > * > * All normal calls to Trusted OS uses this struct. If cmd requires further > - * information than what these field holds it can be passed as a parameter > + * information than what these fields hold it can be passed as a parameter > * tagged as meta (setting the OPTEE_MSG_ATTR_META bit in corresponding > - * attrs field). All parameters tagged as meta has to come first. > - * > - * Temp memref parameters can be fragmented if supported by the Trusted OS > - * (when optee_smc.h is bearer of this protocol this is indicated with > - * OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM). If a logical memref parameter is > - * fragmented then has all but the last fragment the > - * OPTEE_MSG_ATTR_FRAGMENT bit set in attrs. Even if a memref is fragmented > - * it will still be presented as a single logical memref to the Trusted > - * Application. > + * attrs field). All parameters tagged as meta have to come first. > */ > struct optee_msg_arg { > u32 cmd; > @@ -290,13 +280,10 @@ struct optee_msg_arg { > * OPTEE_MSG_CMD_REGISTER_SHM registers a shared memory reference. The > * information is passed as: > * [in] param[0].attr OPTEE_MSG_ATTR_TYPE_TMEM_INPUT > - * [| OPTEE_MSG_ATTR_FRAGMENT] > + * [| OPTEE_MSG_ATTR_NONCONTIG] > * [in] param[0].u.tmem.buf_ptr physical address (of first fragment) > * [in] param[0].u.tmem.size size (of first fragment) > * [in] param[0].u.tmem.shm_ref holds shared memory reference > - * ... > - * The shared memory can optionally be fragmented, temp memrefs can follow > - * each other with all but the last with the OPTEE_MSG_ATTR_FRAGMENT bit set. > * > * OPTEE_MSG_CMD_UNREGISTER_SHM unregisteres a previously registered shared nit: since you are touching this file, s/unregisteres/unregisters/ -Sumit > * memory reference. The information is passed as: > @@ -313,131 +300,4 @@ struct optee_msg_arg { > #define OPTEE_MSG_CMD_UNREGISTER_SHM 5 > #define OPTEE_MSG_FUNCID_CALL_WITH_ARG 0x0004 > > -/***************************************************************************** > - * Part 3 - Requests from secure world, RPC > - *****************************************************************************/ > - > -/* > - * All RPC is done with a struct optee_msg_arg as bearer of information, > - * struct optee_msg_arg::arg holds values defined by OPTEE_MSG_RPC_CMD_* below > - * > - * RPC communication with tee-supplicant is reversed compared to normal > - * client communication desribed above. The supplicant receives requests > - * and sends responses. > - */ > - > -/* > - * Load a TA into memory, defined in tee-supplicant > - */ > -#define OPTEE_MSG_RPC_CMD_LOAD_TA 0 > - > -/* > - * Reserved > - */ > -#define OPTEE_MSG_RPC_CMD_RPMB 1 > - > -/* > - * File system access, defined in tee-supplicant > - */ > -#define OPTEE_MSG_RPC_CMD_FS 2 > - > -/* > - * Get time > - * > - * Returns number of seconds and nano seconds since the Epoch, > - * 1970-01-01 00:00:00 +0000 (UTC). > - * > - * [out] param[0].u.value.a Number of seconds > - * [out] param[0].u.value.b Number of nano seconds. > - */ > -#define OPTEE_MSG_RPC_CMD_GET_TIME 3 > - > -/* > - * Wait queue primitive, helper for secure world to implement a wait queue. > - * > - * If secure world need to wait for a secure world mutex it issues a sleep > - * request instead of spinning in secure world. Conversely is a wakeup > - * request issued when a secure world mutex with a thread waiting thread is > - * unlocked. > - * > - * Waiting on a key > - * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP > - * [in] param[0].u.value.b wait key > - * > - * Waking up a key > - * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP > - * [in] param[0].u.value.b wakeup key > - */ > -#define OPTEE_MSG_RPC_CMD_WAIT_QUEUE 4 > -#define OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP 0 > -#define OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP 1 > - > -/* > - * Suspend execution > - * > - * [in] param[0].value .a number of milliseconds to suspend > - */ > -#define OPTEE_MSG_RPC_CMD_SUSPEND 5 > - > -/* > - * Allocate a piece of shared memory > - * > - * Shared memory can optionally be fragmented, to support that additional > - * spare param entries are allocated to make room for eventual fragments. > - * The spare param entries has .attr = OPTEE_MSG_ATTR_TYPE_NONE when > - * unused. All returned temp memrefs except the last should have the > - * OPTEE_MSG_ATTR_FRAGMENT bit set in the attr field. > - * > - * [in] param[0].u.value.a type of memory one of > - * OPTEE_MSG_RPC_SHM_TYPE_* below > - * [in] param[0].u.value.b requested size > - * [in] param[0].u.value.c required alignment > - * > - * [out] param[0].u.tmem.buf_ptr physical address (of first fragment) > - * [out] param[0].u.tmem.size size (of first fragment) > - * [out] param[0].u.tmem.shm_ref shared memory reference > - * ... > - * [out] param[n].u.tmem.buf_ptr physical address > - * [out] param[n].u.tmem.size size > - * [out] param[n].u.tmem.shm_ref shared memory reference (same value > - * as in param[n-1].u.tmem.shm_ref) > - */ > -#define OPTEE_MSG_RPC_CMD_SHM_ALLOC 6 > -/* Memory that can be shared with a non-secure user space application */ > -#define OPTEE_MSG_RPC_SHM_TYPE_APPL 0 > -/* Memory only shared with non-secure kernel */ > -#define OPTEE_MSG_RPC_SHM_TYPE_KERNEL 1 > - > -/* > - * Free shared memory previously allocated with OPTEE_MSG_RPC_CMD_SHM_ALLOC > - * > - * [in] param[0].u.value.a type of memory one of > - * OPTEE_MSG_RPC_SHM_TYPE_* above > - * [in] param[0].u.value.b value of shared memory reference > - * returned in param[0].u.tmem.shm_ref > - * above > - */ > -#define OPTEE_MSG_RPC_CMD_SHM_FREE 7 > - > -/* > - * Access a device on an i2c bus > - * > - * [in] param[0].u.value.a mode: RD(0), WR(1) > - * [in] param[0].u.value.b i2c adapter > - * [in] param[0].u.value.c i2c chip > - * > - * [in] param[1].u.value.a i2c control flags > - * > - * [in/out] memref[2] buffer to exchange the transfer data > - * with the secure world > - * > - * [out] param[3].u.value.a bytes transferred by the driver > - */ > -#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER 21 > -/* I2C master transfer modes */ > -#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD 0 > -#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR 1 > -/* I2C master control flags */ > -#define OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT BIT(0) > - > #endif /* _OPTEE_MSG_H */ > diff --git a/drivers/tee/optee/optee_rpc_cmd.h b/drivers/tee/optee/optee_rpc_cmd.h > new file mode 100644 > index 000000000000..b8275140cef8 > --- /dev/null > +++ b/drivers/tee/optee/optee_rpc_cmd.h > @@ -0,0 +1,103 @@ > +/* SPDX-License-Identifier: BSD-2-Clause */ > +/* > + * Copyright (c) 2016-2021, Linaro Limited > + */ > + > +#ifndef __OPTEE_RPC_CMD_H > +#define __OPTEE_RPC_CMD_H > + > +/* > + * All RPC is done with a struct optee_msg_arg as bearer of information, > + * struct optee_msg_arg::arg holds values defined by OPTEE_RPC_CMD_* below. > + * Only the commands handled by the kernel driver are defined here. > + * > + * RPC communication with tee-supplicant is reversed compared to normal > + * client communication described above. The supplicant receives requests > + * and sends responses. > + */ > + > +/* > + * Get time > + * > + * Returns number of seconds and nano seconds since the Epoch, > + * 1970-01-01 00:00:00 +0000 (UTC). > + * > + * [out] value[0].a Number of seconds > + * [out] value[0].b Number of nano seconds. > + */ > +#define OPTEE_RPC_CMD_GET_TIME 3 > + > +/* > + * Wait queue primitive, helper for secure world to implement a wait queue. > + * > + * If secure world needs to wait for a secure world mutex it issues a sleep > + * request instead of spinning in secure world. Conversely is a wakeup > + * request issued when a secure world mutex with a thread waiting thread is > + * unlocked. > + * > + * Waiting on a key > + * [in] value[0].a OPTEE_RPC_WAIT_QUEUE_SLEEP > + * [in] value[0].b Wait key > + * > + * Waking up a key > + * [in] value[0].a OPTEE_RPC_WAIT_QUEUE_WAKEUP > + * [in] value[0].b Wakeup key > + */ > +#define OPTEE_RPC_CMD_WAIT_QUEUE 4 > +#define OPTEE_RPC_WAIT_QUEUE_SLEEP 0 > +#define OPTEE_RPC_WAIT_QUEUE_WAKEUP 1 > + > +/* > + * Suspend execution > + * > + * [in] value[0].a Number of milliseconds to suspend > + */ > +#define OPTEE_RPC_CMD_SUSPEND 5 > + > +/* > + * Allocate a piece of shared memory > + * > + * [in] value[0].a Type of memory one of > + * OPTEE_RPC_SHM_TYPE_* below > + * [in] value[0].b Requested size > + * [in] value[0].c Required alignment > + * [out] memref[0] Buffer > + */ > +#define OPTEE_RPC_CMD_SHM_ALLOC 6 > +/* Memory that can be shared with a non-secure user space application */ > +#define OPTEE_RPC_SHM_TYPE_APPL 0 > +/* Memory only shared with non-secure kernel */ > +#define OPTEE_RPC_SHM_TYPE_KERNEL 1 > + > +/* > + * Free shared memory previously allocated with OPTEE_RPC_CMD_SHM_ALLOC > + * > + * [in] value[0].a Type of memory one of > + * OPTEE_RPC_SHM_TYPE_* above > + * [in] value[0].b Value of shared memory reference or cookie > + */ > +#define OPTEE_RPC_CMD_SHM_FREE 7 > + > +/* > + * Issue master requests (read and write operations) to an I2C chip. > + * > + * [in] value[0].a Transfer mode (OPTEE_RPC_I2C_TRANSFER_*) > + * [in] value[0].b The I2C bus (a.k.a adapter). > + * 16 bit field. > + * [in] value[0].c The I2C chip (a.k.a address). > + * 16 bit field (either 7 or 10 bit effective). > + * [in] value[1].a The I2C master control flags (ie, 10 bit address). > + * 16 bit field. > + * [in/out] memref[2] Buffer used for data transfers. > + * [out] value[3].a Number of bytes transferred by the REE. > + */ > +#define OPTEE_RPC_CMD_I2C_TRANSFER 21 > + > +/* I2C master transfer modes */ > +#define OPTEE_RPC_I2C_TRANSFER_RD 0 > +#define OPTEE_RPC_I2C_TRANSFER_WR 1 > + > +/* I2C master control flags */ > +#define OPTEE_RPC_I2C_FLAGS_TEN_BIT BIT(0) > + > +#endif /*__OPTEE_RPC_CMD_H*/ > diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h > index 777ad54d4c2c..821e1c30c150 100644 > --- a/drivers/tee/optee/optee_smc.h > +++ b/drivers/tee/optee/optee_smc.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */ > /* > - * Copyright (c) 2015-2019, Linaro Limited > + * Copyright (c) 2015-2021, Linaro Limited > */ > #ifndef OPTEE_SMC_H > #define OPTEE_SMC_H > @@ -39,10 +39,10 @@ > /* > * Function specified by SMC Calling convention > * > - * Return one of the following UIDs if using API specified in this file > - * without further extentions: > - * 65cb6b93-af0c-4617-8ed6-644a8d1140f8 > - * see also OPTEE_SMC_UID_* in optee_msg.h > + * Return the following UID if using API specified in this file > + * without further extensions: > + * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. > + * see also OPTEE_MSG_UID_* in optee_msg.h > */ > #define OPTEE_SMC_FUNCID_CALLS_UID OPTEE_MSG_FUNCID_CALLS_UID > #define OPTEE_SMC_CALLS_UID \ > @@ -53,7 +53,7 @@ > /* > * Function specified by SMC Calling convention > * > - * Returns 2.0 if using API specified in this file without further extentions. > + * Returns 2.0 if using API specified in this file without further extensions. > * see also OPTEE_MSG_REVISION_* in optee_msg.h > */ > #define OPTEE_SMC_FUNCID_CALLS_REVISION OPTEE_MSG_FUNCID_CALLS_REVISION > @@ -109,8 +109,8 @@ struct optee_smc_call_get_os_revision_result { > * > * Call register usage: > * a0 SMC Function ID, OPTEE_SMC*CALL_WITH_ARG > - * a1 Upper 32bit of a 64bit physical pointer to a struct optee_msg_arg > - * a2 Lower 32bit of a 64bit physical pointer to a struct optee_msg_arg > + * a1 Upper 32 bits of a 64-bit physical pointer to a struct optee_msg_arg > + * a2 Lower 32 bits of a 64-bit physical pointer to a struct optee_msg_arg > * a3 Cache settings, not used if physical pointer is in a predefined shared > * memory area else per OPTEE_SMC_SHM_* > * a4-6 Not used > @@ -214,8 +214,9 @@ struct optee_smc_get_shm_config_result { > * secure world accepts command buffers located in any parts of non-secure RAM > */ > #define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM BIT(2) > - > -/* Secure world supports Shared Memory with a NULL buffer reference */ > +/* Secure world is built with virtualization support */ > +#define OPTEE_SMC_SEC_CAP_VIRTUALIZATION BIT(3) > +/* Secure world supports Shared Memory with a NULL reference */ > #define OPTEE_SMC_SEC_CAP_MEMREF_NULL BIT(4) > > #define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9 > @@ -245,8 +246,8 @@ struct optee_smc_exchange_capabilities_result { > * > * Normal return register usage: > * a0 OPTEE_SMC_RETURN_OK > - * a1 Upper 32bit of a 64bit Shared memory cookie > - * a2 Lower 32bit of a 64bit Shared memory cookie > + * a1 Upper 32 bits of a 64-bit Shared memory cookie > + * a2 Lower 32 bits of a 64-bit Shared memory cookie > * a3-7 Preserved > * > * Cache empty return register usage: > @@ -293,6 +294,31 @@ struct optee_smc_disable_shm_cache_result { > #define OPTEE_SMC_ENABLE_SHM_CACHE \ > OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE) > > +/* > + * Query OP-TEE about number of supported threads > + * > + * Normal World OS or Hypervisor issues this call to find out how many > + * threads OP-TEE supports. That is how many standard calls can be issued > + * in parallel before OP-TEE will return OPTEE_SMC_RETURN_ETHREAD_LIMIT. > + * > + * Call requests usage: > + * a0 SMC Function ID, OPTEE_SMC_GET_THREAD_COUNT > + * a1-6 Not used > + * a7 Hypervisor Client ID register > + * > + * Normal return register usage: > + * a0 OPTEE_SMC_RETURN_OK > + * a1 Number of threads > + * a2-7 Preserved > + * > + * Error return: > + * a0 OPTEE_SMC_RETURN_UNKNOWN_FUNCTION Requested call is not implemented > + * a1-7 Preserved > + */ > +#define OPTEE_SMC_FUNCID_GET_THREAD_COUNT 15 > +#define OPTEE_SMC_GET_THREAD_COUNT \ > + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_THREAD_COUNT) > + > /* > * Resume from RPC (for example after processing a foreign interrupt) > * > @@ -341,16 +367,16 @@ struct optee_smc_disable_shm_cache_result { > * > * "Return" register usage: > * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. > - * a1 Upper 32bits of 64bit physical pointer to allocated > + * a1 Upper 32 bits of 64-bit physical pointer to allocated > * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't > * be allocated. > - * a2 Lower 32bits of 64bit physical pointer to allocated > + * a2 Lower 32 bits of 64-bit physical pointer to allocated > * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't > * be allocated > * a3 Preserved > - * a4 Upper 32bits of 64bit Shared memory cookie used when freeing > + * a4 Upper 32 bits of 64-bit Shared memory cookie used when freeing > * the memory or doing an RPC > - * a5 Lower 32bits of 64bit Shared memory cookie used when freeing > + * a5 Lower 32 bits of 64-bit Shared memory cookie used when freeing > * the memory or doing an RPC > * a6-7 Preserved > */ > @@ -363,9 +389,9 @@ struct optee_smc_disable_shm_cache_result { > * > * "Call" register usage: > * a0 This value, OPTEE_SMC_RETURN_RPC_FREE > - * a1 Upper 32bits of 64bit shared memory cookie belonging to this > + * a1 Upper 32 bits of 64-bit shared memory cookie belonging to this > * argument memory > - * a2 Lower 32bits of 64bit shared memory cookie belonging to this > + * a2 Lower 32 bits of 64-bit shared memory cookie belonging to this > * argument memory > * a3-7 Resume information, must be preserved > * > @@ -379,7 +405,7 @@ struct optee_smc_disable_shm_cache_result { > OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FREE) > > /* > - * Deliver foreign interrupt to normal world. > + * Deliver a foreign interrupt in normal world. > * > * "Call" register usage: > * a0 OPTEE_SMC_RETURN_RPC_FOREIGN_INTR > @@ -389,7 +415,7 @@ struct optee_smc_disable_shm_cache_result { > * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. > * a1-7 Preserved > */ > -#define OPTEE_SMC_RPC_FUNC_FOREIGN_INTR 4 > +#define OPTEE_SMC_RPC_FUNC_FOREIGN_INTR 4 > #define OPTEE_SMC_RETURN_RPC_FOREIGN_INTR \ > OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FOREIGN_INTR) > > @@ -405,10 +431,10 @@ struct optee_smc_disable_shm_cache_result { > * > * "Call" register usage: > * a0 OPTEE_SMC_RETURN_RPC_CMD > - * a1 Upper 32bit of a 64bit Shared memory cookie holding a > + * a1 Upper 32 bits of a 64-bit Shared memory cookie holding a > * struct optee_msg_arg, must be preserved, only the data should > * be updated > - * a2 Lower 32bit of a 64bit Shared memory cookie holding a > + * a2 Lower 32 bits of a 64-bit Shared memory cookie holding a > * struct optee_msg_arg, must be preserved, only the data should > * be updated > * a3-7 Resume information, must be preserved > diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c > index 1e3614e4798f..a0c30b664e53 100644 > --- a/drivers/tee/optee/rpc.c > +++ b/drivers/tee/optee/rpc.c > @@ -12,6 +12,7 @@ > #include <linux/tee_drv.h> > #include "optee_private.h" > #include "optee_smc.h" > +#include "optee_rpc_cmd.h" > > struct wq_entry { > struct list_head link; > @@ -89,7 +90,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, > if (!client.adapter) > goto bad; > > - if (params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT) { > + if (params[1].u.value.a & OPTEE_RPC_I2C_FLAGS_TEN_BIT) { > if (!i2c_check_functionality(client.adapter, > I2C_FUNC_10BIT_ADDR)) { > i2c_put_adapter(client.adapter); > @@ -103,11 +104,11 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, > snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr); > > switch (params[0].u.value.a) { > - case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD: > + case OPTEE_RPC_I2C_TRANSFER_RD: > ret = i2c_master_recv(&client, params[2].u.memref.shm->kaddr, > params[2].u.memref.size); > break; > - case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR: > + case OPTEE_RPC_I2C_TRANSFER_WR: > ret = i2c_master_send(&client, params[2].u.memref.shm->kaddr, > params[2].u.memref.size); > break; > @@ -194,10 +195,10 @@ static void handle_rpc_func_cmd_wq(struct optee *optee, > goto bad; > > switch (arg->params[0].u.value.a) { > - case OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP: > + case OPTEE_RPC_WAIT_QUEUE_SLEEP: > wq_sleep(&optee->wait_queue, arg->params[0].u.value.b); > break; > - case OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP: > + case OPTEE_RPC_WAIT_QUEUE_WAKEUP: > wq_wakeup(&optee->wait_queue, arg->params[0].u.value.b); > break; > default: > @@ -267,11 +268,11 @@ static struct tee_shm *cmd_alloc_suppl(struct tee_context *ctx, size_t sz) > struct tee_shm *shm; > > param.attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT; > - param.u.value.a = OPTEE_MSG_RPC_SHM_TYPE_APPL; > + param.u.value.a = OPTEE_RPC_SHM_TYPE_APPL; > param.u.value.b = sz; > param.u.value.c = 0; > > - ret = optee_supp_thrd_req(ctx, OPTEE_MSG_RPC_CMD_SHM_ALLOC, 1, &param); > + ret = optee_supp_thrd_req(ctx, OPTEE_RPC_CMD_SHM_ALLOC, 1, &param); > if (ret) > return ERR_PTR(-ENOMEM); > > @@ -308,10 +309,10 @@ static void handle_rpc_func_cmd_shm_alloc(struct tee_context *ctx, > > sz = arg->params[0].u.value.b; > switch (arg->params[0].u.value.a) { > - case OPTEE_MSG_RPC_SHM_TYPE_APPL: > + case OPTEE_RPC_SHM_TYPE_APPL: > shm = cmd_alloc_suppl(ctx, sz); > break; > - case OPTEE_MSG_RPC_SHM_TYPE_KERNEL: > + case OPTEE_RPC_SHM_TYPE_KERNEL: > shm = tee_shm_alloc(ctx, sz, TEE_SHM_MAPPED); > break; > default: > @@ -383,7 +384,7 @@ static void cmd_free_suppl(struct tee_context *ctx, struct tee_shm *shm) > struct tee_param param; > > param.attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT; > - param.u.value.a = OPTEE_MSG_RPC_SHM_TYPE_APPL; > + param.u.value.a = OPTEE_RPC_SHM_TYPE_APPL; > param.u.value.b = tee_shm_get_id(shm); > param.u.value.c = 0; > > @@ -400,7 +401,7 @@ static void cmd_free_suppl(struct tee_context *ctx, struct tee_shm *shm) > */ > tee_shm_put(shm); > > - optee_supp_thrd_req(ctx, OPTEE_MSG_RPC_CMD_SHM_FREE, 1, &param); > + optee_supp_thrd_req(ctx, OPTEE_RPC_CMD_SHM_FREE, 1, &param); > } > > static void handle_rpc_func_cmd_shm_free(struct tee_context *ctx, > @@ -418,10 +419,10 @@ static void handle_rpc_func_cmd_shm_free(struct tee_context *ctx, > > shm = (struct tee_shm *)(unsigned long)arg->params[0].u.value.b; > switch (arg->params[0].u.value.a) { > - case OPTEE_MSG_RPC_SHM_TYPE_APPL: > + case OPTEE_RPC_SHM_TYPE_APPL: > cmd_free_suppl(ctx, shm); > break; > - case OPTEE_MSG_RPC_SHM_TYPE_KERNEL: > + case OPTEE_RPC_SHM_TYPE_KERNEL: > tee_shm_free(shm); > break; > default: > @@ -458,23 +459,23 @@ static void handle_rpc_func_cmd(struct tee_context *ctx, struct optee *optee, > } > > switch (arg->cmd) { > - case OPTEE_MSG_RPC_CMD_GET_TIME: > + case OPTEE_RPC_CMD_GET_TIME: > handle_rpc_func_cmd_get_time(arg); > break; > - case OPTEE_MSG_RPC_CMD_WAIT_QUEUE: > + case OPTEE_RPC_CMD_WAIT_QUEUE: > handle_rpc_func_cmd_wq(optee, arg); > break; > - case OPTEE_MSG_RPC_CMD_SUSPEND: > + case OPTEE_RPC_CMD_SUSPEND: > handle_rpc_func_cmd_wait(arg); > break; > - case OPTEE_MSG_RPC_CMD_SHM_ALLOC: > + case OPTEE_RPC_CMD_SHM_ALLOC: > free_pages_list(call_ctx); > handle_rpc_func_cmd_shm_alloc(ctx, arg, call_ctx); > break; > - case OPTEE_MSG_RPC_CMD_SHM_FREE: > + case OPTEE_RPC_CMD_SHM_FREE: > handle_rpc_func_cmd_shm_free(ctx, arg); > break; > - case OPTEE_MSG_RPC_CMD_I2C_TRANSFER: > + case OPTEE_RPC_CMD_I2C_TRANSFER: > handle_rpc_func_cmd_i2c_transfer(ctx, arg); > break; > default: > -- > 2.25.1 >

5 years, 4 months

2
1
0 0

[PATCH] tee: optee: remove need_resched() before cond_resched()

by Jens Wiklander

Testing need_resched() before cond_resched() is not needed as an equivalent test is done internally in cond_resched(). So drop the need_resched() test. Fixes: dcb3b06d9c34 ("tee: optee: replace might_sleep with cond_resched") Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/optee/call.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 780d7c4fd756..7a77e375b503 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -149,8 +149,7 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) */ optee_cq_wait_for_completion(&optee->call_queue, &w); } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) { - if (need_resched()) - cond_resched(); + cond_resched(); param.a0 = res.a0; param.a1 = res.a1; param.a2 = res.a2; -- 2.25.1

5 years, 4 months

2
2
0 0

[PATCH] optee: sync OP-TEE headers

by Jens Wiklander

Pulls in updates in the internal headers from OP-TEE OS [1]. A few defines has been shortened, hence the changes in rpc.c. Defines not used by the driver in tee_rpc_cmd.h has been filtered out. Note that this does not change the ABI. Link: [1] https://github.com/OP-TEE/optee_os Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/optee/optee_msg.h | 154 ++---------------------------- drivers/tee/optee/optee_rpc_cmd.h | 103 ++++++++++++++++++++ drivers/tee/optee/optee_smc.h | 70 +++++++++----- drivers/tee/optee/rpc.c | 39 ++++---- 4 files changed, 178 insertions(+), 188 deletions(-) create mode 100644 drivers/tee/optee/optee_rpc_cmd.h diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 7b2d919da2ac..7c4723b66668 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */ /* - * Copyright (c) 2015-2019, Linaro Limited + * Copyright (c) 2015-2021, Linaro Limited */ #ifndef _OPTEE_MSG_H #define _OPTEE_MSG_H @@ -12,11 +12,9 @@ * This file defines the OP-TEE message protocol used to communicate * with an instance of OP-TEE running in secure world. * - * This file is divided into three sections. + * This file is divided into two sections. * 1. Formatting of messages. * 2. Requests from normal world - * 3. Requests from secure world, Remote Procedure Call (RPC), handled by - * tee-supplicant. */ /***************************************************************************** @@ -54,8 +52,8 @@ * Every entry in buffer should point to a 4k page beginning (12 least * significant bits must be equal to zero). * - * 12 least significant bints of optee_msg_param.u.tmem.buf_ptr should hold page - * offset of the user buffer. + * 12 least significant bits of optee_msg_param.u.tmem.buf_ptr should hold + * page offset of user buffer. * * So, entries should be placed like members of this structure: * @@ -176,17 +174,9 @@ struct optee_msg_param { * @params: the parameters supplied to the OS Command * * All normal calls to Trusted OS uses this struct. If cmd requires further - * information than what these field holds it can be passed as a parameter + * information than what these fields hold it can be passed as a parameter * tagged as meta (setting the OPTEE_MSG_ATTR_META bit in corresponding - * attrs field). All parameters tagged as meta has to come first. - * - * Temp memref parameters can be fragmented if supported by the Trusted OS - * (when optee_smc.h is bearer of this protocol this is indicated with - * OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM). If a logical memref parameter is - * fragmented then has all but the last fragment the - * OPTEE_MSG_ATTR_FRAGMENT bit set in attrs. Even if a memref is fragmented - * it will still be presented as a single logical memref to the Trusted - * Application. + * attrs field). All parameters tagged as meta have to come first. */ struct optee_msg_arg { u32 cmd; @@ -290,13 +280,10 @@ struct optee_msg_arg { * OPTEE_MSG_CMD_REGISTER_SHM registers a shared memory reference. The * information is passed as: * [in] param[0].attr OPTEE_MSG_ATTR_TYPE_TMEM_INPUT - * [| OPTEE_MSG_ATTR_FRAGMENT] + * [| OPTEE_MSG_ATTR_NONCONTIG] * [in] param[0].u.tmem.buf_ptr physical address (of first fragment) * [in] param[0].u.tmem.size size (of first fragment) * [in] param[0].u.tmem.shm_ref holds shared memory reference - * ... - * The shared memory can optionally be fragmented, temp memrefs can follow - * each other with all but the last with the OPTEE_MSG_ATTR_FRAGMENT bit set. * * OPTEE_MSG_CMD_UNREGISTER_SHM unregisteres a previously registered shared * memory reference. The information is passed as: @@ -313,131 +300,4 @@ struct optee_msg_arg { #define OPTEE_MSG_CMD_UNREGISTER_SHM 5 #define OPTEE_MSG_FUNCID_CALL_WITH_ARG 0x0004 -/***************************************************************************** - * Part 3 - Requests from secure world, RPC - *****************************************************************************/ - -/* - * All RPC is done with a struct optee_msg_arg as bearer of information, - * struct optee_msg_arg::arg holds values defined by OPTEE_MSG_RPC_CMD_* below - * - * RPC communication with tee-supplicant is reversed compared to normal - * client communication desribed above. The supplicant receives requests - * and sends responses. - */ - -/* - * Load a TA into memory, defined in tee-supplicant - */ -#define OPTEE_MSG_RPC_CMD_LOAD_TA 0 - -/* - * Reserved - */ -#define OPTEE_MSG_RPC_CMD_RPMB 1 - -/* - * File system access, defined in tee-supplicant - */ -#define OPTEE_MSG_RPC_CMD_FS 2 - -/* - * Get time - * - * Returns number of seconds and nano seconds since the Epoch, - * 1970-01-01 00:00:00 +0000 (UTC). - * - * [out] param[0].u.value.a Number of seconds - * [out] param[0].u.value.b Number of nano seconds. - */ -#define OPTEE_MSG_RPC_CMD_GET_TIME 3 - -/* - * Wait queue primitive, helper for secure world to implement a wait queue. - * - * If secure world need to wait for a secure world mutex it issues a sleep - * request instead of spinning in secure world. Conversely is a wakeup - * request issued when a secure world mutex with a thread waiting thread is - * unlocked. - * - * Waiting on a key - * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP - * [in] param[0].u.value.b wait key - * - * Waking up a key - * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP - * [in] param[0].u.value.b wakeup key - */ -#define OPTEE_MSG_RPC_CMD_WAIT_QUEUE 4 -#define OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP 0 -#define OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP 1 - -/* - * Suspend execution - * - * [in] param[0].value .a number of milliseconds to suspend - */ -#define OPTEE_MSG_RPC_CMD_SUSPEND 5 - -/* - * Allocate a piece of shared memory - * - * Shared memory can optionally be fragmented, to support that additional - * spare param entries are allocated to make room for eventual fragments. - * The spare param entries has .attr = OPTEE_MSG_ATTR_TYPE_NONE when - * unused. All returned temp memrefs except the last should have the - * OPTEE_MSG_ATTR_FRAGMENT bit set in the attr field. - * - * [in] param[0].u.value.a type of memory one of - * OPTEE_MSG_RPC_SHM_TYPE_* below - * [in] param[0].u.value.b requested size - * [in] param[0].u.value.c required alignment - * - * [out] param[0].u.tmem.buf_ptr physical address (of first fragment) - * [out] param[0].u.tmem.size size (of first fragment) - * [out] param[0].u.tmem.shm_ref shared memory reference - * ... - * [out] param[n].u.tmem.buf_ptr physical address - * [out] param[n].u.tmem.size size - * [out] param[n].u.tmem.shm_ref shared memory reference (same value - * as in param[n-1].u.tmem.shm_ref) - */ -#define OPTEE_MSG_RPC_CMD_SHM_ALLOC 6 -/* Memory that can be shared with a non-secure user space application */ -#define OPTEE_MSG_RPC_SHM_TYPE_APPL 0 -/* Memory only shared with non-secure kernel */ -#define OPTEE_MSG_RPC_SHM_TYPE_KERNEL 1 - -/* - * Free shared memory previously allocated with OPTEE_MSG_RPC_CMD_SHM_ALLOC - * - * [in] param[0].u.value.a type of memory one of - * OPTEE_MSG_RPC_SHM_TYPE_* above - * [in] param[0].u.value.b value of shared memory reference - * returned in param[0].u.tmem.shm_ref - * above - */ -#define OPTEE_MSG_RPC_CMD_SHM_FREE 7 - -/* - * Access a device on an i2c bus - * - * [in] param[0].u.value.a mode: RD(0), WR(1) - * [in] param[0].u.value.b i2c adapter - * [in] param[0].u.value.c i2c chip - * - * [in] param[1].u.value.a i2c control flags - * - * [in/out] memref[2] buffer to exchange the transfer data - * with the secure world - * - * [out] param[3].u.value.a bytes transferred by the driver - */ -#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER 21 -/* I2C master transfer modes */ -#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD 0 -#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR 1 -/* I2C master control flags */ -#define OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT BIT(0) - #endif /* _OPTEE_MSG_H */ diff --git a/drivers/tee/optee/optee_rpc_cmd.h b/drivers/tee/optee/optee_rpc_cmd.h new file mode 100644 index 000000000000..b8275140cef8 --- /dev/null +++ b/drivers/tee/optee/optee_rpc_cmd.h @@ -0,0 +1,103 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ +/* + * Copyright (c) 2016-2021, Linaro Limited + */ + +#ifndef __OPTEE_RPC_CMD_H +#define __OPTEE_RPC_CMD_H + +/* + * All RPC is done with a struct optee_msg_arg as bearer of information, + * struct optee_msg_arg::arg holds values defined by OPTEE_RPC_CMD_* below. + * Only the commands handled by the kernel driver are defined here. + * + * RPC communication with tee-supplicant is reversed compared to normal + * client communication described above. The supplicant receives requests + * and sends responses. + */ + +/* + * Get time + * + * Returns number of seconds and nano seconds since the Epoch, + * 1970-01-01 00:00:00 +0000 (UTC). + * + * [out] value[0].a Number of seconds + * [out] value[0].b Number of nano seconds. + */ +#define OPTEE_RPC_CMD_GET_TIME 3 + +/* + * Wait queue primitive, helper for secure world to implement a wait queue. + * + * If secure world needs to wait for a secure world mutex it issues a sleep + * request instead of spinning in secure world. Conversely is a wakeup + * request issued when a secure world mutex with a thread waiting thread is + * unlocked. + * + * Waiting on a key + * [in] value[0].a OPTEE_RPC_WAIT_QUEUE_SLEEP + * [in] value[0].b Wait key + * + * Waking up a key + * [in] value[0].a OPTEE_RPC_WAIT_QUEUE_WAKEUP + * [in] value[0].b Wakeup key + */ +#define OPTEE_RPC_CMD_WAIT_QUEUE 4 +#define OPTEE_RPC_WAIT_QUEUE_SLEEP 0 +#define OPTEE_RPC_WAIT_QUEUE_WAKEUP 1 + +/* + * Suspend execution + * + * [in] value[0].a Number of milliseconds to suspend + */ +#define OPTEE_RPC_CMD_SUSPEND 5 + +/* + * Allocate a piece of shared memory + * + * [in] value[0].a Type of memory one of + * OPTEE_RPC_SHM_TYPE_* below + * [in] value[0].b Requested size + * [in] value[0].c Required alignment + * [out] memref[0] Buffer + */ +#define OPTEE_RPC_CMD_SHM_ALLOC 6 +/* Memory that can be shared with a non-secure user space application */ +#define OPTEE_RPC_SHM_TYPE_APPL 0 +/* Memory only shared with non-secure kernel */ +#define OPTEE_RPC_SHM_TYPE_KERNEL 1 + +/* + * Free shared memory previously allocated with OPTEE_RPC_CMD_SHM_ALLOC + * + * [in] value[0].a Type of memory one of + * OPTEE_RPC_SHM_TYPE_* above + * [in] value[0].b Value of shared memory reference or cookie + */ +#define OPTEE_RPC_CMD_SHM_FREE 7 + +/* + * Issue master requests (read and write operations) to an I2C chip. + * + * [in] value[0].a Transfer mode (OPTEE_RPC_I2C_TRANSFER_*) + * [in] value[0].b The I2C bus (a.k.a adapter). + * 16 bit field. + * [in] value[0].c The I2C chip (a.k.a address). + * 16 bit field (either 7 or 10 bit effective). + * [in] value[1].a The I2C master control flags (ie, 10 bit address). + * 16 bit field. + * [in/out] memref[2] Buffer used for data transfers. + * [out] value[3].a Number of bytes transferred by the REE. + */ +#define OPTEE_RPC_CMD_I2C_TRANSFER 21 + +/* I2C master transfer modes */ +#define OPTEE_RPC_I2C_TRANSFER_RD 0 +#define OPTEE_RPC_I2C_TRANSFER_WR 1 + +/* I2C master control flags */ +#define OPTEE_RPC_I2C_FLAGS_TEN_BIT BIT(0) + +#endif /*__OPTEE_RPC_CMD_H*/ diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 777ad54d4c2c..821e1c30c150 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */ /* - * Copyright (c) 2015-2019, Linaro Limited + * Copyright (c) 2015-2021, Linaro Limited */ #ifndef OPTEE_SMC_H #define OPTEE_SMC_H @@ -39,10 +39,10 @@ /* * Function specified by SMC Calling convention * - * Return one of the following UIDs if using API specified in this file - * without further extentions: - * 65cb6b93-af0c-4617-8ed6-644a8d1140f8 - * see also OPTEE_SMC_UID_* in optee_msg.h + * Return the following UID if using API specified in this file + * without further extensions: + * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. + * see also OPTEE_MSG_UID_* in optee_msg.h */ #define OPTEE_SMC_FUNCID_CALLS_UID OPTEE_MSG_FUNCID_CALLS_UID #define OPTEE_SMC_CALLS_UID \ @@ -53,7 +53,7 @@ /* * Function specified by SMC Calling convention * - * Returns 2.0 if using API specified in this file without further extentions. + * Returns 2.0 if using API specified in this file without further extensions. * see also OPTEE_MSG_REVISION_* in optee_msg.h */ #define OPTEE_SMC_FUNCID_CALLS_REVISION OPTEE_MSG_FUNCID_CALLS_REVISION @@ -109,8 +109,8 @@ struct optee_smc_call_get_os_revision_result { * * Call register usage: * a0 SMC Function ID, OPTEE_SMC*CALL_WITH_ARG - * a1 Upper 32bit of a 64bit physical pointer to a struct optee_msg_arg - * a2 Lower 32bit of a 64bit physical pointer to a struct optee_msg_arg + * a1 Upper 32 bits of a 64-bit physical pointer to a struct optee_msg_arg + * a2 Lower 32 bits of a 64-bit physical pointer to a struct optee_msg_arg * a3 Cache settings, not used if physical pointer is in a predefined shared * memory area else per OPTEE_SMC_SHM_* * a4-6 Not used @@ -214,8 +214,9 @@ struct optee_smc_get_shm_config_result { * secure world accepts command buffers located in any parts of non-secure RAM */ #define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM BIT(2) - -/* Secure world supports Shared Memory with a NULL buffer reference */ +/* Secure world is built with virtualization support */ +#define OPTEE_SMC_SEC_CAP_VIRTUALIZATION BIT(3) +/* Secure world supports Shared Memory with a NULL reference */ #define OPTEE_SMC_SEC_CAP_MEMREF_NULL BIT(4) #define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9 @@ -245,8 +246,8 @@ struct optee_smc_exchange_capabilities_result { * * Normal return register usage: * a0 OPTEE_SMC_RETURN_OK - * a1 Upper 32bit of a 64bit Shared memory cookie - * a2 Lower 32bit of a 64bit Shared memory cookie + * a1 Upper 32 bits of a 64-bit Shared memory cookie + * a2 Lower 32 bits of a 64-bit Shared memory cookie * a3-7 Preserved * * Cache empty return register usage: @@ -293,6 +294,31 @@ struct optee_smc_disable_shm_cache_result { #define OPTEE_SMC_ENABLE_SHM_CACHE \ OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE) +/* + * Query OP-TEE about number of supported threads + * + * Normal World OS or Hypervisor issues this call to find out how many + * threads OP-TEE supports. That is how many standard calls can be issued + * in parallel before OP-TEE will return OPTEE_SMC_RETURN_ETHREAD_LIMIT. + * + * Call requests usage: + * a0 SMC Function ID, OPTEE_SMC_GET_THREAD_COUNT + * a1-6 Not used + * a7 Hypervisor Client ID register + * + * Normal return register usage: + * a0 OPTEE_SMC_RETURN_OK + * a1 Number of threads + * a2-7 Preserved + * + * Error return: + * a0 OPTEE_SMC_RETURN_UNKNOWN_FUNCTION Requested call is not implemented + * a1-7 Preserved + */ +#define OPTEE_SMC_FUNCID_GET_THREAD_COUNT 15 +#define OPTEE_SMC_GET_THREAD_COUNT \ + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_THREAD_COUNT) + /* * Resume from RPC (for example after processing a foreign interrupt) * @@ -341,16 +367,16 @@ struct optee_smc_disable_shm_cache_result { * * "Return" register usage: * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. - * a1 Upper 32bits of 64bit physical pointer to allocated + * a1 Upper 32 bits of 64-bit physical pointer to allocated * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't * be allocated. - * a2 Lower 32bits of 64bit physical pointer to allocated + * a2 Lower 32 bits of 64-bit physical pointer to allocated * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't * be allocated * a3 Preserved - * a4 Upper 32bits of 64bit Shared memory cookie used when freeing + * a4 Upper 32 bits of 64-bit Shared memory cookie used when freeing * the memory or doing an RPC - * a5 Lower 32bits of 64bit Shared memory cookie used when freeing + * a5 Lower 32 bits of 64-bit Shared memory cookie used when freeing * the memory or doing an RPC * a6-7 Preserved */ @@ -363,9 +389,9 @@ struct optee_smc_disable_shm_cache_result { * * "Call" register usage: * a0 This value, OPTEE_SMC_RETURN_RPC_FREE - * a1 Upper 32bits of 64bit shared memory cookie belonging to this + * a1 Upper 32 bits of 64-bit shared memory cookie belonging to this * argument memory - * a2 Lower 32bits of 64bit shared memory cookie belonging to this + * a2 Lower 32 bits of 64-bit shared memory cookie belonging to this * argument memory * a3-7 Resume information, must be preserved * @@ -379,7 +405,7 @@ struct optee_smc_disable_shm_cache_result { OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FREE) /* - * Deliver foreign interrupt to normal world. + * Deliver a foreign interrupt in normal world. * * "Call" register usage: * a0 OPTEE_SMC_RETURN_RPC_FOREIGN_INTR @@ -389,7 +415,7 @@ struct optee_smc_disable_shm_cache_result { * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. * a1-7 Preserved */ -#define OPTEE_SMC_RPC_FUNC_FOREIGN_INTR 4 +#define OPTEE_SMC_RPC_FUNC_FOREIGN_INTR 4 #define OPTEE_SMC_RETURN_RPC_FOREIGN_INTR \ OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FOREIGN_INTR) @@ -405,10 +431,10 @@ struct optee_smc_disable_shm_cache_result { * * "Call" register usage: * a0 OPTEE_SMC_RETURN_RPC_CMD - * a1 Upper 32bit of a 64bit Shared memory cookie holding a + * a1 Upper 32 bits of a 64-bit Shared memory cookie holding a * struct optee_msg_arg, must be preserved, only the data should * be updated - * a2 Lower 32bit of a 64bit Shared memory cookie holding a + * a2 Lower 32 bits of a 64-bit Shared memory cookie holding a * struct optee_msg_arg, must be preserved, only the data should * be updated * a3-7 Resume information, must be preserved diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c index 1e3614e4798f..a0c30b664e53 100644 --- a/drivers/tee/optee/rpc.c +++ b/drivers/tee/optee/rpc.c @@ -12,6 +12,7 @@ #include <linux/tee_drv.h> #include "optee_private.h" #include "optee_smc.h" +#include "optee_rpc_cmd.h" struct wq_entry { struct list_head link; @@ -89,7 +90,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, if (!client.adapter) goto bad; - if (params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT) { + if (params[1].u.value.a & OPTEE_RPC_I2C_FLAGS_TEN_BIT) { if (!i2c_check_functionality(client.adapter, I2C_FUNC_10BIT_ADDR)) { i2c_put_adapter(client.adapter); @@ -103,11 +104,11 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr); switch (params[0].u.value.a) { - case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD: + case OPTEE_RPC_I2C_TRANSFER_RD: ret = i2c_master_recv(&client, params[2].u.memref.shm->kaddr, params[2].u.memref.size); break; - case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR: + case OPTEE_RPC_I2C_TRANSFER_WR: ret = i2c_master_send(&client, params[2].u.memref.shm->kaddr, params[2].u.memref.size); break; @@ -194,10 +195,10 @@ static void handle_rpc_func_cmd_wq(struct optee *optee, goto bad; switch (arg->params[0].u.value.a) { - case OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP: + case OPTEE_RPC_WAIT_QUEUE_SLEEP: wq_sleep(&optee->wait_queue, arg->params[0].u.value.b); break; - case OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP: + case OPTEE_RPC_WAIT_QUEUE_WAKEUP: wq_wakeup(&optee->wait_queue, arg->params[0].u.value.b); break; default: @@ -267,11 +268,11 @@ static struct tee_shm *cmd_alloc_suppl(struct tee_context *ctx, size_t sz) struct tee_shm *shm; param.attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT; - param.u.value.a = OPTEE_MSG_RPC_SHM_TYPE_APPL; + param.u.value.a = OPTEE_RPC_SHM_TYPE_APPL; param.u.value.b = sz; param.u.value.c = 0; - ret = optee_supp_thrd_req(ctx, OPTEE_MSG_RPC_CMD_SHM_ALLOC, 1, &param); + ret = optee_supp_thrd_req(ctx, OPTEE_RPC_CMD_SHM_ALLOC, 1, &param); if (ret) return ERR_PTR(-ENOMEM); @@ -308,10 +309,10 @@ static void handle_rpc_func_cmd_shm_alloc(struct tee_context *ctx, sz = arg->params[0].u.value.b; switch (arg->params[0].u.value.a) { - case OPTEE_MSG_RPC_SHM_TYPE_APPL: + case OPTEE_RPC_SHM_TYPE_APPL: shm = cmd_alloc_suppl(ctx, sz); break; - case OPTEE_MSG_RPC_SHM_TYPE_KERNEL: + case OPTEE_RPC_SHM_TYPE_KERNEL: shm = tee_shm_alloc(ctx, sz, TEE_SHM_MAPPED); break; default: @@ -383,7 +384,7 @@ static void cmd_free_suppl(struct tee_context *ctx, struct tee_shm *shm) struct tee_param param; param.attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT; - param.u.value.a = OPTEE_MSG_RPC_SHM_TYPE_APPL; + param.u.value.a = OPTEE_RPC_SHM_TYPE_APPL; param.u.value.b = tee_shm_get_id(shm); param.u.value.c = 0; @@ -400,7 +401,7 @@ static void cmd_free_suppl(struct tee_context *ctx, struct tee_shm *shm) */ tee_shm_put(shm); - optee_supp_thrd_req(ctx, OPTEE_MSG_RPC_CMD_SHM_FREE, 1, &param); + optee_supp_thrd_req(ctx, OPTEE_RPC_CMD_SHM_FREE, 1, &param); } static void handle_rpc_func_cmd_shm_free(struct tee_context *ctx, @@ -418,10 +419,10 @@ static void handle_rpc_func_cmd_shm_free(struct tee_context *ctx, shm = (struct tee_shm *)(unsigned long)arg->params[0].u.value.b; switch (arg->params[0].u.value.a) { - case OPTEE_MSG_RPC_SHM_TYPE_APPL: + case OPTEE_RPC_SHM_TYPE_APPL: cmd_free_suppl(ctx, shm); break; - case OPTEE_MSG_RPC_SHM_TYPE_KERNEL: + case OPTEE_RPC_SHM_TYPE_KERNEL: tee_shm_free(shm); break; default: @@ -458,23 +459,23 @@ static void handle_rpc_func_cmd(struct tee_context *ctx, struct optee *optee, } switch (arg->cmd) { - case OPTEE_MSG_RPC_CMD_GET_TIME: + case OPTEE_RPC_CMD_GET_TIME: handle_rpc_func_cmd_get_time(arg); break; - case OPTEE_MSG_RPC_CMD_WAIT_QUEUE: + case OPTEE_RPC_CMD_WAIT_QUEUE: handle_rpc_func_cmd_wq(optee, arg); break; - case OPTEE_MSG_RPC_CMD_SUSPEND: + case OPTEE_RPC_CMD_SUSPEND: handle_rpc_func_cmd_wait(arg); break; - case OPTEE_MSG_RPC_CMD_SHM_ALLOC: + case OPTEE_RPC_CMD_SHM_ALLOC: free_pages_list(call_ctx); handle_rpc_func_cmd_shm_alloc(ctx, arg, call_ctx); break; - case OPTEE_MSG_RPC_CMD_SHM_FREE: + case OPTEE_RPC_CMD_SHM_FREE: handle_rpc_func_cmd_shm_free(ctx, arg); break; - case OPTEE_MSG_RPC_CMD_I2C_TRANSFER: + case OPTEE_RPC_CMD_I2C_TRANSFER: handle_rpc_func_cmd_i2c_transfer(ctx, arg); break; default: -- 2.25.1

5 years, 4 months

1
0
0 0

[GIT PULL] OP-TEE driver fix for v5.11

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch taking care of a rcu_sched trace in some corner cases when OP-TEE is invoked. 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-rcu-sched-trace-for-v5.11 for you to fetch changes up to dcb3b06d9c34f33a249f65c08805461fb0c4325b: tee: optee: replace might_sleep with cond_resched (2021-01-21 10:36:48 +0100) ---------------------------------------------------------------- Fix rcu_sched trace from OP-TEE invoke Replaces might_sleep() with a conditional call to cond_resched() in order to avoid the rcu_sched trace in some corner cases. ---------------------------------------------------------------- Rouven Czerwinski (1): tee: optee: replace might_sleep with cond_resched drivers/tee/optee/call.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

5 years, 5 months

2
1
0 0

[PATCH v2] tee: optee: replace might_sleep with cond_resched

by Rouven Czerwinski

might_sleep() is a debugging aid and triggers rescheduling only for certain kernel configurations. Replace with an explicit check and reschedule to work for all kernel configurations. Fixes the following trace: [ 572.945146] rcu: INFO: rcu_sched self-detected stall on CPU [ 572.949275] rcu: 0-....: (2099 ticks this GP) idle=572/1/0x40000002 softirq=7412/7412 fqs=974 [ 572.957964] (t=2100 jiffies g=10393 q=21) [ 572.962054] NMI backtrace for cpu 0 [ 572.965540] CPU: 0 PID: 165 Comm: xtest Not tainted 5.8.7 #1 [ 572.971188] Hardware name: STM32 (Device Tree Support) [ 572.976354] [<c011163c>] (unwind_backtrace) from [<c010b7f8>] (show_stack+0x10/0x14) [ 572.984080] [<c010b7f8>] (show_stack) from [<c0511e4c>] (dump_stack+0xc4/0xd8) [ 572.991300] [<c0511e4c>] (dump_stack) from [<c0519abc>] (nmi_cpu_backtrace+0x90/0xc4) [ 572.999130] [<c0519abc>] (nmi_cpu_backtrace) from [<c0519bdc>] (nmi_trigger_cpumask_backtrace+0xec/0x130) [ 573.008706] [<c0519bdc>] (nmi_trigger_cpumask_backtrace) from [<c01a5184>] (rcu_dump_cpu_stacks+0xe8/0x110) [ 573.018453] [<c01a5184>] (rcu_dump_cpu_stacks) from [<c01a4234>] (rcu_sched_clock_irq+0x7fc/0xa88) [ 573.027416] [<c01a4234>] (rcu_sched_clock_irq) from [<c01acdd0>] (update_process_times+0x30/0x8c) [ 573.036291] [<c01acdd0>] (update_process_times) from [<c01bfb90>] (tick_sched_timer+0x4c/0xa8) [ 573.044905] [<c01bfb90>] (tick_sched_timer) from [<c01adcc8>] (__hrtimer_run_queues+0x174/0x358) [ 573.053696] [<c01adcc8>] (__hrtimer_run_queues) from [<c01aea2c>] (hrtimer_interrupt+0x118/0x2bc) [ 573.062573] [<c01aea2c>] (hrtimer_interrupt) from [<c09ad664>] (arch_timer_handler_virt+0x28/0x30) [ 573.071536] [<c09ad664>] (arch_timer_handler_virt) from [<c0190f50>] (handle_percpu_devid_irq+0x8c/0x240) [ 573.081109] [<c0190f50>] (handle_percpu_devid_irq) from [<c018ab8c>] (generic_handle_irq+0x34/0x44) [ 573.090156] [<c018ab8c>] (generic_handle_irq) from [<c018b194>] (__handle_domain_irq+0x5c/0xb0) [ 573.098857] [<c018b194>] (__handle_domain_irq) from [<c052ac50>] (gic_handle_irq+0x4c/0x90) [ 573.107209] [<c052ac50>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x90) [ 573.114682] Exception stack(0xd90dfcf8 to 0xd90dfd40) [ 573.119732] fce0: ffff0004 00000000 [ 573.127917] fd00: 00000000 00000000 00000000 00000000 00000000 00000000 d93493cc ffff0000 [ 573.136098] fd20: d2bc39c0 be926998 d90dfd58 d90dfd48 c09f3384 c01151f0 400d0013 ffffffff [ 573.144281] [<c0100b0c>] (__irq_svc) from [<c01151f0>] (__arm_smccc_smc+0x10/0x20) [ 573.151854] [<c01151f0>] (__arm_smccc_smc) from [<c09f3384>] (optee_smccc_smc+0x3c/0x44) [ 573.159948] [<c09f3384>] (optee_smccc_smc) from [<c09f4170>] (optee_do_call_with_arg+0xb8/0x154) [ 573.168735] [<c09f4170>] (optee_do_call_with_arg) from [<c09f4638>] (optee_invoke_func+0x110/0x190) [ 573.177786] [<c09f4638>] (optee_invoke_func) from [<c09f1ebc>] (tee_ioctl+0x10b8/0x11c0) [ 573.185879] [<c09f1ebc>] (tee_ioctl) from [<c029f62c>] (ksys_ioctl+0xe0/0xa4c) [ 573.193101] [<c029f62c>] (ksys_ioctl) from [<c0100060>] (ret_fast_syscall+0x0/0x54) [ 573.200750] Exception stack(0xd90dffa8 to 0xd90dfff0) [ 573.205803] ffa0: be926bf4 be926a78 00000003 8010a403 be926908 004e3cf8 [ 573.213987] ffc0: be926bf4 be926a78 00000000 00000036 be926908 be926918 be9269b0 bffdf0f8 [ 573.222162] ffe0: b6d76fb0 be9268fc b6d66621 b6c7e0d8 seen on STM32 DK2 with CONFIG_PREEMPT_NONE. Signed-off-by: Rouven Czerwinski <r.czerwinski(a)pengutronix.de> Tested-by: Sumit Garg <sumit.garg(a)linaro.org> --- v2: - Add tested-by from Sumit Garg - Adjust commit message as agreed upon with Lucas Stach drivers/tee/optee/call.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index c981757ba0d4..f889bc97bed7 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -8,6 +8,7 @@ #include <linux/errno.h> #include <linux/mm.h> #include <linux/slab.h> +#include <linux/sched.h> #include <linux/tee_drv.h> #include <linux/types.h> #include <linux/uaccess.h> @@ -148,7 +149,8 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) */ optee_cq_wait_for_completion(&optee->call_queue, &w); } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) { - might_sleep(); + if(need_resched()) + cond_resched(); param.a0 = res.a0; param.a1 = res.a1; param.a2 = res.a2; -- 2.29.2

5 years, 5 months

2
1
0 0

OP-TEE 3.12.0 has been released

by Joakim Bech

Hi, I'm pleased to let you know that I've just wrapped up the v3.12.0 release for OP-TEE. As usual, the list of changes can be found in the changelog [1]. Thanks to everyone who participated with contributions and helping out with testing the release candidate [2]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/3d47a131bca1d9ed511bfd516aa5e7026… Regards, Joakim

5 years, 5 months

2
1
0 0

Linaro OP-TEE Contributions meeting January 2021

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Thursday January 28th(a)16.00 (UTC+1). This time we have two guest speakers, with two different topics. - Clément Faure (NXP): HW crypto accelerator integration with crypto framework in OP-TEE - Sumit Garg (Linaro): TEE based Trusted Keys This might take the whole meeting, but feel free to suggest topics you'd like to discuss otherwise (by replying to this email or write it directly in the meeting notes). Meeting details: --------------- Date/time: Thursday January 28th(a)16.00 (UTC+1) https://everytimezone.com/s/c43ea835 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

5 years, 5 months

1
0
0 0

[PATCH] drivers: optee: use flexible-array member instead of zero-length array

by Tian Tao

Use flexible-array member introduced in C99 instead of zero-length array. Most of zero-length array was already taken care in previous patch [1]. Now modified few more cases which were not handled earlier. [1]. https://patchwork.kernel.org/patch/11394197/ Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/tee/optee/optee_msg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 7b2d919..b1f1e90 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -199,7 +199,7 @@ struct optee_msg_arg { u32 num_params; /* num_params tells the actual number of element in params */ - struct optee_msg_param params[0]; + struct optee_msg_param params[]; }; /** -- 2.7.4

5 years, 5 months

2
1
0 0

Re: [Tee-dev] Persistent filesystem between reboots

by Joakim Bech

On Fri, Jan 15, 2021 at 12:50:27PM +0000, Jens Wiklander via OP-TEE wrote: > Hi Kris, > > On Thu, Jan 14, 2021 at 1:37 PM Kris Kwiatkowski <kris(a)amongbytes.com> wrote: > > > > Hi, > > > > I'm using HiKey 960 for my research project. I've noticed that > > filesystem is not persistent between reboot. Is there a way > > to change it, so that any change to file in the /etc will be > > persistent? > > There's no easy way of doing that with our repo based builds I'm aware > of. The purpose of our (OP-TEE team) builds is in principle to be able > to execute xtest and other test programs. For this use case it's > actually an advantage to start from a clean state each time. In your > case I think you need to pick a suitable distribution and update it as > needed to support OP-TEE. It could be worth looking at Yocto as there > is some OP-TEE support already. > You can also give NFS a try, I tend to use that myself when playing with OP-TEE and Raspberry Pi3. I.e., I basically just untar the rootfs created by our setup into a folder that is exposed via NFS. Then in addition to that I have a couple of helper scripts that copies the files Jens mentioned below into that NFS folder when I need to update with changed files (TA's, OP-TEE libs etc). > Here's a short list of what's needed: > 1. TF-A compiled with OP-TEE support (dispatcher in BL31 and load > support in bl2) > 2. OP-TEE included in the FIP loaded by TF-A > 3. OP-TEE nodes in device tree > 4. OP-TEE driver enabled in the kernel (recent upstream kernel should > work in most cases) > 5. tee-supplicant and libteec.so installed in the file system > 6. tee-supplicant started > > With that in place you should be good to go. > > Cheers, > Jens -- Regards, Joakim

5 years, 5 months

1
0
0 0

Re: [Tee-dev] Persistent filesystem between reboots

by Jens Wiklander

Hi Kris, On Thu, Jan 14, 2021 at 1:37 PM Kris Kwiatkowski <kris(a)amongbytes.com> wrote: > > Hi, > > I'm using HiKey 960 for my research project. I've noticed that > filesystem is not persistent between reboot. Is there a way > to change it, so that any change to file in the /etc will be > persistent? There's no easy way of doing that with our repo based builds I'm aware of. The purpose of our (OP-TEE team) builds is in principle to be able to execute xtest and other test programs. For this use case it's actually an advantage to start from a clean state each time. In your case I think you need to pick a suitable distribution and update it as needed to support OP-TEE. It could be worth looking at Yocto as there is some OP-TEE support already. Here's a short list of what's needed: 1. TF-A compiled with OP-TEE support (dispatcher in BL31 and load support in bl2) 2. OP-TEE included in the FIP loaded by TF-A 3. OP-TEE nodes in device tree 4. OP-TEE driver enabled in the kernel (recent upstream kernel should work in most cases) 5. tee-supplicant and libteec.so installed in the file system 6. tee-supplicant started With that in place you should be good to go. Cheers, Jens

5 years, 5 months

1
0
0 0

Preparing for OP-TEE 3.12.0

by Joakim Bech

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.12.0 is scheduled to be released at 2021-01-15. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/4291. As usual, we will create a release candidate tag one week before the release date for final testing. In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Regards, Joakim

5 years, 5 months

1
1
0 0

FYI - Open Source Project Criticality Score

by Jerome Forissier

Hi, I just wanted to share that the Open Source Security Foundation (OSSF, [1]) has recently developed a tool called the Open Source Project Criticality Score (Beta) [2]. As of December 24, 2020, OP-TEE OS is number 39 in the top 200 C language projects on GitHub, ranked by criticality score. Not bad I think. [1] https://openssf.org/ [2] https://github.com/ossf/criticality_score [3] https://commondatastorage.googleapis.com/ossf-criticality-score/index.html (c_top_200.csv) Regards, -- Jerome

5 years, 5 months

1
0
0 0

Re: [PATCH] tee: optee: replace might_sleep with cond_resched

by Sumit Garg

On Fri, 25 Sept 2020 at 12:29, Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > On Fri, Sep 18, 2020 at 7:45 PM Rouven Czerwinski > <r.czerwinski(a)pengutronix.de> wrote: > > > > On Kernels with CONFIG_PREEMPT_NONE might_sleep() is not enough to force > > rescheduling, replace it with a resched check and cond_resched. Fixes > > the following stall: > > > > [ 572.945146] rcu: INFO: rcu_sched self-detected stall on CPU > > [ 572.949275] rcu: 0-....: (2099 ticks this GP) idle=572/1/0x40000002 softirq=7412/7412 fqs=974 > > [ 572.957964] (t=2100 jiffies g=10393 q=21) > > [ 572.962054] NMI backtrace for cpu 0 > > [ 572.965540] CPU: 0 PID: 165 Comm: xtest Not tainted 5.8.7 #1 > > [ 572.971188] Hardware name: STM32 (Device Tree Support) > > [ 572.976354] [<c011163c>] (unwind_backtrace) from [<c010b7f8>] (show_stack+0x10/0x14) > > [ 572.984080] [<c010b7f8>] (show_stack) from [<c0511e4c>] (dump_stack+0xc4/0xd8) > > [ 572.991300] [<c0511e4c>] (dump_stack) from [<c0519abc>] (nmi_cpu_backtrace+0x90/0xc4) > > [ 572.999130] [<c0519abc>] (nmi_cpu_backtrace) from [<c0519bdc>] (nmi_trigger_cpumask_backtrace+0xec/0x130) > > [ 573.008706] [<c0519bdc>] (nmi_trigger_cpumask_backtrace) from [<c01a5184>] (rcu_dump_cpu_stacks+0xe8/0x110) > > [ 573.018453] [<c01a5184>] (rcu_dump_cpu_stacks) from [<c01a4234>] (rcu_sched_clock_irq+0x7fc/0xa88) > > [ 573.027416] [<c01a4234>] (rcu_sched_clock_irq) from [<c01acdd0>] (update_process_times+0x30/0x8c) > > [ 573.036291] [<c01acdd0>] (update_process_times) from [<c01bfb90>] (tick_sched_timer+0x4c/0xa8) > > [ 573.044905] [<c01bfb90>] (tick_sched_timer) from [<c01adcc8>] (__hrtimer_run_queues+0x174/0x358) > > [ 573.053696] [<c01adcc8>] (__hrtimer_run_queues) from [<c01aea2c>] (hrtimer_interrupt+0x118/0x2bc) > > [ 573.062573] [<c01aea2c>] (hrtimer_interrupt) from [<c09ad664>] (arch_timer_handler_virt+0x28/0x30) > > [ 573.071536] [<c09ad664>] (arch_timer_handler_virt) from [<c0190f50>] (handle_percpu_devid_irq+0x8c/0x240) > > [ 573.081109] [<c0190f50>] (handle_percpu_devid_irq) from [<c018ab8c>] (generic_handle_irq+0x34/0x44) > > [ 573.090156] [<c018ab8c>] (generic_handle_irq) from [<c018b194>] (__handle_domain_irq+0x5c/0xb0) > > [ 573.098857] [<c018b194>] (__handle_domain_irq) from [<c052ac50>] (gic_handle_irq+0x4c/0x90) > > [ 573.107209] [<c052ac50>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x90) > > [ 573.114682] Exception stack(0xd90dfcf8 to 0xd90dfd40) > > [ 573.119732] fce0: ffff0004 00000000 > > [ 573.127917] fd00: 00000000 00000000 00000000 00000000 00000000 00000000 d93493cc ffff0000 > > [ 573.136098] fd20: d2bc39c0 be926998 d90dfd58 d90dfd48 c09f3384 c01151f0 400d0013 ffffffff > > [ 573.144281] [<c0100b0c>] (__irq_svc) from [<c01151f0>] (__arm_smccc_smc+0x10/0x20) > > [ 573.151854] [<c01151f0>] (__arm_smccc_smc) from [<c09f3384>] (optee_smccc_smc+0x3c/0x44) > > [ 573.159948] [<c09f3384>] (optee_smccc_smc) from [<c09f4170>] (optee_do_call_with_arg+0xb8/0x154) > > [ 573.168735] [<c09f4170>] (optee_do_call_with_arg) from [<c09f4638>] (optee_invoke_func+0x110/0x190) > > [ 573.177786] [<c09f4638>] (optee_invoke_func) from [<c09f1ebc>] (tee_ioctl+0x10b8/0x11c0) > > [ 573.185879] [<c09f1ebc>] (tee_ioctl) from [<c029f62c>] (ksys_ioctl+0xe0/0xa4c) > > [ 573.193101] [<c029f62c>] (ksys_ioctl) from [<c0100060>] (ret_fast_syscall+0x0/0x54) > > [ 573.200750] Exception stack(0xd90dffa8 to 0xd90dfff0) > > [ 573.205803] ffa0: be926bf4 be926a78 00000003 8010a403 be926908 004e3cf8 > > [ 573.213987] ffc0: be926bf4 be926a78 00000000 00000036 be926908 be926918 be9269b0 bffdf0f8 > > [ 573.222162] ffe0: b6d76fb0 be9268fc b6d66621 b6c7e0d8 > > > > seen on STM32 DK2. > > > > Signed-off-by: Rouven Czerwinski <r.czerwinski(a)pengutronix.de> > > --- > > drivers/tee/optee/call.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c > > index 20b6fd7383c5..83b73b1d52f0 100644 > > --- a/drivers/tee/optee/call.c > > +++ b/drivers/tee/optee/call.c > > @@ -8,6 +8,7 @@ > > #include <linux/errno.h> > > #include <linux/mm.h> > > #include <linux/slab.h> > > +#include <linux/sched.h> > > #include <linux/tee_drv.h> > > #include <linux/types.h> > > #include <linux/uaccess.h> > > @@ -148,7 +149,8 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) > > */ > > optee_cq_wait_for_completion(&optee->call_queue, &w); > > } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) { > > - might_sleep(); > > + if(need_resched()) > > + cond_resched(); > > This looks OK to me. But I'd prefer if someone else could confirm this too. > Tested-by: Sumit Garg <sumit.garg(a)linaro.org> -Sumit > Thanks, > Jens > > > param.a0 = res.a0; > > param.a1 = res.a1; > > param.a2 = res.a2; > > -- > > 2.28.0 > >

5 years, 5 months

2
1
0 0

Re: Mapping an arbitrary SDRAM block outside TZDRAM

by Jens Wiklander

Hi Robert, Comments below. On Mon, Dec 28, 2020 at 7:49 PM Robert Delien via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hi, > > As discussed earlier, our application requires secured display contents and > is using a secure frame buffer. > > Now to transit from U-Boot to Op-tee as smoothly as possible, I would like > to copy the contents from the U-Boot frame buffer into the Optee frame > buffer upon LCD driver initialisation. > > The U-Boot frame buffer address is calculated at run time and I haven't > found a hand-off mechanism, but the physical address can be easily read > from the LCDIF peripheral's registers. Unfortunately, no MMU mapping is > present per default for this physical address outside the TZDRAM area. > > Is it possible to temporarily map this rather arbitrary non-secure physical > DDR address outside TZDRAM, so I can access it through a virtual address? > Preferably in a way that I can also remove this mapping after copying the > frame buffer? Yes, it's actually easier than one might first imagine. I assume you will interact with OP-TEE via a Pseudo TA. This framebuffer is normal non-secure DDR from OP-TEE point of view, so it should be possible to just supply it as a memref parameter when invoking the PTA. Cheers, Jens

5 years, 5 months

1
0
0 0

Mapping an arbitrary SDRAM block outside TZDRAM

by Robert Delien

Hi, As discussed earlier, our application requires secured display contents and is using a secure frame buffer. Now to transit from U-Boot to Op-tee as smoothly as possible, I would like to copy the contents from the U-Boot frame buffer into the Optee frame buffer upon LCD driver initialisation. The U-Boot frame buffer address is calculated at run time and I haven't found a hand-off mechanism, but the physical address can be easily read from the LCDIF peripheral's registers. Unfortunately, no MMU mapping is present per default for this physical address outside the TZDRAM area. Is it possible to temporarily map this rather arbitrary non-secure physical DDR address outside TZDRAM, so I can access it through a virtual address? Preferably in a way that I can also remove this mapping after copying the frame buffer? Thanks in advance; Your help is highly appreciated. 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.

5 years, 5 months

1
0
0 0

Re: [PATCH] tee: client UUID: Skip REE kernel login method as well

by Elvira Khabirova

On Tue, 22 Dec 2020 08:50:56 +0000 Vesa Jääskeläinen via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > Hi, > > On 2020-10-08 08:53, Jens Wiklander wrote: > > Hi Sumit, > > > > On Wed, Oct 7, 2020 at 11:27 AM Sumit Garg <sumit.garg(a)linaro.org> wrote: > >> > >> Hi Jens, > >> > >> On Thu, 17 Sep 2020 at 19:10, Sumit Garg <sumit.garg(a)linaro.org> wrote: > >>> > >>> Since the addition of session's client UUID generation via commit [1], > >>> login via REE kernel method was disallowed. So fix that via passing > >>> nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well. > >>> > >>> Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") [1] > >>> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> > >>> --- > >>> drivers/tee/tee_core.c | 3 ++- > >>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>> > >> > >> Would you like to pick up this fix? > > > > Thanks for the reminder. > > This looks good to me. I'll pick up this unless someone objects. > > Vesa, does this look good to you too? > > > > Cheers, > > Jens > > Sorry I have been away for a while from the mailing list. > > It seems that this is merged -- only thing that came to my mind with > this is that: > > If we have some kernel protected keys or so -- should we have separate > client UUID for kernel operations. > > Like when TEE_IOCTL_LOGIN_REE_KERNEL is given then client UUID would be > generated for "kernel". > > This way we can make sure that kernel owned keys stays for kernel. Nil > UUID is kinda reserved for public login. Isn't this unnecessary? According to the TEE Internal Core API Specification, TEE_Identity, a data type that "defines the full identity of a Client", consists of a UUID *and* one of the TEE_LOGIN_XXX constants. Therefore, TEE_LOGIN_PUBLIC with a nil UUID is a different client than TEE_LOGIN_REE_KERNEL with a nil UUID. > Thanks, > Vesa Jääskeläinen > > > > >> > >> -Sumit > >> > >>> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c > >>> index 64637e0..2f6199e 100644 > >>> --- a/drivers/tee/tee_core.c > >>> +++ b/drivers/tee/tee_core.c > >>> @@ -200,7 +200,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, > >>> int name_len; > >>> int rc; > >>> > >>> - if (connection_method == TEE_IOCTL_LOGIN_PUBLIC) { > >>> + if (connection_method == TEE_IOCTL_LOGIN_PUBLIC || > >>> + connection_method == TEE_IOCTL_LOGIN_REE_KERNEL) { > >>> /* Nil UUID to be passed to TEE environment */ > >>> uuid_copy(uuid, &uuid_null); > >>> return 0; > >>> -- > >>> 2.7.4 > >>> >

5 years, 6 months

2
1
0 0

[PATCH v4] tee: add support for application-based session login methods

by Elvira Khabirova

GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- Changes in v4: - Fix potential exe_file leaks. Changes in v3: - Remove free_app_id() and replace it with calls to kfree(). Changes in v2: - Rename some functions and variables to make them shorter. - Include linux/security.h unconditionally. - Restructure error handling in tee_session_calc_client_uuid(). --- drivers/tee/Kconfig | 29 ++++++++++ drivers/tee/tee_core.c | 126 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 147 insertions(+), 8 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index e99d840c2511..4cd6e0d2aad5 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -11,6 +11,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e09a095..a72b8c19253a 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -7,9 +7,12 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> +#include <linux/security.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -21,7 +24,7 @@ #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -125,6 +128,65 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *get_app_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + /* + * An identifier string for the binary. Depends on the implementation. + * Could be, for example, a string containing the application vendor ID, + * or the binary's signature, or its hash and a timestamp. + */ + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + fput(exe_file); + + if (len < 0) + return ERR_PTR(len); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *get_app_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + fput(exe_file); + + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -197,6 +259,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *app_id_data = NULL; + const char *app_id = NULL; int name_len; int rc; @@ -217,6 +281,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -227,10 +299,6 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, case TEE_IOCTL_LOGIN_USER: name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x", current_euid().val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; - goto out_free_name; - } break; case TEE_IOCTL_LOGIN_GROUP: @@ -243,10 +311,49 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x", grp.val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; + break; + + case TEE_IOCTL_LOGIN_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); goto out_free_name; } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, app_id); + kfree(app_id_data); break; default: @@ -254,7 +361,10 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + if (name_len < TEE_UUID_NS_NAME_SIZE) + rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + else + rc = -E2BIG; out_free_name: kfree(name); -- 2.28.0

5 years, 6 months

2
1
0 0

[PATCH] tee: client UUID: Skip REE kernel login method as well

by Sumit Garg

Since the addition of session's client UUID generation via commit [1], login via REE kernel method was disallowed. So fix that via passing nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well. Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") [1] Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/tee/tee_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e0..2f6199e 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -200,7 +200,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, int name_len; int rc; - if (connection_method == TEE_IOCTL_LOGIN_PUBLIC) { + if (connection_method == TEE_IOCTL_LOGIN_PUBLIC || + connection_method == TEE_IOCTL_LOGIN_REE_KERNEL) { /* Nil UUID to be passed to TEE environment */ uuid_copy(uuid, &uuid_null); return 0; -- 2.7.4

5 years, 6 months

3
3
0 0

Linaro OP-TEE Contributions meeting December 2020

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Monday December 21st(a)16.00 (UTC+1). This time it will just be an open discussion, since we have no planned presentation/talks otherwise. So feel free to suggest topics you'd like to discuss (by replying to this email or write it directly in the meeting notes). The issue we had last time with Zoom ID not valid any longer should have been fixed now. Note that the fix involved generating a new meeting ID, which means that the old connection information is no longer valid. It's also worth mentioning that all upcoming meetings can now be found at the TrustedFirmware calendar (url is below). Meeting details: --------------- Date/time: Monday December 21st(a)16.00 (UTC+1) https://everytimezone.com/s/f5c1ffe4 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

5 years, 6 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 17th December 2020 16:00 – 17:00 (GMT). As well as being posted to the TF-A mailing list this has been cross posted to OPTEE mailing list. For OPTEE attendees the Zoom call details are included below. Agenda: * An introduction to the Trusted Services project * Presented by Julian Hall * Summary * The Trusted Services project is a new trustedfirmware.org project that provides a home for security related service components that can run in the different isolated processing environments available on Arm Cortex-A. The project attempts to promote reuse and standardization to enable a consistent set of services to be provided by firmware, independent of which isolation technology is used. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. This is the last TF-A Tech Forum session until January 2021. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

5 years, 6 months

1
0
0 0

[PATCH v4 RESEND] tee: add support for application-based session login methods

by Elvira Khabirova

This is both a resend and a request for comments. The main reason for implementing this was to be able to authorize access to particular TAs based on the applications that request it. Furthermore, being able to distinguish between different applications also allows having trusted storage per-application. I believe this functionality might be crucial to many users of op-tee. This patch provides two possible ways of calculating the application identifier strings. This also serves as a stub for other methods. Since there is no concept of "application" known to the Linux kernel, the two proposed methods are based on the calling task's executable: the executable file's path and its SELinux attributes. Some vendor-specific methods may employ a service running in userspace, but these two methods are the only ones that we came up with that are fully contained in the kernel and are usable (and we actually use one of the two methods suggested). There might be other valid definitions of application-based identifier strings. The GP TEE Client API specifies the credentials generated as "only depending on the identity of the application program", being "persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage"; not more specific than that. Perhaps some other properties of a running task can be used to calculate an app ID, for example, to not depend on having an executable file (which is admittedly a rare thing to come by), or to be able to distinguish between different scripts run with one interpreter (which is also rare since the TEE Client API is C-based). If you're interested in this patch, or if you're using application-based login methods but with a different scheme, I would love to hear your experiences. Maybe there are other methods to consider; maybe the proposed methods are enough. If you're interested in testing this patch out, there is a reviewed, good-to-go pull request in the optee_test repository: https://github.com/OP-TEE/optee_test/pull/468 >8------------------------------------------------------8< GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- Changes in v4: - Fix potential exe_file leaks. Changes in v3: - Remove free_app_id() and replace it with calls to kfree(). Changes in v2: - Rename some functions and variables to make them shorter. - Include linux/security.h unconditionally. - Restructure error handling in tee_session_calc_client_uuid(). --- drivers/tee/Kconfig | 29 ++++++++++ drivers/tee/tee_core.c | 126 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 147 insertions(+), 8 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index e99d840c2511..4cd6e0d2aad5 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -11,6 +11,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 6ade4a5c4840..510ef2fceb82 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -7,9 +7,12 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> +#include <linux/security.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -21,7 +24,7 @@ #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -125,6 +128,65 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *get_app_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + /* + * An identifier string for the binary. Depends on the implementation. + * Could be, for example, a string containing the application vendor ID, + * or the binary's signature, or its hash and a timestamp. + */ + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + fput(exe_file); + + if (len < 0) + return ERR_PTR(len); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *get_app_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + fput(exe_file); + + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -197,6 +259,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *app_id_data = NULL; + const char *app_id = NULL; int name_len; int rc; @@ -218,6 +282,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -228,10 +300,6 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, case TEE_IOCTL_LOGIN_USER: name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x", current_euid().val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; - goto out_free_name; - } break; case TEE_IOCTL_LOGIN_GROUP: @@ -244,10 +312,49 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x", grp.val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; + break; + + case TEE_IOCTL_LOGIN_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); goto out_free_name; } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, app_id); + kfree(app_id_data); break; default: @@ -255,7 +362,10 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + if (name_len < TEE_UUID_NS_NAME_SIZE) + rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + else + rc = -E2BIG; out_free_name: kfree(name); -- 2.29.2

5 years, 6 months

1
0
0 0

Re: Secure memory allocation

by Rouven Czerwinski

On Mon, 2020-12-07 at 16:48 +0000, Robert Deliën via OP-TEE wrote: > Hi, > > Again, thank you very much for your prompt answer. > > > Looks good, the tee_mm functions handle resource allocation typically > > virtual or physical memory. It doesn't touch the memory itself. The > > code above looks OK. Yep, the memory will be physically contiguous > > since the entire TA RAM range (represented here by tee_mm_sec_ddr) is > > mapped with physically contiguous memory. > > The code 'works' beautifully. That is; The FB addresses it produces seem plausible: > D/TC:0 0 imx_lcdif_init:334 fb[0] @0x88e00000 (pa 0x8e100000) > D/TC:0 0 imx_lcdif_init:334 fb[1] @0x88e96000 (pa 0x8e196000) > Even accessing the buffer using the corresponding virtual addresses produces no Abort faults. > > Unfortunately, it doesn't produce an image on the LCD either. However, if I (illegally) re-use part of shared memory as a frame buffer, I _do_ get an image. > Details from conf.mk: > CFG_DRAM_BASE = 0x80000000 > CFG_DDR_SIZE = 0x10000000 > CFG_SHMEM_SIZE = 0x00200000 > CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) > > Details from code: > fb_pa = 0x90000000 - FB_SIZE; > fb_va = (void *fb_pa, MEM_AREA_NSEC_SHM); > > We are starting to suspect that the LCD peripheral is denied access to the frame buffer by the TZ controller, and this specific peripheral's bus master doesn't seem to have corresponding Supervisor mode bits in the HP0 or SA register. > > Now I do know that this problem is beyond the scope of this mailing list, but if anybody on this list knows more about this, I'd be more than happy to hear about it! > Hm, since the LCDIF CSL register is lumped together with the PXP, you could try setting the SA bit for the PXP peripheral. Regards, Rouven Czerwinski

5 years, 6 months

2
1
0 0

Re: Secure memory allocation

by Jens Wiklander

Hi Robert, Some answers below. On Wed, Dec 2, 2020 at 1:00 PM Robert Deliën via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hi, > > We are using op-tee 3.10 in our i.MX6UL-based product and we are running into a small problem we hope you can help us out with. Apologies for the large mail; It's mostly pictures. > > The nature of our product requires us to protect access to the display contents. To achieve this, we have added a display driver to op-tee and have allocated the frame buffers in op-tee too. > > We are conforming to the memory-map as layed out in .../core/arch/arm/include/mm/generic_ram_layout.h: > > TEE RAM layout without CFG_WITH_PAGER > > +----------------------------------+ <-- CFG_TZDRAM_START > | TEE core secure RAM (TEE_RAM) | > +----------------------------------+ > | Trusted Application RAM (TA_RAM) | > +----------------------------------+ > | SDP test memory (optional) | > +----------------------------------+ <-- CFG_TZDRAM_START + CFG_TZDRAM_SIZE > > +----------------------------------+ <-- CFG_SHMEM_START > | Non-secure static SHM | > +----------------------------------+ <-- CFG_SHMEM_START + CFG_SHMEM_SIZE > > With this memory map in mind, we came up with the following solution: > > +----------------------------------+ <-- CFG_DRAM_BASE > | | > | Non-secure memory | > | | > +----------------------------------+ <-- CFG_TZDRAM_START > | TEE core secure RAM (TEE_RAM) | > +----------------------------------+ > | Trusted Application RAM (TA_RAM) | > +----------------------------------+ <-- CFG_POS_SEC_FB0_START > | Secure frame buffer 0 | > +----------------------------------+ <-- CFG_POS_SEC_FB1_START > | Secure frame buffer 1 | > +----------------------------------+ <-- CFG_SHMEM_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) > | Non-secure static SHM | > +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) > CFG_DDR_SIZE = 0x10000000 > CFG_SHMEM_SIZE = 0x00200000 > CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) > CFG_SEC_FB_SIZE = 0x00096000 > CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) > CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) > CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) > CFG_TZDRAM_SIZE = ($(CFG_SHMEM_START) - $(CFG_TZDRAM_START)) > > This solution keeps the frame buffers within the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE, but when booting the system, we notice an overlap between TA_RAM and both frame buffer areas: > > D/TC:0 dump_mmap_table:732 type TA_RAM va 0x88c00000..0x8a8fffff pa 0x8e100000..0x8fdfffff size 0x01d00000 (pgdir) > ... > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8ded4000..0x8df69fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8df6a000..0x8dffffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) > > Without fully comprehending how memory is allocated, we fear that this situation will allow TA's to be loaded into these frame buffer areas. > To mitigate this, we came up with this alternative: > > +----------------------------------+ <-- CFG_DRAM_BASE > | | > | Non-secure memory | > | | > +----------------------------------+ <-- CFG_TZDRAM_START > | TEE core secure RAM (TEE_RAM) | > +----------------------------------+ > | Trusted Application RAM (TA_RAM) | > +----------------------------------+ <-- CFG_POS_SEC_FB0_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) > | Secure frame buffer 0 | > +----------------------------------+ <-- CFG_POS_SEC_FB1_START > | Secure frame buffer 1 | > +----------------------------------+ <-- CFG_SHMEM_START > | Non-secure static SHM | > +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) > CFG_DDR_SIZE = 0x10000000 > CFG_SHMEM_SIZE = 0x00200000 > CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) > CFG_SEC_FB_SIZE = 0x00096000 > CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) > CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) > CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) > CFG_TZDRAM_SIZE = ($(CFG_POS_SEC_FB0_START) - $(CFG_TZDRAM_START)) > > This solution puts the frame buffers outside the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE so they no longer overlap with TA_RAM. However, when booting the system, op-tee panics: > > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c2d4000..0x8c369fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c36a000..0x8c3fffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) > ... > D/TC:0 dump_mmap_table:732 type TA_RAM va 0x8c400000..0x8dfd3fff pa 0x8e100000..0x8fcd3fff size 0x01bd4000 (smallpg) > ... > E/TC:0 0 check_phys_mem_is_outside:332 Non-sec mem (0x8fcd4000:0x12c000) overlaps map (type 12 0x8fd6a000:0x96000) > E/TC:0 0 Panic at core/arch/arm/mm/core_mmu.c:336 <check_phys_mem_is_outside> > E/TC:0 0 TEE load address @ 0x8e000000 > E/TC:0 0 Call stack: > E/TC:0 0 0x8e005621 > E/TC:0 0 0x8e01d397 > E/TC:0 0 0x8e005aaf > E/TC:0 0 0x8e004da7 > E/TC:0 0 0x8e000174 > > In this situation, the memory area intended for the frame buffers (0x8fd6a000:0x96000) is now implicitly regarded as non-secure RAM, regardless of us registering it as MEM_AREA_RAM_SEC in main.c: > > register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB0_START, CFG_SEC_FB_SIZE); > register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB1_START, CFG_SEC_FB_SIZE); > > Could you please confirm (or deny) that our first solution is the proper way to allocate these secure frame buffers and that they will not be overwritten by the process of loading TAs? It looks like something went wrong in the first solution. The failure in the last solution is because OP-TEE thinks that you've accidentally tried to configure non-secure memory as secure memory. > If this is not the proper way, could you give us some pointers on how to do this? We do not feel comfortable allocating such large areas on the heap because of good taste and because we're not sure yet whether or not there are additional alignment requirement for these frame buffers. Perhaps something similar to the Linux slab-allocator is available? I think the easiest is to allocate memory from the pool used for TAs with: mm = tee_mm_alloc(&tee_mm_sec_ddr, size); Until this mm is freed no one else will use the memory it represents. Returned memory is page aligned (based on CORE_MMU_USER_CODE_SHIFT). This depends on paging being disabled, which it seems it is for the IMX platforms. If paging would have been enabled this memory might have been less secure than what you require, depending on how the platform is configured. Cheers, Jens

5 years, 6 months

2
3
0 0

Linaro OP-TEE Contributions meeting October 2020

by Joakim Bech

Hi, LOC monthly meeting is planned to take place October 28th @ 16.00 (UTC+1). Connection details can be found in the meeting notes document (link below). Ilias and Jens will give an introduction to the secure partitions and StandaloneMM parts in OP-TEE. Other than that feel free to suggest topics you'd like to discuss (by replying to this email or write it directly in the meeting notes). Note that it's UTC+1 since we're moving to winter time in Sweden in a couple of days from now (previous LOC meetings have been UTC+2). Meeting details: --------------- Date/time: Wednesday October 28th(a)16.00 (UTC+1) https://everytimezone.com/s/9bfdb976 Invitation/connection details: In the meeting notes 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

5 years, 6 months

1
3
0 0

Secure memory allocation

by Robert Deliën

Hi, We are using op-tee 3.10 in our i.MX6UL-based product and we are running into a small problem we hope you can help us out with. Apologies for the large mail; It's mostly pictures. The nature of our product requires us to protect access to the display contents. To achieve this, we have added a display driver to op-tee and have allocated the frame buffers in op-tee too. We are conforming to the memory-map as layed out in .../core/arch/arm/include/mm/generic_ram_layout.h: TEE RAM layout without CFG_WITH_PAGER +----------------------------------+ <-- CFG_TZDRAM_START | TEE core secure RAM (TEE_RAM) | +----------------------------------+ | Trusted Application RAM (TA_RAM) | +----------------------------------+ | SDP test memory (optional) | +----------------------------------+ <-- CFG_TZDRAM_START + CFG_TZDRAM_SIZE +----------------------------------+ <-- CFG_SHMEM_START | Non-secure static SHM | +----------------------------------+ <-- CFG_SHMEM_START + CFG_SHMEM_SIZE With this memory map in mind, we came up with the following solution: +----------------------------------+ <-- CFG_DRAM_BASE | | | Non-secure memory | | | +----------------------------------+ <-- CFG_TZDRAM_START | TEE core secure RAM (TEE_RAM) | +----------------------------------+ | Trusted Application RAM (TA_RAM) | +----------------------------------+ <-- CFG_POS_SEC_FB0_START | Secure frame buffer 0 | +----------------------------------+ <-- CFG_POS_SEC_FB1_START | Secure frame buffer 1 | +----------------------------------+ <-- CFG_SHMEM_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) | Non-secure static SHM | +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) CFG_DDR_SIZE = 0x10000000 CFG_SHMEM_SIZE = 0x00200000 CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) CFG_SEC_FB_SIZE = 0x00096000 CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) CFG_TZDRAM_SIZE = ($(CFG_SHMEM_START) - $(CFG_TZDRAM_START)) This solution keeps the frame buffers within the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE, but when booting the system, we notice an overlap between TA_RAM and both frame buffer areas: D/TC:0 dump_mmap_table:732 type TA_RAM va 0x88c00000..0x8a8fffff pa 0x8e100000..0x8fdfffff size 0x01d00000 (pgdir) ... D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8ded4000..0x8df69fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8df6a000..0x8dffffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) Without fully comprehending how memory is allocated, we fear that this situation will allow TA's to be loaded into these frame buffer areas. To mitigate this, we came up with this alternative: +----------------------------------+ <-- CFG_DRAM_BASE | | | Non-secure memory | | | +----------------------------------+ <-- CFG_TZDRAM_START | TEE core secure RAM (TEE_RAM) | +----------------------------------+ | Trusted Application RAM (TA_RAM) | +----------------------------------+ <-- CFG_POS_SEC_FB0_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) | Secure frame buffer 0 | +----------------------------------+ <-- CFG_POS_SEC_FB1_START | Secure frame buffer 1 | +----------------------------------+ <-- CFG_SHMEM_START | Non-secure static SHM | +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) CFG_DDR_SIZE = 0x10000000 CFG_SHMEM_SIZE = 0x00200000 CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) CFG_SEC_FB_SIZE = 0x00096000 CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) CFG_TZDRAM_SIZE = ($(CFG_POS_SEC_FB0_START) - $(CFG_TZDRAM_START)) This solution puts the frame buffers outside the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE so they no longer overlap with TA_RAM. However, when booting the system, op-tee panics: D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c2d4000..0x8c369fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c36a000..0x8c3fffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) ... D/TC:0 dump_mmap_table:732 type TA_RAM va 0x8c400000..0x8dfd3fff pa 0x8e100000..0x8fcd3fff size 0x01bd4000 (smallpg) ... E/TC:0 0 check_phys_mem_is_outside:332 Non-sec mem (0x8fcd4000:0x12c000) overlaps map (type 12 0x8fd6a000:0x96000) E/TC:0 0 Panic at core/arch/arm/mm/core_mmu.c:336 <check_phys_mem_is_outside> E/TC:0 0 TEE load address @ 0x8e000000 E/TC:0 0 Call stack: E/TC:0 0 0x8e005621 E/TC:0 0 0x8e01d397 E/TC:0 0 0x8e005aaf E/TC:0 0 0x8e004da7 E/TC:0 0 0x8e000174 In this situation, the memory area intended for the frame buffers (0x8fd6a000:0x96000) is now implicitly regarded as non-secure RAM, regardless of us registering it as MEM_AREA_RAM_SEC in main.c: register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB0_START, CFG_SEC_FB_SIZE); register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB1_START, CFG_SEC_FB_SIZE); Could you please confirm (or deny) that our first solution is the proper way to allocate these secure frame buffers and that they will not be overwritten by the process of loading TAs? If this is not the proper way, could you give us some pointers on how to do this? We do not feel comfortable allocating such large areas on the heap because of good taste and because we're not sure yet whether or not there are additional alignment requirement for these frame buffers. Perhaps something similar to the Linux slab-allocator is available? Thank you in advance for your help. With kind regards, Robert Deliën.

5 years, 6 months

1
0
0 0

[PATCH] optee: extend normal memory check to also write-through

by Andrey Zhizhikin

ARMv7 Architecture Reference Manual [1] section A3.5.5 details Normal memory type, together with cacheability attributes that could be applied to memory regions defined as "Normal memory". Section B2.1.2 of the Architecture Reference Manual [1] also provides details regarding the Memory attributes that could be assigned to particular memory regions, which includes the descrption of cacheability attributes and cache allocation hints. Memory type and cacheability attributes forms 2 separate definitions, where cacheability attributes defines a mechanism of coherency control rather than the type of memory itself. In other words: Normal memory type can be configured with several combination of cacheability attributes, namely: - Write-Through (WT) - Write-Back (WB) followed by cache allocation hint: - Write-Allocate - No Write-Allocate (also known as Read-Allocate) Those types are mapped in the kernel to corresponding macros: - Write-Through: L_PTE_MT_WRITETHROUGH - Write-Back Write-Allocate: L_PTE_MT_WRITEALLOC - Write-Back Read-Allocate: L_PTE_MT_WRITEBACK Current implementation of the op-tee driver takes in account only 2 last memory region types, while performing a check if the memory block is allocated as "Normal memory", leaving Write-Through allocations to be not considered. Extend verification mechanism to include also Normal memory regios, which are designated with Write-Through cacheability attributes. Link: [1]: https://developer.arm.com/documentation/ddi0406/cd Fixes: 853735e40424 ("optee: add writeback to valid memory type") Cc: stable(a)vger.kernel.org Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin(a)leica-geosystems.com> --- drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index c981757ba0d4..8da27d02a2d6 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -535,7 +535,8 @@ static bool is_normal_memory(pgprot_t p) { #if defined(CONFIG_ARM) return (((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC) || - ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK)); + ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK) || + ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITETHROUGH)); #elif defined(CONFIG_ARM64) return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); #else -- 2.17.1

5 years, 6 months

3
4
0 0

[GIT PULL] OP-TEE driver for v5.11

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch which allows the OP-TEE driver to work with ARMv7 based single CPU systems. Thanks, Jens The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891: Linux 5.10-rc2 (2020-11-01 14:43:51 -0800) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-valid-memory-type-for-v5.11 for you to fetch changes up to 853735e404244f5496cdb6188c5ed9a0f9627ee6: optee: add writeback to valid memory type (2020-11-25 12:51:52 +0100) ---------------------------------------------------------------- Add writeback to valid OP-TEE shared memory types Allows OP-TEE to work with ARMv7 based single CPU systems by allowing writeback cache policy for shared memory. ---------------------------------------------------------------- Rui Miguel Silva (1): optee: add writeback to valid memory type drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

5 years, 6 months

2
2
0 0

[PATCH] optee: add writeback to valid memory type

by Rui Miguel Silva

Only in smp systems the cache policy is setup as write alloc, in single cpu systems the cache policy is set as writeback and it is normal memory, so, it should pass the is_normal_memory check in the share memory registration. Add the right condition to make it work in no smp systems. Fixes: cdbcf83d29c1 ("tee: optee: check type of registered shared memory") Signed-off-by: Rui Miguel Silva <rui.silva(a)linaro.org> --- drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 20b6fd7383c5..c981757ba0d4 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -534,7 +534,8 @@ void optee_free_pages_list(void *list, size_t num_entries) static bool is_normal_memory(pgprot_t p) { #if defined(CONFIG_ARM) - return (pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC; + return (((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC) || + ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK)); #elif defined(CONFIG_ARM64) return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); #else -- 2.29.2

5 years, 7 months

2
1
0 0

[PATCH] Properly check tee_shm buffer mmap offset

by gaoyusong

The memmap options in tee_shm_op_mmap were not being checked for all sets of possible crazy values. Fix this up by properly check tee_shm buffer offsets. Signed-off-by: gaoyusong <a869920004(a)163.com> --- drivers/tee/tee_shm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 827ac3d..3f762c8 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -75,6 +75,16 @@ static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) { struct tee_shm *shm = dmabuf->priv; size_t size = vma->vm_end - vma->vm_start; + unsigned long offset; + + /* Check dmabuffer mmap offset */ + if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT)) + return -EINVAL; + + offset = vma->vm_pgoff << PAGE_SHIFT; + + if (offset > shm->size || size > shm->size - offset) + return -EINVAL; /* Refuse sharing shared memory provided by application */ if (shm->flags & TEE_SHM_USER_MAPPED) -- 1.8.3.1

5 years, 7 months

2
1
0 0

[GIT PULL] AMDTEE driver fixes for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull these AMDTEE driver fixes which are needed when opening multiple contexts or file descriptors. Note that this isn't a usual Arm driver update. This targets x86/AMD instead, but is still part of the TEE subsystem. Thanks, Jens The following changes since commit bbf5c979011a099af5dc76498918ed7df445635b: Linux 5.9 (2020-10-11 14:15:50 -0700) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/amdtee-fixes-for-5.10 for you to fetch changes up to be353be27874f40837327d9a39e3ad2149ab66d3: tee: amdtee: synchronize access to shm list (2020-11-09 08:59:00 +0100) ---------------------------------------------------------------- AMD-TEE driver bug fixes AMD-TEE driver keeps track of shared memory buffers and their corresponding buffer id's in a global linked list. These buffers are used to share data between x86 and AMD Secure Processor. This pull request fixes issues related to maintaining mapped buffers in a shared linked list. ---------------------------------------------------------------- Rijo Thomas (2): tee: amdtee: fix memory leak due to reset of global shm list tee: amdtee: synchronize access to shm list drivers/tee/amdtee/amdtee_private.h | 8 ++++---- drivers/tee/amdtee/core.c | 26 +++++++++++++++++++------- 2 files changed, 23 insertions(+), 11 deletions(-)

5 years, 7 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE