From: Tom Rini <trini@konsulko.com>
Date: Thu, 18 Apr 2024 18:13:40 +0000 (-0600)
Subject: Merge tag 'tpm-master-18042024' of https://source.denx.de/u-boot/custodians/u-boot-tpm
X-Git-Url: http://git.dujemihanovic.xyz/%22http:/www.sics.se/static/%7B%7B%20%24style.Permalink%20%7D%7D?a=commitdiff_plain;h=d893c93205701b77f9b3f2e8074297a32d8710db;p=u-boot.git

Merge tag 'tpm-master-18042024' of https://source.denx.de/u-boot/custodians/u-boot-tpm

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
---

d893c93205701b77f9b3f2e8074297a32d8710db