From: Jann Horn <jannh(a)google.com>
Bump the file's refcount before moving the reference into the fd table,
not afterwards. The old code could drop the file's refcount to zero for a
short moment before calling get_file() via get_dma_buf().
This code can only be triggered on ARM systems that use Linaro's OP-TEE.
Fixes: 967c9cca2cc5 ("tee: generic TEE subsystem")
Signed-off-by: Jann Horn <jannh(a)google.com>
Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>
---
drivers/tee/tee_shm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 556960a1bab3..07d3be6f0780 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -360,9 +360,10 @@ int tee_shm_get_fd(struct tee_shm *shm)
if (!(shm->flags & TEE_SHM_DMA_BUF))
return -EINVAL;
+ get_dma_buf(shm->dmabuf);
fd = dma_buf_fd(shm->dmabuf, O_CLOEXEC);
- if (fd >= 0)
- get_dma_buf(shm->dmabuf);
+ if (fd < 0)
+ dma_buf_put(shm->dmabuf);
return fd;
}
--
2.17.0
Hello,
I would like to know the kind of information that a Trusted Application
know about the client applications that interact with them? Is there a way
for a TA to distinguish between two client applications?
If the TA has no knowledge about CAs, how about the OPTEE kernel? Does the
kernel know any information that can differentiate between client
applications??
Thank you,
Francis
Hello OP-TEE contributors and maintainers,
We are on our way to OP-TEE release 3.1.0.
I have created a release candidate tag (3.1.0-rc1) in the various
OP-TEE repositories (optee_os, optee_client, optee_test,
optee_examples).
Please help with testing on your favorite platform and report success
(Tested-by:) or issues in the "changelog" pull request [1].
[1] https://github.com/OP-TEE/optee_os/pull/2235
Thanks for your help and support,
Jens
OP-TEE Maintainer
Hello,
I have a question about hardware acceleration of cryptography in OP-TEE.
I know that some platforms has ARM CryptoCell support. AFAIK, all
documentation on this topic is closed and (in some cases) under export
restrictions. So only way to use CryptoCell is to somehow obtain
binary library from ARM.
So, do you have any information on this topic? Is it possible to use
HW accelerators in OP-TEE? What is required for this?
--
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk(a)gmail.com
when the current process is doing a rpc call from optee, and if there
is a signal pending on the process, it will enter dead loop if the
tee-supplicant is working correctly, fix the problem by breaking out
the loop when the rpc job is finished.
Signed-off-by: Zeng Tao <prime.zeng(a)hisilicon.com>
---
drivers/tee/optee/supp.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c
index b4ea067..170dedb 100644
--- a/drivers/tee/optee/supp.c
+++ b/drivers/tee/optee/supp.c
@@ -107,6 +107,13 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params,
mutex_unlock(&supp->ctx_mutex);
if (interruptable)
break;
+
+ /*
+ * if there is signal pending, and the supplicant has finished
+ * the rpc job, we need to break out the loop
+ */
+ if (try_wait_for_completion(&supp->data_from_supp))
+ break;
}
ret = supp->ret;
--
2.7.4
Hello TEE POCs:
We came across Jens' 2015 patch:
https://github.com/linaro-swg/linux/commit/b8d05a0934b2
What is the status of the kernel client API below? Is it slated to go
upstream in the 4.16 or 4.17 kernel?
I ask because we have use cases that, if ported to the Generic TEE
interface, may require tee_shm_alloc() and friends to be available for use
cases such as the Linux soc-specific kernel entropy manager requesting TEE
side to provide PRNG data. The above patch would be a good starting point.
For instance, we were looking at using the following two APIs from Jens'
patch to open and close context objects. They will enable the clients to use
"tee_shm_alloc".
Cheers,
-thomas
Hi Guys,
I see fix for Variant3/meltdown is almost there. Congrats, that's quick.
Do you know of any device that officially supported and vulnerable to
variant 3?
Kris
Hi,
We shall be releasing OP-TEE 3.0.0 soon, so if you have pending pull
requests you'd like merged, please update them ASAP. Target date for the
release was January 19th but we may slip a bit due to Spectre and Meltdown.
As soon as the vulnerability patches are in, I'll create a -rc1 tag.
Thanks,
--
Jerome
Hi,
These two patches complements the previously posted patchset
"tee: optee: add dynamic shared memory support"
https://lwn.net/Articles/740242/
Tests are added to see that the registered shared memory cache attributes
are compatible with OP-TEE in secure world. Under normal circumstances they
will be compatible, but if memory has been previously mapped from a device
with special page attributes it could lead to trouble.
Thanks,
Jens
Jens Wiklander (2):
tee: add start argument to shm_register callback
tee: optee: check type of registered shared memory
drivers/tee/optee/call.c | 50 +++++++++++++++++++++++++++++++++++----
drivers/tee/optee/optee_private.h | 6 +++--
drivers/tee/tee_shm.c | 2 +-
include/linux/tee_drv.h | 3 ++-
4 files changed, 53 insertions(+), 8 deletions(-)
--
2.14.1