There is export_uuid() function which exports uuid_t to the u8 array.
Use it instead of open coding variant.
This allows to hide the uuid_t internals.
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
---
drivers/tee/optee/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
index e3a148521ec1d..2ecc6993f48bb 100644
--- a/drivers/tee/optee/device.c
+++ b/drivers/tee/optee/device.c
@@ -107,7 +107,7 @@ int optee_enumerate_devices(void)
return -ENODEV;
/* Open session with device enumeration pseudo TA */
- memcpy(sess_arg.uuid, pta_uuid.b, TEE_IOCTL_UUID_LEN);
+ export_uuid(sess_arg.uuid, &pta_uuid);
sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
sess_arg.num_params = 0;
--
2.26.1
Hello arm-soc maintainers,
Please pull this small patch converting the tee subsystem to use
pin_user_pages() instead of get_user_pages().
Thanks,
Jens
The following changes since commit ae83d0b416db002fe95601e7f97f64b59514d936:
Linux 5.7-rc2 (2020-04-19 14:35:30 -0700)
are available in the Git repository at:
git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/tee-pin-user-pages-for-5.8
for you to fetch changes up to 37f6b4d5f47b600ec4ab6682c005a44a1bfca530:
tee: convert get_user_pages() --> pin_user_pages() (2020-05-26 10:42:41 +0200)
----------------------------------------------------------------
Converts tee subsystem to use pin_user_pages() instead of get_user_pages()
----------------------------------------------------------------
John Hubbard (1):
tee: convert get_user_pages() --> pin_user_pages()
drivers/tee/tee_shm.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
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