- OP-TEE - lists.trustedfirmware.org

[PATCHv3 2/2] hwrng: optee: fix wait use case

by Jorge Ramirez-Ortiz

The current code waits for data to be available before attempting a second read. However the second read would not be executed as the while loop will exit. This fix does not wait if all data has been read (skips the call to msleep(0)) and reads a second time if partial data was retrieved on the first read. Worth noticing that since msleep(0) schedules a one jiffy timeout is better to skip such a call. Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/char/hw_random/optee-rng.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c index 5bc4700c4dae..a99d82949981 100644 --- a/drivers/char/hw_random/optee-rng.c +++ b/drivers/char/hw_random/optee-rng.c @@ -122,14 +122,14 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) if (max > MAX_ENTROPY_REQ_SZ) max = MAX_ENTROPY_REQ_SZ; - while (read == 0) { + while (read < max) { rng_size = get_optee_rng_data(pvt_data, data, (max - read)); data += rng_size; read += rng_size; if (wait && pvt_data->data_rate) { - if (timeout-- == 0) + if ((timeout-- == 0) || (read == max)) return read; msleep((1000 * (max - read)) / pvt_data->data_rate); } else { -- 2.17.1

5 years, 9 months

1
0
0 0

[PATCHv2 1/2] hwrng: optee: handle unlimited data rates

by Jorge Ramirez-Ortiz

Data rates of MAX_UINT32 will schedule an unnecessary one jiffy timeout on the call to msleep. Avoid this scenario by using 0 as the unlimited data rate. Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> --- drivers/char/hw_random/optee-rng.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c index 49b2e02537dd..5bc4700c4dae 100644 --- a/drivers/char/hw_random/optee-rng.c +++ b/drivers/char/hw_random/optee-rng.c @@ -128,7 +128,7 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) data += rng_size; read += rng_size; - if (wait) { + if (wait && pvt_data->data_rate) { if (timeout-- == 0) return read; msleep((1000 * (max - read)) / pvt_data->data_rate); -- 2.17.1

5 years, 9 months

3
13
0 0

PSA OP-TEE development

by Miklos Balint

Hi, In parallel with - and based on - the work by Jens to enable PSA FF-A as a transport for the SMC ABI (recently merged to the upstream as PR #3908) there's an effort to provide a fully-functional SPMC component in OP-TEE to manage S-EL0 Secure Partitions, with the goal of providing a similar set of PSA Root of Trust services over OP-TEE as presently supported for M-profile processors, while also providing a standard execution framework and ABI for potential integration of 3rd party partitions, such as StMM. Please note that this work is currently at the prototyping stage and is managed as a fork on trustedfirmware.org, but is planned to be merged with the official OP-TEE stream as it matures. There's an initial set of patches on review to provide * A library for S-EL0 SPs to access FF-A ABI at the SVC call interface: https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4751 * A change to introduce an SP build system to OP-TEE: https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4752 * OP-TEE kernel changes to support initialization and context management of SPs and the forwarding of FF-A messages to their designated endpoints: https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4987 All related open reviews at the moment can be found here: https://review.trustedfirmware.org/q/project:OP-TEE%252Foptee_os+status:open For the S-EL1 SPMC configuration functionality and requirements see the PSA FF-A specification (https://developer.arm.com/documentation/den0077/latest) Work is in progress to showcase the capabilities of the framework using a subset of PSA Crypto API and also to propose a standardized protocol layer for partitions, but as mentioned work is still at the early stages so expect gradual increments in functionality and flexibility. Any questions and feedback are very welcome Cheers, Miklos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

1
0
0 0

Re: OP-TEE release dates?

by Joakim Bech

Hi Jerome, On Fri, Jul 24, 2020 at 02:57:34PM +0000, Jérôme Forissier via OP-TEE wrote: > Hi, > > Anyone know if the planned dates of OP-TEE releases are publicly available > somewhere? > Still a bit legacy regarding that, i.e., still tracked in the Linaro Jira instance. Even though the "Linaro OP-TEE Contributions" is publicly available, the release schedule seems to be locked down. > Readthedocs [1] documents that we do quarterly releases, but it would help > to have a more precise indication, at least for the next (upcoming) release. > Agree, I can replicate what we have in the Jira instance and put that on the release page you're referring to. > Can we count on 3.10.0 being made available by the end of August? > Yes, so it's about time to initiate the release work for that tag. As maintainers, let's sync up on that separately. Here are the dates for future releases. Version Start date Release date OP-TEE 3.10.0 23/May/20 21/Aug/20 OP-TEE 3.11.0 22/Aug/20 16/Oct/20 OP-TEE 3.12.0 17/Oct/20 15/Jan/21 OP-TEE 3.13.0 16/Jan/21 16/Apr/21 > [1] https://optee.readthedocs.io/en/latest/general/releases.html > > Thanks, > -- > Jerome > -- > OP-TEE mailing list > OP-TEE(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/op-tee -- Regards, Joakim

5 years, 9 months

2
2
0 0

OP-TEE release dates?

by Jérôme Forissier

Hi, Anyone know if the planned dates of OP-TEE releases are publicly available somewhere? Readthedocs [1] documents that we do quarterly releases, but it would help to have a more precise indication, at least for the next (upcoming) release. Can we count on 3.10.0 being made available by the end of August? [1] https://optee.readthedocs.io/en/latest/general/releases.html Thanks, -- Jerome

5 years, 10 months

1
0
0 0

Re: [PATCH] docs: staging/tee.rst: convert into definition list

by Jonathan Corbet

On Sat, 18 Jul 2020 13:50:58 -0300 "Daniel W. S. Almeida" <dwlsalmeida(a)gmail.com> wrote: > TEE bus infrastructure registers following APIs: > -- match(): iterates over the client driver UUID table to find a corresponding > - match for device UUID. If a match is found, then this particular device is > - probed via corresponding probe API registered by the client driver. This > - process happens whenever a device or a client driver is registered with TEE > - bus. > -- uevent(): notifies user-space (udev) whenever a new device is registered on > - TEE bus for auto-loading of modularized client drivers. > + > +match(): > + iterates over the client driver UUID table to find a corresponding > + match for device UUID. If a match is found, then this particular device is > + probed via corresponding probe API registered by the client driver. This > + process happens whenever a device or a client driver is registered with TEE > + bus. > + > +uevent(): > + notifies user-space (udev) whenever a new device is registered on > + TEE bus for auto-loading of modularized client drivers. Just FWIW, this could have been fixed by adding a blank line between the two bulleted entries. This fix is fine too, though, applied, thanks. jon

5 years, 10 months

1
0
0 0

[PATCH 1/2] hwrng: optee: handle unlimited data rates

by Jorge Ramirez-Ortiz

Data rates of MAX_UINT32 will schedule an unnecessary one jiffy timeout on the call to msleep. Avoid this scenario by using 0 as the unlimited data rate. Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> --- drivers/char/hw_random/optee-rng.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c index 49b2e02537dd..5bc4700c4dae 100644 --- a/drivers/char/hw_random/optee-rng.c +++ b/drivers/char/hw_random/optee-rng.c @@ -128,7 +128,7 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) data += rng_size; read += rng_size; - if (wait) { + if (wait && pvt_data->data_rate) { if (timeout-- == 0) return read; msleep((1000 * (max - read)) / pvt_data->data_rate); -- 2.17.1

5 years, 10 months

1
1
0 0

[GIT PULL] optee bus for v5.9

by Jens Wiklander

Hello arm-soc maintainers, Please pull these patches enabling multi-stage OP-TEE bus enumeration and also adds a TPM driver for a OP-TEE based fTPM Trusted Application. The TPM driver depends on and takes advantage of the multi-stage OP-TEE bus enumeration by indicating that it should be probed after tee-supplicant has been started. Jarkko, one of the TPM maintainers, has been involved in reviewing these patches and agrees that I can include the TPM patch in the pull request. Thanks, Jens The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162: Linux 5.7 (2020-05-31 16:49:15 -0700) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-bus-for-v5.9 for you to fetch changes up to 9f1944c23c8cb1c033b73de80cf6c612a2a80a2b: tpm_ftpm_tee: register driver on TEE bus (2020-07-10 09:41:58 +0200) ---------------------------------------------------------------- Enable multi-stage OP-TEE bus enumeration Probes drivers on the OP-TEE bus in two steps. First for drivers which do not depend on tee-supplicant. After tee-supplicant has been started probe the devices which do depend on tee-supplicant. Also introduces driver which uses an OP-TEE based fTPM Trusted Application depends on tee-supplicant NV RAM implementation based on RPMB secure storage. ---------------------------------------------------------------- Maxim Uvarov (3): optee: use uuid for sysfs driver entry optee: enable support for multi-stage bus enumeration tpm_ftpm_tee: register driver on TEE bus Documentation/ABI/testing/sysfs-bus-optee-devices | 8 +++ MAINTAINERS | 1 + drivers/char/tpm/tpm_ftpm_tee.c | 70 +++++++++++++++++++---- drivers/tee/optee/core.c | 27 ++++++++- drivers/tee/optee/device.c | 38 ++++++------ drivers/tee/optee/optee_private.h | 10 +++- 6 files changed, 119 insertions(+), 35 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices

5 years, 10 months

2
1
0 0

Re: OP-TEE Development Guidance

by Jens Wiklander

Hi Saad, On Thu, Jun 18, 2020 at 9:43 AM Muhammad Saad via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hello All, > > First, I hope you are safe and doing fine in the unfortunate COVID-19 situation. I am a Ph.D. student at the University of Central Florida. Currently, I am working on a TEE-based prototype application for a proof-of-concept. Since I am totally new in this domain, so it is taking some effort. I have a few questions and I hope you guys can help me in that. > > At present, I am able to set up OP-TEE on Qemu and run the examples on the normal world and the secure world. Additionally, I tweaked a few parameters (ie., the integer value in the main.c) for the CA and the addition and subtraction sequence in the TA. Upon building it again (cd/build/make all run), it seems to work. However, if I need to pass a normal string to the TA and the TA computes Sha256 of the string and returns the value, what steps do I need to take? In other words, how can I pass a tuple from the TA to the CA and obtain the Hash of the tuple. Additionally, if I am able to do that by tailoring the HelloWorld examples, how can I develop new CA and TA with unique UUID and perform the same procedure. Finally, instead of doing the entire (cd/build/make all run), is there a method by which I can simply build the application and alone and run it on Qemu? You can find an example of doing some hashing at https://github.com/OP-TEE/optee_test/blob/391168ec03980e1cc8fb6d3e3c4b42481… You'll need to look around a little to get the whole picture, but it shouldn't be too hard. If you only change a TA or some client application it's enough to rebuild with: make buildroot and then run it with: make run-only A new UUID can be obtained with the Linux command uuidgen. Cheers, Jens > > I understand that these must be trivial questions, however, I will deeply appreciate if you can help me in figuring them out. > > > Best, > > Saad > -- > OP-TEE mailing list > OP-TEE(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/op-tee

5 years, 10 months

2
2
0 0

[PATCH v2 0/2] optee: SHM handling fixes

by Volodymyr Babchuk

There are two patches that previously was mailed separatedly. Both patches fix issues found during testing the OP-TEE 3.9 release. Julien and Stefano suggested to include this patches in Xen 4.14 release, because optee support still in the preview state and those patches provide no new functionality, bugfixes only. Volodymyr Babchuk (2): optee: immediately free buffers that are released by OP-TEE optee: allow plain TMEM buffers with NULL address xen/arch/arm/tee/optee.c | 59 +++++++++++++++++++++++++++++++++++----- 1 file changed, 52 insertions(+), 7 deletions(-) -- 2.26.2

5 years, 10 months

4
10
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

5 years, 10 months

1
0
0 0

[op-tee] [PATCH v2] Documentation: tee: Document TEE kernel interface

by Sumit Garg

Update documentation with TEE bus infrastructure which provides an interface for kernel client drivers to communicate with corresponding Trusted Application. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v2: - Add TEE client driver example snippet. Documentation/tee.txt | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/Documentation/tee.txt b/Documentation/tee.txt index c8fad81..350dd40 100644 --- a/Documentation/tee.txt +++ b/Documentation/tee.txt @@ -53,6 +53,66 @@ clients, forward them to the TEE and send back the results. In the case of supplicants the communication goes in the other direction, the TEE sends requests to the supplicant which then sends back the result. +The TEE kernel interface +======================== + +Kernel provides a TEE bus infrastructure where a Trusted Application is +represented as a device identified via Universally Unique Identifier (UUID) and +client drivers register a table of supported device UUIDs. + +TEE bus infrastructure registers following APIs: +- match(): iterates over the client driver UUID table to find a corresponding + match for device UUID. If a match is found, then this particular device is + probed via corresponding probe API registered by the client driver. This + process happens whenever a device or a client driver is registered with TEE + bus. +- uevent(): notifies user-space (udev) whenever a new device is registered on + TEE bus for auto-loading of modularized client drivers. + +TEE bus device enumeration is specific to underlying TEE implementation, so it +is left open for TEE drivers to provide corresponding implementation. + +Then TEE client driver can talk to a matched Trusted Application using APIs +listed in include/linux/tee_drv.h. + +TEE client driver example +------------------------- + +Suppose a TEE client driver needs to communicate with a Trusted Application +having UUID: ``ac6a4085-0e82-4c33-bf98-8eb8e118b6c2``, so driver registration +snippet would look like:: + + static const struct tee_client_device_id client_id_table[] = { + {UUID_INIT(0xac6a4085, 0x0e82, 0x4c33, + 0xbf, 0x98, 0x8e, 0xb8, 0xe1, 0x18, 0xb6, 0xc2)}, + {} + }; + + MODULE_DEVICE_TABLE(tee, client_id_table); + + static struct tee_client_driver client_driver = { + .id_table = client_id_table, + .driver = { + .name = DRIVER_NAME, + .bus = &tee_bus_type, + .probe = client_probe, + .remove = client_remove, + }, + }; + + static int __init client_init(void) + { + return driver_register(&client_driver.driver); + } + + static void __exit client_exit(void) + { + driver_unregister(&client_driver.driver); + } + + module_init(client_init); + module_exit(client_exit); + OP-TEE driver ============= @@ -112,6 +172,14 @@ kernel are handled by the kernel driver. Other RPC messages will be forwarded to tee-supplicant without further involvement of the driver, except switching shared memory buffer representation. +OP-TEE device enumeration +------------------------- + +OP-TEE provides a pseudo Trusted Application: drivers/tee/optee/device.c in +order to support device enumeration. In other words, OP-TEE driver invokes this +application to retrieve a list of Trusted Applications which can be registered +as devices on the TEE bus. + AMD-TEE driver ============== -- 2.7.4

5 years, 11 months

4
5
0 0

OP-TEE Development Guidance

by Muhammad Saad

Hello All, First, I hope you are safe and doing fine in the unfortunate COVID-19 situation. I am a Ph.D. student at the University of Central Florida. Currently, I am working on a TEE-based prototype application for a proof-of-concept. Since I am totally new in this domain, so it is taking some effort. I have a few questions and I hope you guys can help me in that. At present, I am able to set up OP-TEE on Qemu and run the examples on the normal world and the secure world. Additionally, I tweaked a few parameters (ie., the integer value in the main.c) for the CA and the addition and subtraction sequence in the TA. Upon building it again (cd/build/make all run), it seems to work. However, if I need to pass a normal string to the TA and the TA computes Sha256 of the string and returns the value, what steps do I need to take? In other words, how can I pass a tuple from the TA to the CA and obtain the Hash of the tuple. Additionally, if I am able to do that by tailoring the HelloWorld examples, how can I develop new CA and TA with unique UUID and perform the same procedure. Finally, instead of doing the entire (cd/build/make all run), is there a method by which I can simply build the application and alone and run it on Qemu? I understand that these must be trivial questions, however, I will deeply appreciate if you can help me in figuring them out. Best, Saad

5 years, 11 months

1
0
0 0

[op-tee] [PATCH v5 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 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 entry for TEE based Trusted Keys Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++--- MAINTAINERS | 8 + include/keys/trusted-type.h | 48 ++++ include/keys/trusted_tee.h | 66 +++++ include/keys/trusted_tpm.h | 15 - security/keys/Kconfig | 31 +- security/keys/trusted-keys/Makefile | 6 +- security/keys/trusted-keys/trusted_core.c | 321 +++++++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 280 ++++++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 335 ++++------------------ 10 files changed, 981 insertions(+), 332 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, 11 months

4
13
0 0

[op-tee] [PATCH] MAINTAINERS: change tee mailing list

by Jens Wiklander

The old TEE mailing list tee-dev(a)lists.linaro.org is about to be retired. From now on please use op-tee(a)lists.trustedfirmware.org instead. Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 68f21d46614c..772448e36203 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12691,13 +12691,13 @@ F: arch/mips/boot/dts/ralink/omega2p.dts OP-TEE DRIVER M: Jens Wiklander <jens.wiklander(a)linaro.org> -L: tee-dev(a)lists.linaro.org +L: op-tee(a)lists.trustedfirmware.org S: Maintained F: drivers/tee/optee/ OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER M: Sumit Garg <sumit.garg(a)linaro.org> -L: tee-dev(a)lists.linaro.org +L: op-tee(a)lists.trustedfirmware.org S: Maintained F: drivers/char/hw_random/optee-rng.c @@ -16759,7 +16759,7 @@ F: include/media/i2c/tw9910.h TEE SUBSYSTEM M: Jens Wiklander <jens.wiklander(a)linaro.org> -L: tee-dev(a)lists.linaro.org +L: op-tee(a)lists.trustedfirmware.org S: Maintained F: Documentation/tee.txt F: drivers/tee/ -- 2.25.1

5 years, 11 months

2
1
0 0

[op-tee] Issue with __attribute__((constructor)) and -Os -fno-common

by Jerome Forissier

Hi, I think that Clang erroneously discards a function annotated with __attribute__((constructor)) when flags -Os -fno-common are given. Test case below. What do you think? Thanks. ----8<--------8<--------8<--------8<--------8<--------8<-------- $ cat ctor.c int val; static void __attribute__((constructor)) init_fn(void) { val = 1; } int main(int argc, char *argv[]) { return val; } ----8<--------8<--------8<--------8<--------8<--------8<-------- Here is what I observed: - Clang (10.0.0-4ubuntu1) with -Os -fno-common: function init_fn() is NOT emitted, - Clang (10.0.0-4ubuntu1) with no flag, or only -Os or -fno-common: init_fn() is present as expected, - GCC (Ubuntu 9.3.0-10ubuntu1) with the same flags: init_fn() is present too, - Since https://reviews.llvm.org/D75056, -fno-common is the default and therefore -Os is enough to cause the issue. ----8<--------8<--------8<--------8<--------8<--------8<-------- $ clang --target=arm-linux-gnueabihf -Os -fno-common -S ctor.c \ -o /dev/stdout | grep init_fn $ clang --target=arm-linux-gnueabihf -Os -S ctor.c \ -o /dev/stdout | grep init_fn .p2align 2 @ -- Begin function init_fn .type init_fn,%function .code 32 @ @init_fn init_fn: .size init_fn, .Lfunc_end0-init_fn .long init_fn(target1) .addrsig_sym init_fn $ clang --target=arm-linux-gnueabihf -fno-common -S ctor.c \ -o /dev/stdout | grep init_fn .p2align 2 @ -- Begin function init_fn .type init_fn,%function .code 32 @ @init_fn init_fn: .size init_fn, .Lfunc_end0-init_fn .long init_fn(target1) .addrsig_sym init_fn $ arm-linux-gnueabihf-gcc -Os -fno-common -S ctor.c \ -o /dev/stdout | grep init_fn .type init_fn, %function init_fn: .size init_fn, .-init_fn .word init_fn(target1) ----8<--------8<--------8<--------8<--------8<--------8<-------- -- Jerome

5 years, 11 months

4
5
0 0

[op-tee] [PATCH] Documentation: tee: Document TEE kernel interface

by Sumit Garg

Update documentation with TEE bus infrastructure which provides an interface for kernel client drivers to communicate with corresponding Trusted Application. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Documentation/tee.txt | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/Documentation/tee.txt b/Documentation/tee.txt index c8fad81..428d3b5 100644 --- a/Documentation/tee.txt +++ b/Documentation/tee.txt @@ -53,6 +53,28 @@ clients, forward them to the TEE and send back the results. In the case of supplicants the communication goes in the other direction, the TEE sends requests to the supplicant which then sends back the result. +The TEE kernel interface +======================== + +Kernel provides a TEE bus infrastructure where a Trusted Application is +represented as a device identified via Universally Unique Identifier (UUID) and +client drivers register a table of supported device UUIDs. + +TEE bus infrastructure registers following APIs: +- match(): iterates over the client driver UUID table to find a corresponding + match for device UUID. If a match is found, then this particular device is + probed via corresponding probe API registered by the client driver. This + process happens whenever a device or a client driver is registered with TEE + bus. +- uevent(): notifies user-space (udev) whenever a new device is registered on + TEE bus for auto-loading of modularized client drivers. + +TEE bus device enumeration is specific to underlying TEE implementation, so it +is left open for TEE drivers to provide corresponding implementation. + +Then TEE client driver can talk to a matched Trusted Application using APIs +listed in include/linux/tee_drv.h. + OP-TEE driver ============= @@ -112,6 +134,14 @@ kernel are handled by the kernel driver. Other RPC messages will be forwarded to tee-supplicant without further involvement of the driver, except switching shared memory buffer representation. +OP-TEE device enumeration +------------------------- + +OP-TEE provides a pseudo Trusted Application: drivers/tee/optee/device.c in +order to support device enumeration. In other words, OP-TEE driver invokes this +application to retrieve a list of Trusted Applications which can be registered +as devices on the TEE bus. + AMD-TEE driver ============== -- 2.7.4

5 years, 11 months

2
2
0 0

[op-tee] [PATCH v4 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 can be found here [1]. [1] https://github.com/OP-TEE/optee_os/pull/3838 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 entry for TEE based Trusted Keys Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++--- MAINTAINERS | 8 + include/keys/trusted-type.h | 48 ++++ include/keys/trusted_tee.h | 66 +++++ include/keys/trusted_tpm.h | 15 - security/keys/Kconfig | 3 + security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_common.c | 336 ++++++++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 282 ++++++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 335 ++++----------------- 10 files changed, 974 insertions(+), 324 deletions(-) create mode 100644 include/keys/trusted_tee.h create mode 100644 security/keys/trusted-keys/trusted_common.c create mode 100644 security/keys/trusted-keys/trusted_tee.c -- 2.7.4

5 years, 11 months

2
20
0 0

[op-tee] Aarch64: unaligned access despite -mstrict-align

by Jerome Forissier

Hi, I experienced a crash in code compiled with Clang 10.0.0 due to a misaligned 64-bit data access. The (ARMv8) CPU is configured with SCTL.A == 1 (alignment check enable). With SCTLR.A == 0 the code runs as expected. After some investigation I came up with the following reproducer: ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- $ cat test.c extern char *g; int memcmp(const void *s1, const void *s2, unsigned long n); int f(void *c) { return memcmp(g, c, 16); } $ clang --target=aarch64-linux-gnu -Os -mstrict-align -S test.c $ cat test.s .text .file "test.c" .globl f // -- Begin function f .p2align 2 .type f,@function f: // @f // %bb.0: adrp x8, g ldr x10, [x8, :lo12:g] ldr x9, [x0] ldr x8, [x10] rev x9, x9 rev x8, x8 cmp x8, x9 b.ne .LBB0_3 // %bb.1: ldr x8, [x10, #8] ldr x9, [x0, #8] rev x8, x8 rev x9, x9 cmp x8, x9 b.ne .LBB0_3 // %bb.2: mov w0, wzr ret .LBB0_3: cmp x8, x9 mov w8, #-1 cneg w0, w8, hs ret .Lfunc_end0: .size f, .Lfunc_end0-f // -- End function .ident "clang version 10.0.0-4ubuntu1 " .section ".note.GNU-stack","",@progbits .addrsig ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- Note the 'ldr x9, [x0]'. At this point there is no guarantee that x0 is a multiple of 8, so why is Clang generating this code? Thanks, -- Jerome

5 years, 11 months

4
6
0 0

[op-tee] Maximum line length in the Linux kernel

by Jérôme Forissier

FYI, the "80 column" rule has just evolved a bit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… So it is now s "<= 80 columns preferred, but up to 100 is OK". Since we are mostly following the Linux coding style, I think this should apply to OP-TEE as well. Personally, I think it's a good thing as it will help avoid some silly line breaks in long debug messages for instance. -- Jerome

5 years, 11 months

1
0
0 0

[op-tee] OP-TEE 3.9.0 has been released

by Jens Wiklander

[BCC all OP-TEE maintainers] Hi, FYI, I have just finalized the OP-TEE 3.9.0 release (changelog [1]). As always, thank you to everyone who contributed to OP-TEE and participated in testing this release [2]. [1] https://github.com/OP-TEE/optee_os/blob/3.9.0/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/af141c61fe7a2430f3b4bb89661d84141… Regards, Jens

5 years, 12 months

1
0
0 0

[op-tee] Preparing for OP-TEE 3.9.0

by Jens Wiklander

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, We're about to make another OP-TEE release, namely: 3.9.0. Target is Friday, May 22th which leaves us almost 3 weeks to finalize the release. Please start testing your favorite platform(s) and report any issue in this pull request [1]. I will create a release candidate tag one week before the release date, at which point we will do some more testing and I will collect Tested-by tags in the same pull request. [1] https://github.com/OP-TEE/optee_os/pull/3833 Thanks! Regards, Jens

6 years

1
1
0 0

[op-tee] [PATCH v2 0/3] tee: add support for session's client UUID generation

by Vesa Jääskeläinen

TEE Client API defines that from user space only information needed for specified login operations is group identifier for group based logins. REE kernel is expected to formulate trustworthy client UUID and pass that to TEE environment. REE kernel is required to verify that provided group identifier for group based logins matches calling processes group memberships. TEE specification only defines that the information passed from REE environment to TEE environment is encoded into on UUID. In order to guarantee trustworthiness of client UUID user space is not allowed to freely pass client UUID. Vesa Jääskeläinen (3): tee: add support for session's client UUID generation tee: optee: Add support for session login client UUID generation [RFC] tee: add support for app id for client UUID generation drivers/tee/Kconfig | 1 + drivers/tee/optee/call.c | 6 +- drivers/tee/tee_core.c | 211 +++++++++++++++++++++++++++++++++++++++ include/linux/tee_drv.h | 16 +++ 4 files changed, 233 insertions(+), 1 deletion(-) -- 2.17.1 Changes v1->v2: * Changed goto labels to be more logical * Capture error if formatted string for UUIDv5 does not fit into buffer Notes: This patcheset has been designed so that it can be iteratively intergrated meaning that the application ID (RFC patch) part can be left for later when there is agreed solution for that. TEE specification leaves Linux behavior undefined. It does not define any UUID value for name space. UUID in here is randomly generated with uuidgen tool. I have also include amdtee people as this method probably should also be applied in there. Using op-tee(a)lists.trustedfirmware.org instead of tee-dev(a)lists.linaro.org as latter is deprecated old list. Original issue in OP-TEE OS tracker: https://github.com/OP-TEE/optee_os/issues/3642 Related reviews and demonstration for the concept: https://github.com/linaro-swg/linux/pull/74 https://github.com/OP-TEE/optee_client/pull/195 https://github.com/OP-TEE/optee_test/pull/406

6 years

2
4
0 0

[op-tee] [PATCH 0/3] tee: add support for session's client UUID generation

by Vesa Jääskeläinen

TEE Client API defines that from user space only information needed for specified login operations is group identifier for group based logins. REE kernel is expected to formulate trustworthy client UUID and pass that to TEE environment. REE kernel is required to verify that provided group identifier for group based logins matches calling processes group memberships. TEE specification only defines that the information passed from REE environment to TEE environment is encoded into on UUID. In order to guarantee trustworthiness of client UUID user space is not allowed to freely pass client UUID. Vesa Jääskeläinen (3): tee: add support for session's client UUID generation tee: optee: Add support for session login client UUID generation [RFC] tee: add support for app id for client UUID generation drivers/tee/Kconfig | 1 + drivers/tee/optee/call.c | 6 +- drivers/tee/tee_core.c | 188 +++++++++++++++++++++++++++++++++++++++ include/linux/tee_drv.h | 16 ++++ 4 files changed, 210 insertions(+), 1 deletion(-) -- 2.17.1 Notes: This patcheset has been designed so that it can be iteratively intergrated meaning that the application ID (RFC patch) part can be left for later when there is agreed solution for that. TEE specification leaves Linux behavior undefined. It does not define any UUID value for name space. UUID in here is randomly generated with uuidgen tool. I have also include amdtee people as this method probably should also be applied in there. Using op-tee(a)lists.trustedfirmware.org instead of tee-dev(a)lists.linaro.org as latter is deprecated old list. Original issue in OP-TEE OS tracker: https://github.com/OP-TEE/optee_os/issues/3642 Related reviews and demonstration for the concept: https://github.com/linaro-swg/linux/pull/74 https://github.com/OP-TEE/optee_client/pull/195 https://github.com/OP-TEE/optee_test/pull/406

6 years

2
6
0 0

[op-tee] [PATCH v2 0/2] hw/arm/virt: dt: add kaslr-seed property

by Jerome Forissier

This patchset creates the DT property /chosen/kaslr-seed which is used by the OS for Address Space Layout Randomization. If the machine is secure, a similar property is created under /secure-chosen. Changes since v1: - Move creation of /secure-chosen to create_fdt() - Use qemu_guest_getrandom() instead of qcrypto_random_bytes() - Create kaslr-seed for the non-secure OS too Jerome Forissier (2): hw/arm/virt: dt: move creation of /secure-chosen to create_fdt() hw/arm/virt: dt: add kaslr-seed property hw/arm/virt.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) -- 2.20.1

6 years

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE