- OP-TEE - lists.trustedfirmware.org

by Ran Wang

This patch add ACPI support for optee driver. Signed-off-by: Ran Wang <ran.wang_1(a)nxp.com> --- drivers/tee/optee/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index cf4718c6d35d..8fb261f4b9db 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -5,6 +5,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <linux/acpi.h> #include <linux/arm-smccc.h> #include <linux/errno.h> #include <linux/io.h> @@ -735,12 +736,21 @@ static const struct of_device_id optee_dt_match[] = { }; MODULE_DEVICE_TABLE(of, optee_dt_match); +#ifdef CONFIG_ACPI +static const struct acpi_device_id optee_acpi_match[] = { + { "OPTEE01",}, + { }, +}; +MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match); +#endif + static struct platform_driver optee_driver = { .probe = optee_probe, .remove = optee_remove, .driver = { .name = "optee", .of_match_table = optee_dt_match, + .acpi_match_table = ACPI_PTR(optee_acpi_match), }, }; module_platform_driver(optee_driver); -- 2.25.1

3 years, 6 months

3
5
0 0

EHF + OPTEE on ARM64

by Peng Fan

Hi, In bl31/ehf.c, there are following two lines, per my understanding, when cpu is in secure world, the non-secure interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 /* Route EL3 interrupts when in Secure and Non-secure. */ set_interrupt_rm_flag(flags, NON_SECURE); set_interrupt_rm_flag(flags, SECURE); So this will conflict with OP-TEE, because OP-TEE needs catch NS-interrupt as FIQ in S-EL1 world. Am I understand correct? Any ideas how we could address this to make EHF + OPTEE run together? Thanks Peng.

3 years, 6 months

2
7
0 0

Re: EHF + OPTEE on ARM64

by Jelle Sels

Hi, If I am not mistaking, the fiq handler should be opteed_sel1_interrupt_handler which will forward the interrupt to S-EL1. R, Jelle ________________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: Tuesday, March 16, 2021 11:08 To: op-tee(a)lists.trustedfirmware.org; Jens Wiklander; Joakim Bech Subject: EHF + OPTEE on ARM64 Hi, In bl31/ehf.c, there are following two lines, per my understanding, when cpu is in secure world, the non-secure interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 /* Route EL3 interrupts when in Secure and Non-secure. */ set_interrupt_rm_flag(flags, NON_SECURE); set_interrupt_rm_flag(flags, SECURE); So this will conflict with OP-TEE, because OP-TEE needs catch NS-interrupt as FIQ in S-EL1 world. Am I understand correct? Any ideas how we could address this to make EHF + OPTEE run together? Thanks Peng.

3 years, 6 months

1
0
0 0

[PATCH] drivers: tee: optee: removed repeated words in comments

by Anupama K Patil

the word "the" is repeated in the file core.c so it has been removed. Likewise the word "of" is repeated in optee_smc.h and have removed it. Signed-off-by: Anupama K Patil <anupamakpatil123(a)gmail.com> --- drivers/tee/optee/core.c | 2 +- drivers/tee/optee/optee_smc.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index cf4718c6d35d..2ccb091cd643 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -422,7 +422,7 @@ static bool optee_msg_exchange_capabilities(optee_invoke_fn *invoke_fn, /* * TODO This isn't enough to tell if it's UP system (from kernel - * point of view) or not, is_smp() returns the the information + * point of view) or not, is_smp() returns the information * needed, but can't be called directly from here. */ if (!IS_ENABLED(CONFIG_SMP) || nr_cpu_ids == 1) diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 80eb763a8a80..49e8e027dc5b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -162,7 +162,7 @@ struct optee_smc_call_get_os_revision_result { * Have config return register usage: * a0 OPTEE_SMC_RETURN_OK * a1 Physical address of start of SHM - * a2 Size of of SHM + * a2 Size of SHM * a3 Cache settings of memory, as defined by the * OPTEE_SMC_SHM_* values above * a4-7 Preserved -- 2.25.1

3 years, 6 months

1
0
0 0

Re: Request for support opensource optee contribution guide line

by Jens Wiklander

Hi Raghu, On Wed, Mar 3, 2021 at 8:38 AM Yejerla, VeeraraghavuluX via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > 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? That depends, it might be good to start with something small as a first contribution. > 2. What are the code guide line I have to follow it? https://optee.readthedocs.io/en/latest/general/coding_standards.html > 3. What are mail chain I have to include for patch review purpose? > 4. Is there any open source link for post quarry ? See https://optee.readthedocs.io/en/latest/general/contribute.html Cheers, Jens

3 years, 7 months

1
0
0 0

Re: Linaro OP-TEE Contributions meeting February 2021

by Jens Wiklander

Hi, On Fri, Feb 26, 2021 at 9:50 AM Jérôme Forissier via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > 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. Yes, the kernel part is the hard part here. Cheers, Jens

3 years, 7 months

1
0
0 0

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

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

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

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

3 years, 7 months

3
14
0 0

2024

2023

2022

2021

2020

OP-TEE