mbox series

Pull request for tpm-master-18042024

Message ID 20240418171401.4742-1-ilias.apalodimas@linaro.org
State New
Headers show
Series Pull request for tpm-master-18042024 | expand

Pull-request

https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-master-18042024

Message

Ilias Apalodimas April 18, 2024, 5:14 p.m. UTC
OP-TEE fixes only on this PR, no TPM related ones.

The following changes since commit 2c3fa4b8add3cb6a440184ab67debc6867d383c0:

  sandbox: don't call os_close with invalid file descriptor (2024-04-17 17:06:16 -0600)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-master-18042024

for you to fetch changes up to b905599b36e3d8158c5cd045c26278416909b422:

  tee: remove common.h inclusion (2024-04-18 16:04:48 +0300)

Igor says:
"The problem initially was in the TEE sandbox driver implementation
 (drivers/tee/sandbox.c) and it's limitations, which doesn't
 permit to have multiple simultaneous sessions with different TAs.
 This is what actually happened in this CI run [1], firstly "optee_rpmb"
 cmd was executed (and after execution we had one session open), and
 then "scp03", which also makes calls to OP-TEE, however it fails
 in sandbox_tee_open_session() because of this check:

 if (state->ta) {
     printf("A session is already open\n");
     return -EBUSY;
 }

 I had two ways in mind to address that:
 1. Close a session on each optee_rpmb cmd invocation.
 I don't see any reason to keep this session open, as obviously
 there is no other mechanism (tbh, I don't know if DM calls ".remove" for active
 devices) to close it automatically before handing over control to
 Linux kernel. As a result we might end up with some orphaned sessions
 registered in OP-TEE OS core (obvious resource leak).
 2. Extend TEE sandbox driver, add support for multiple
 simultaneous sessions just to handle the case.

 I've chosen the first approach, as IMO it was "kill two birds with one stone",
 I could address resource leak in OP-TEE and bypass limitations of
 TEE sandbox driver."

Link: https://lore.kernel.org/u-boot/CAByghJZVRbnFUwJdgU534tvGA+DX2pArf0i7ySik=BrXgADe3Q@mail.gmail.com/

The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/20414
showed no problems

Please pull
/Ilias

----------------------------------------------------------------
optee fixes and cleanups
----------------------------------------------------------------
Igor Opaniuk (5):
      tee: optee: fix description in Kconfig
      cmd: optee_rpmb: close tee session
      cmd: optee_rpmb: build cmd for sandbox
      test: py: add optee_rpmb tests
      tee: remove common.h inclusion

 cmd/Kconfig                        |  4 +++-
 cmd/optee_rpmb.c                   | 23 +++++++++++++++++------
 drivers/tee/broadcom/chimp_optee.c |  3 ++-
 drivers/tee/optee/Kconfig          |  2 +-
 drivers/tee/optee/core.c           |  1 -
 drivers/tee/optee/i2c.c            |  1 -
 drivers/tee/optee/rpmb.c           |  1 -
 drivers/tee/optee/supplicant.c     |  2 +-
 drivers/tee/sandbox.c              |  2 +-
 drivers/tee/tee-uclass.c           |  1 -
 test/py/tests/test_optee_rpmb.py   | 20 ++++++++++++++++++++
 11 files changed, 45 insertions(+), 15 deletions(-)
 create mode 100644 test/py/tests/test_optee_rpmb.py

Comments

Tom Rini April 19, 2024, 9:31 p.m. UTC | #1
On Thu, Apr 18, 2024 at 08:14:01PM +0300, Ilias Apalodimas wrote:

> OP-TEE fixes only on this PR, no TPM related ones.
> 
> The following changes since commit 2c3fa4b8add3cb6a440184ab67debc6867d383c0:
> 
>   sandbox: don't call os_close with invalid file descriptor (2024-04-17 17:06:16 -0600)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-master-18042024
> 
> for you to fetch changes up to b905599b36e3d8158c5cd045c26278416909b422:
> 
>   tee: remove common.h inclusion (2024-04-18 16:04:48 +0300)
> 
> Igor says:
> "The problem initially was in the TEE sandbox driver implementation
>  (drivers/tee/sandbox.c) and it's limitations, which doesn't
>  permit to have multiple simultaneous sessions with different TAs.
>  This is what actually happened in this CI run [1], firstly "optee_rpmb"
>  cmd was executed (and after execution we had one session open), and
>  then "scp03", which also makes calls to OP-TEE, however it fails
>  in sandbox_tee_open_session() because of this check:
> 
>  if (state->ta) {
>      printf("A session is already open\n");
>      return -EBUSY;
>  }
> 
>  I had two ways in mind to address that:
>  1. Close a session on each optee_rpmb cmd invocation.
>  I don't see any reason to keep this session open, as obviously
>  there is no other mechanism (tbh, I don't know if DM calls ".remove" for active
>  devices) to close it automatically before handing over control to
>  Linux kernel. As a result we might end up with some orphaned sessions
>  registered in OP-TEE OS core (obvious resource leak).
>  2. Extend TEE sandbox driver, add support for multiple
>  simultaneous sessions just to handle the case.
> 
>  I've chosen the first approach, as IMO it was "kill two birds with one stone",
>  I could address resource leak in OP-TEE and bypass limitations of
>  TEE sandbox driver."
> 
> Link: https://lore.kernel.org/u-boot/CAByghJZVRbnFUwJdgU534tvGA+DX2pArf0i7ySik=BrXgADe3Q@mail.gmail.com/
> 
> The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/20414
> showed no problems
> 
> Please pull
> /Ilias
> 

Applied to u-boot/master, thanks!