Hello All,
[please suggest the email list if this is not the right platform to discuss, sorry for that]
We use Op-tee (3.18) in our ARM64 based project (Linux 5.15.14+) for cryption, so basically it is like " OpenSSH -> OpenSSL -> OpTee -> HSM". It works fine until we tried with a test scenario of reboot request via SSH.
When we request the system reboot via SSH, the shutting down looks not a graceful way (ssh client connection exception). This is only we add OpTee layer, otherwise everything works fine. I would like to know anyone has encountered similar kind of issue where OpTee has to take care any special shutting down process. Any leads much appreciated !
Thanks & Regards, Hareesh
Hi,
On Fri, May 17, 2024 at 10:42 AM Hareesh Das Ulleri hareesh.ulleri@ovt.com wrote:
Hello All,
[please suggest the email list if this is not the right platform to discuss, sorry for that]
We use Op-tee (3.18) in our ARM64 based project (Linux 5.15.14+) for cryption, so basically it is like " OpenSSH -> OpenSSL -> OpTee -> HSM". It works fine until we tried with a test scenario of reboot request via SSH.
When we request the system reboot via SSH, the shutting down looks not a graceful way (ssh client connection exception). This is only we add OpTee layer, otherwise everything works fine. I would like to know anyone has encountered similar kind of issue where OpTee has to take care any special shutting down process. Any leads much appreciated !
The OP-TEE kernel driver does something to prepare for shutdown. The exception in the ssh client suggests it could be a user-space integration issue. I assume the exception is triggered by an unexpected return code from OP-TEE. Is it possible to do something special when receiving that return code in order to avoid the exception?
Cheers, Jens
Hi,
Thanks for the reply.
In this scenario, userspace lib triggers a series of OP-TEE lib calls (Init, TEEC_OpenSession, TA_CRYPT_CMD_PREPARE, TA_CRYPT_CMD_SET_KEY ... ) one by one based on previous call's response return code. Shutdown request can happen middle of any of the above calls and what I see is TEE function return code is SUCESSS even after system shutdown request. So here I can't take any action based on the return code !
Regards, Hareesh
-----Original Message----- From: Jens Wiklander jens.wiklander@linaro.org Sent: Tuesday, May 21, 2024 3:18 PM To: Hareesh Das Ulleri hareesh.ulleri@ovt.com Cc: op-tee@lists.trustedfirmware.org Subject: Re: SSH - OpTee reboot scenario Issue
[CAUTION]: EXTERNAL EMAIL
Hi,
On Fri, May 17, 2024 at 10:42 AM Hareesh Das Ulleri hareesh.ulleri@ovt.com wrote:
Hello All,
[please suggest the email list if this is not the right platform to discuss, sorry for that]
We use Op-tee (3.18) in our ARM64 based project (Linux 5.15.14+) for cryption, so basically it is like " OpenSSH -> OpenSSL -> OpTee -> HSM". It works fine until we tried with a test scenario of reboot request via SSH.
When we request the system reboot via SSH, the shutting down looks not a graceful way (ssh client connection exception). This is only we add OpTee layer, otherwise everything works fine. I would like to know anyone has encountered similar kind of issue where OpTee has to take care any special shutting down process. Any leads much appreciated !
The OP-TEE kernel driver does something to prepare for shutdown. The exception in the ssh client suggests it could be a user-space integration issue. I assume the exception is triggered by an unexpected return code from OP-TEE. Is it possible to do something special when receiving that return code in order to avoid the exception?
Cheers, Jens
Hi,
On Tue, May 21, 2024 at 10:08 AM Hareesh Das Ulleri hareesh.ulleri@ovt.com wrote:
Hi,
Thanks for the reply.
In this scenario, userspace lib triggers a series of OP-TEE lib calls (Init, TEEC_OpenSession, TA_CRYPT_CMD_PREPARE, TA_CRYPT_CMD_SET_KEY ... ) one by one based on previous call's response return code. Shutdown request can happen middle of any of the above calls and what I see is TEE function return code is SUCESSS even after system shutdown request. So here I can't take any action based on the return code !
That is strange. It would make more sense to return some error code in this scenario. Can you find where an error should have been returned instead of OK? I suspect there's a struct somewhere where an error code isn't written in this case.
Cheers, Jens
Regards, Hareesh
-----Original Message----- From: Jens Wiklander jens.wiklander@linaro.org Sent: Tuesday, May 21, 2024 3:18 PM To: Hareesh Das Ulleri hareesh.ulleri@ovt.com Cc: op-tee@lists.trustedfirmware.org Subject: Re: SSH - OpTee reboot scenario Issue
[CAUTION]: EXTERNAL EMAIL
Hi,
On Fri, May 17, 2024 at 10:42 AM Hareesh Das Ulleri hareesh.ulleri@ovt.com wrote:
Hello All,
[please suggest the email list if this is not the right platform to discuss, sorry for that]
We use Op-tee (3.18) in our ARM64 based project (Linux 5.15.14+) for cryption, so basically it is like " OpenSSH -> OpenSSL -> OpTee -> HSM". It works fine until we tried with a test scenario of reboot request via SSH.
When we request the system reboot via SSH, the shutting down looks not a graceful way (ssh client connection exception). This is only we add OpTee layer, otherwise everything works fine. I would like to know anyone has encountered similar kind of issue where OpTee has to take care any special shutting down process. Any leads much appreciated !
The OP-TEE kernel driver does something to prepare for shutdown. The exception in the ssh client suggests it could be a user-space integration issue. I assume the exception is triggered by an unexpected return code from OP-TEE. Is it possible to do something special when receiving that return code in order to avoid the exception?
Cheers, Jens
op-tee@lists.trustedfirmware.org
-
Hareesh Das Ulleri -
Jens Wiklander