Open lorc opened 4 years ago
This small changes fixes the second issue. But I don't know if it the right way:
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 34409c916882..91584b066787 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -728,10 +728,8 @@ static int __init optee_driver_init(void)
return PTR_ERR(optee);
rc = optee_enumerate_devices();
- if (rc) {
- optee_remove(optee);
- return rc;
- }
+ if (rc)
+ pr_warn("can't enumerate optee_devices: %d\n", rc);
pr_info("initialized driver\n");
It uses old style TMEM arg even with dynamic SHM enabled. Xen is not happy about this
Right, it would make sense that driver uses RMEM when dynamic shm capability is supported.
This small changes fixes the second issue. But I don't know if it the right way:
I think your change is legitimate. OP-TEE does not mandate TA/PTA devices enumeration.
Drivers panics during optee_remove()
Indeed, that's bad.
2. If
optee_enumerate_devices()
fails,optee_driver_init()
fails. But actually optee can work without this feature. Does it means, than older OP-TEE versions are not supported anymore?
optee_enumerate_devices()
should not fail when "TEE device" enumeration is not supported by OP-TEE. It should simply enumerate nothing. I have checked that it is the case on QEMU if the PTA is not compiled in (CFG_DEVICE_ENUM_PTA=n
).
So it seems to me we have only (!) two issues here, not three.
(edited: rephrased)
@jforissier, you're right. Actually it is explicitly stated in the Linux driver. It should also does not fail if device PTA is found and it returns no device to enumerate: shm_size == 0.
Regarding device enumeration and TMEM: Looking into device.c, i can't see where TMEM is explicitly used. Looks like the driver allocates SHM.
optee_enumerate_devices() should not fail when "TEE device" enumeration is not supported by OP-TEE.
Yes, you are right. In my case tee_client_open_session
completes successfully, but then get_devices
fails. On one hand, this means that something is not right, but on other hand - all other features still work fine afterwards.
So, I don't know: should we consider faults in optee_enumerate_devices
as critical?
Looking into device.c, i can't see where TMEM is explicitly used. Looks like the driver allocates SHM.
I also checked the code. It seems legit, nevertheless Xen is not happy. I'll take a closer look.
And by the way. Is this right? I can see only one parameter used, not four.
No, optee_enumerate_devices()
should not be critical.
I didn't know that Xen didn't support TMEM, how does it support the argument structure? Doesn't that always go via TMEM?
It's still OK to send four parameters even if only one is used.
@lorc, your patch makes sense. If you post it on LKML I'll try to get it into 5.7 if it works well.
I didn't know that Xen didn't support TMEM, how does it support the argument structure? Doesn't that always go via TMEM?
The problem is not in TMEM per se, but in its location. Xen does not support static SHM. And before 3.9, there was no cases when TMEM was used for user SHM. I believe, when both dynamic SHM and registered SHM features are enabled, optee client uses TMEM only for "register shm" calls, which are handled separately in Xen. "Open session" and "call TA" calls always use RMEM.
I believe Xen is being too restrictive there. I'll see what is needed to allow TMEM buffers when they are residing in guest memory.
So, Jerome is right, there is only two issues in the linux driver. Maybe, even one and half :)
I'll post patch in LKML in the nearest time.
@lorc I am changing the title of this issue because it appears to be misleading now.
There are multiple issues with device PTA driver:
optee_enumerate_devices()
fails,optee_driver_init()
fails. But actually optee can work without this feature. Does it means, than older OP-TEE versions are not supported anymore?optee_remove()
Basically I'm getting this error log:
Note that Xen mediator returns an error and then kernel panics.