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
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
Hi All,
While enabling trusty os with xen, I took same approach as OP-TEE,
with OP-TEE running in secure world. But I am also thinking this might
introduce potential issue is that secure world OS communicate with DomU.
If there are some misbehavior in secure world OS, it might let XEN
hypervisor not work proper.
In my setup, trusty os sometimes panic in secure world, xen will not able
to control the panic core anymore.
So I am thinking whether we need to emulating secure world in a XEN VM
which is the VM running DomU. Just like what ACRN did to run trusty
os.
Any comments?
Thanks,
Peng.
Normal World can share buffer with OP-TEE for two reasons:
1. Some client application wants to exchange data with TA
2. OP-TEE asks for shared buffer for internal needs
The second case was handle more strictly than necessary:
1. In RPC request OP-TEE asks for buffer
2. NW allocates buffer and provides it via RPC response
3. Xen pins pages and translates data
4. Xen provides buffer to OP-TEE
5. OP-TEE uses it
6. OP-TEE sends request to free the buffer
7. NW frees the buffer and sends the RPC response
8. Xen unpins pages and forgets about the buffer
The problem is that Xen should forget about buffer in between stages 6
and 7. I.e. the right flow should be like this:
6. OP-TEE sends request to free the buffer
7. Xen unpins pages and forgets about the buffer
8. NW frees the buffer and sends the RPC response
This is because OP-TEE internally frees the buffer before sending the
"free SHM buffer" request. So we have no reason to hold reference for
this buffer anymore. Moreover, in multiprocessor systems NW have time
to reuse buffer cookie for another buffer. Xen complained about this
and denied the new buffer registration. I have seen this issue while
running tests on iMX SoC.
So, this patch basically corrects that behavior by freeing the buffer
earlier, when handling RPC return from OP-TEE.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk(a)epam.com>
---
xen/arch/arm/tee/optee.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 6a035355db..af19fc31f8 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -1099,6 +1099,26 @@ static int handle_rpc_return(struct optee_domain *ctx,
if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_ALLOC )
call->rpc_buffer_type = shm_rpc->xen_arg->params[0].u.value.a;
+ /*
+ * OP-TEE signals that it frees the buffer that it requested
+ * before. This is the right for us to do the same.
+ */
+ if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_FREE )
+ {
+ uint64_t cookie = shm_rpc->xen_arg->params[0].u.value.b;
+
+ free_optee_shm_buf(ctx, cookie);
+
+ /*
+ * This should never happen. We have a bug either in the
+ * OP-TEE or in the mediator.
+ */
+ if ( call->rpc_data_cookie && call->rpc_data_cookie != cookie )
+ gprintk(XENLOG_ERR,
+ "Saved RPC cookie does not corresponds to OP-TEE's (%"PRIx64" != %"PRIx64")\n",
+ call->rpc_data_cookie, cookie);
+ call->rpc_data_cookie = 0;
+ }
unmap_domain_page(shm_rpc->xen_arg);
}
@@ -1464,10 +1484,6 @@ static void handle_rpc_cmd(struct optee_domain *ctx, struct cpu_user_regs *regs,
}
break;
case OPTEE_RPC_CMD_SHM_FREE:
- free_optee_shm_buf(ctx, shm_rpc->xen_arg->params[0].u.value.b);
- if ( call->rpc_data_cookie ==
- shm_rpc->xen_arg->params[0].u.value.b )
- call->rpc_data_cookie = 0;
break;
default:
break;
--
2.25.0
v9: - new mailing list in Docs, update kernel version (Jens Wiklander)
- use Big Endian format to print UUID (Sumit Garg)
v8: - fix v7 check.
v7: - check return value of dev_set_name() (Jarkko Sakkinen)
v6: - description, comments, patches reorder and destroy workqueue (Sumit Garg)
v5: - removed pr_err and fix typos in description (Jarkko Sakkinen)
- added missed kfree in optee_open()
v4: - sysfs entry is optee-ta-uuid (Jerome Forissier, Sumit Garg)
- added Documentation/ABI/testing/sysfs-bus-optee-devices (Greg Kroah-Hartman)
v3: - support tee-suppicant restart (Jens Wiklander)
- description and comments (Jarkko Sakkinen)
- do not name optee drivers by index in sysfs (Sumit Garg)
v2: - write TEE with capital letters.
- declare __optee_enumerate_device() as static.
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
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
.../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
--
2.17.1
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