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
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
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
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
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
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
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)
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
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
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
