Hi,
On Wed, Jul 10, 2024 at 1:17 AM Amirreza Zarrabi
<quic_azarrabi(a)quicinc.com> wrote:
>
>
>
> On 7/3/2024 9:36 PM, Dmitry Baryshkov wrote:
> > On Tue, Jul 02, 2024 at 10:57:35PM GMT, Amirreza Zarrabi wrote:
> >> Qualcomm TEE hosts Trusted Applications (TAs) and services that run in
> >> the secure world. Access to these resources is provided using MinkIPC.
> >> MinkIPC is a capability-based synchronous message passing facility. It
> >> allows code executing in one domain to invoke objects running in other
> >> domains. When a process holds a reference to an object that lives in
> >> another domain, that object reference is a capability. Capabilities
> >> allow us to separate implementation of policies from implementation of
> >> the transport.
> >>
> >> As part of the upstreaming of the object invoke driver (called SMC-Invoke
> >> driver), we need to provide a reasonable kernel API and UAPI. The clear
> >> option is to use TEE subsystem and write a back-end driver, however the
> >> TEE subsystem doesn't fit with the design of Qualcomm TEE.
> >>
>
> To answer your "general comment", maybe a bit of background :).
>
> Traditionally, policy enforcement is based on access-control models,
> either (1) access-control list or (2) capability [0]. A capability is an
> opaque ("non-forge-able") object reference that grants the holder the
> right to perform certain operations on the object (e.g. Read, Write,
> Execute, or Grant). Capabilities are preferred mechanism for representing
> a policy, due to their fine-grained representation of access right, inline
> with
> (P1) the principle of least privilege [1], and
> (P2) the ability to avoid the confused deputy problem [2].
>
> [0] Jack B. Dennis and Earl C. Van Horn. 1966. Programming Semantics for
> Multiprogrammed Computations. Commun. ACM 9 (1966), 143–155.
>
> [1] Jerome H. Saltzer and Michael D. Schroeder. 1975. The Protection of
> Information in Computer Systems. Proc. IEEE 63 (1975), 1278–1308.
>
> [2] Norm Hardy. 1988. The Confused Deputy (or Why Capabilities Might Have
> Been Invented). ACM Operating Systems Review 22, 4 (1988), 36–38.
>
> For MinkIPC, an object represents a TEE or TA service. The reference to
> the object is the "handle" that is returned from TEE (let's call it
> TEE-Handle). The supported operations are "service invocation" (similar
> to Execute), and "sharing access to a service" (similar to Grant).
> Anyone with access to the TEE-Handle can invoke the service or pass the
> TEE-Handle to someone else to access the same service.
>
> The responsibility of the MinkIPC framework is to hide the TEE-Handle,
> so that the client can not forge it, and allow the owner of the handle
> to transfer it to other clients as it wishes. Using a file descriptor
> table we can achieve that. We wrap the TEE-Handle as a FD and let the
> client invoke FD (e.g. using IOCTL), or transfer the FD (e.g. using
> UNIX socket).
>
> As a side note, for the sake of completeness, capabilities are fundamentally
> a "discretionary mechanism", as the holder of the object reference has the
> ability to share it with others. A secure system requires "mandatory
> enforcement" (i.e. ability to revoke authority and ability to control
> the authority propagation). This is out of scope for the MinkIPC.
> MinkIPC is only interested in P1 and P2 (mention above).
This is still quite abstract. We have tried to avoid inventing yet
another IPC mechanism in the TEE subsystem. But that's not written in
stone if it turns out there's a use case that needs it.
>
>
> >> Does TEE subsystem fit requirements of a capability based system?
> >> -----------------------------------------------------------------
> >> In TEE subsystem, to invoke a function:
> >> - client should open a device file "/dev/teeX",
> >> - create a session with a TA, and
> >> - invoke the functions in that session.
> >>
> >> 1. The privilege to invoke a function is determined by a session. If a
> >> client has a session, it cannot share it with other clients. Even if
> >> it does, it is not fine-grained enough, i.e. either all accessible
> >> functions/resources in a session or none. Assume a scenario when a client
> >> wants to grant a permission to invoke just a function that it has the rights,
> >> to another client.
> >>
> >> The "all or nothing" for sharing sessions is not in line with our
> >> capability system: "if you own a capability, you should be able to grant
> >> or share it".
> >
> > Can you please be more specific here? What kind of sharing is expected
> > on the user side of it?
>
> In MinkIPC, after authenticating a client credential, a TA (or TEE) may
> return multiple TEE-Handles, each representing a service that the client
> has privilege to access. The client should be able to "individually"
> reference each TEE-Handle, e.g. to invoke and share it (as per capability-
> based system requirements).
>
> If we use TEE subsystem, which has a session based design, all TEE-Handles
> are meaningful with respect to the session in which they are allocated,
> hence the use of "__u32 session" in "struct tee_ioctl_invoke_arg".
>
> Here, we have a contradiction with MinkIPC. We may ignore the session
> and say "even though a TEE-Handle is allocated in a session but it is also
> valid outside a session", i.e. the session-id in TEE uapi becomes redundant
> (a case of divergence from definition).
Only the backend drivers put a meaning to a session, the TEE subsystem
doesn't enforce anything. All fields but num_params and params in
struct tee_ioctl_invoke_arg are only interpreted by the backend driver
if I recall correctly. Using the fields for something completely
different would be confusing so if struct tee_ioctl_invoke_arg isn't
matching well enough we might need a new IOCTL for whatever you have
in mind.
>
> >
> >> 2. In TEE subsystem, resources are managed in a context. Every time a
> >> client opens "/dev/teeX", a new context is created to keep track of
> >> the allocated resources, including opened sessions and remote objects. Any
> >> effort for sharing resources between two independent clients requires
> >> involvement of context manager, i.e. the back-end driver. This requires
> >> implementing some form of policy in the back-end driver.
> >
> > What kind of resource sharing?
>
> TEE subsystem "rightfully" allocates a context each time a client opens
> a device file. This context pass around to the backend driver to identify
> independent clients that opened the device file.
>
> The context is used by backend driver to keep track of the resources. Type
> of resources are TEE driver dependent. As an example of resource in TEE
> subsystem, you can look into 'shm' register and unregister (specially,
> see comment in function 'shm_alloc_helper').
>
> For MinkIPC, all clients are treated the same and the TEE-Handles are
> representative of the resources, accessible "globally" if a client has the
> capability for them. In kernel, clients access an object if they have
> access to "qcom_tee_object", in userspace, clients access an object if
> they have the FD wrapper for the TEE-Handle.
So if a client has a file descriptor representing a TEE-Handle, then
it has the capability to access a TEE-object? Is the kernel
controlling anything more about these capabilities?
>
> If we use context, instead of the file descriptor table, any form of object
> transfer requires involvement of the backend driver. If we use the file
> descriptor table, contexts are becoming useless for MinkIPC (i.e.
> 'ctx->data' will "always" be null).
You still need to open a device to be able to create TEE-handles.
>
> >
> >> 3. The TEE subsystem supports two type of memory sharing:
> >> - per-device memory pools, and
> >> - user defined memory references.
> >> User defined memory references are private to the application and cannot
> >> be shared. Memory allocated from per-device "shared" pools are accessible
> >> using a file descriptor. It can be mapped by any process if it has
> >> access to it. This means, we cannot provide the resource isolation
> >> between two clients. Assume a scenario when a client wants to allocate a
> >> memory (which is shared with TEE) from an "isolated" pool and share it
> >> with another client, without the right to access the contents of memory.
> >
> > This doesn't explain, why would it want to share such memory with
> > another client.
>
> Ok, I believe there is a misunderstanding here. I did not try to justify
> specific usecase. We want to separate the memory allocation from the
> framework. This way, how the memory is obtained, e.g. it is allocated
> (1) from an isolated pool, (2) a shared pool, (3) a secure heap,
> (4) a system dma-heap, (5) process address space, or (6) other memory
> with "different constraints", becomes independent.
Especially points 3 and 4 are of great interest for the TEE Subsystem.
>
> We introduced "memory object" type. User implements a kernel service
> using "qcom_tee_object" to represent the memory object. We have an
> implementation of memory objects based on dma-buf.
Do you have an idea of what it would take to extend to TEE subsystem
to cover this?
>
> >
> >> 4. The kernel API provided by TEE subsystem does not support a kernel
> >> supplicant. Adding support requires an execution context (e.g. a
> >> kernel thread) due to the TEE subsystem design. tee_driver_ops supports
> >> only "send" and "receive" callbacks and to deliver a request, someone
> >> should wait on "receive".
So far we haven't needed a kernel thread, but if you need one feel
free to propose something.
> >
> > There is nothing wrong here, but maybe I'm misunderstanding something.
>
> I agree. But, I am trying to re-emphasize how useful TEE subsystem is
> for MinkIPC. For kernel services, we solely rely on the backend driver.
> For instance, to expose RPMB service we will use "qcom_tee_object".
> So there is nothing provided by the framework to simplify the service
> development.
The same is true for all backend drivers.
>
> >
> >> We need a callback to "dispatch" or "handle" a request in the context of
> >> the client thread. It should redirect a request to a kernel service or
> >> a user supplicant. In TEE subsystem such requirement should be implemented
> >> in TEE back-end driver, independent from the TEE subsystem.
> >>
> >> 5. The UAPI provided by TEE subsystem is similar to the GPTEE Client
> >> interface. This interface is not suitable for a capability system.
> >> For instance, there is no session in a capability system which means
> >> either its should not be used, or we should overload its definition.
Not using the session field doesn't seem like such a big obstacle.
Overloading it for something different might be messy. We can add a
new IOCTL if needed as I mentioned above.
> >
> > General comment: maybe adding more detailed explanation of how the
> > capabilities are aquired and how they can be used might make sense.
> >
> > BTW. It might be my imperfect English, but each time I see the word
> > 'capability' I'm thinking that some is capable of doing something. I
> > find it hard to use 'capability' for the reference to another object.
> >
>
> Explained at the top :).
>
> >>
> >> Can we use TEE subsystem?
> >> -------------------------
> >> There are workarounds for some of the issues above. The question is if we
> >> should define our own UAPI or try to use a hack-y way of fitting into
> >> the TEE subsystem. I am using word hack-y, as most of the workaround
> >> involves:
Instead of hack-y workarounds, we should consider extending the TEE
subsystem as needed.
> >>
> >> - "diverging from the definition". For instance, ignoring the session
> >> open and close ioctl calls or use file descriptors for all remote
> >> resources (as, fd is the closet to capability) which undermines the
> >> isolation provided by the contexts,
> >>
> >> - "overloading the variables". For instance, passing object ID as file
> >> descriptors in a place of session ID, or
struct qcom_tee_object_invoke_arg and struct tee_ioctl_invoke_arg are
quite similar, there are only a few more fields in the latter and we
are missing a TEE_IOCTL_PARAM_ATTR_TYPE_OBJECT. Does it make sense to
have a direction on objects?
> >>
> >> - "bypass TEE subsystem". For instance, extensively rely on meta
> >> parameters or push everything (e.g. kernel services) to the back-end
> >> driver, which means leaving almost all TEE subsystem unused.
The TEE subsystem is largely "bypassed" by all backend drivers, with
the exception of some SHM handling.
I'm sure the TEE subsystem can be extended to handle the "common" part
of SHM handling needed by QTEE.
> >>
> >> We cannot take the full benefits of TEE subsystem and may need to
> >> implement most of the requirements in the back-end driver. Also, as
> >> discussed above, the UAPI is not suitable for capability-based use cases.
> >> We proposed a new set of ioctl calls for SMC-Invoke driver.
> >>
> >> In this series we posted three patches. We implemented a transport
> >> driver that provides qcom_tee_object. Any object on secure side is
> >> represented with an instance of qcom_tee_object and any struct exposed
> >> to TEE should embed an instance of qcom_tee_object. Any, support for new
> >> services, e.g. memory object, RPMB, userspace clients or supplicants are
> >> implemented independently from the driver.
> >>
> >> We have a simple memory object and a user driver that uses
> >> qcom_tee_object.
> >
> > Could you please point out any user for the uAPI? I'd like to understand
> > how does it from from the userspace point of view.
>
> Sure :), I'll write up a test patch and send it in next series.
>
> Summary.
>
> TEE framework provides some nice facilities, including:
> - uapi and ioctl interface,
> - marshaling parameters and context management,
> - memory mapping and sharing, and
> - TEE bus and TA drivers.
>
> For, MinkIPC, we will not use any of them. The only usable piece, is uapi
> interface which is not suitable for MinkIPC, as discussed above.
I hope that we can change that. :-)
For instance, extending the TEE subsystem with the memory-sharing QTEE
needs could be useful for other TEE drivers.
Cheers,
Jens
Main updates from version V7[1]
Update the series based on Mathieu Poirier's comments.
Details of the updates are listed in the commit messages of the patches.
[1] https://lore.kernel.org/linux-arm-kernel/20240611073904.475019-1-arnaud.pou…
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
Description of the feature:
--------------------------
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating
and loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc…
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem…
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact.the user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (5):
remoteproc: core: Introduce rproc_pa_to_va helper
remoteproc: Add TEE support
dt-bindings: remoteproc: Add compatibility for TEE support
remoteproc: stm32: Create sub-functions to request shutdown and
release
remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
.../bindings/remoteproc/st,stm32-rproc.yaml | 58 ++-
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_core.c | 46 ++
drivers/remoteproc/remoteproc_tee.c | 446 ++++++++++++++++++
drivers/remoteproc/stm32_rproc.c | 147 ++++--
include/linux/remoteproc.h | 5 +
include/linux/remoteproc_tee.h | 100 ++++
8 files changed, 769 insertions(+), 44 deletions(-)
create mode 100644 drivers/remoteproc/remoteproc_tee.c
create mode 100644 include/linux/remoteproc_tee.h
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
--
2.25.1
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v4.3.0 is scheduled to be released on 2024-07-12. So, now is
a good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/6906.
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related to
releases here: https://optee.readthedocs.io/en/latest/general/releases.html
Thanks,
Jens
Hello arm-soc maintainers,
Please pull this small patch fixing a few missing-field-initializers warnings
in the optee driver.
Thanks,
Jens
The following changes since commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6:
Linux 6.9 (2024-05-12 14:12:29 -0700)
are available in the Git repository at:
https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-fix-for-v6.11
for you to fetch changes up to e0556255a53d6d3d406a28362dffd972018a997c:
tee: optee: ffa: Fix missing-field-initializers warning (2024-06-27 10:27:31 +0200)
----------------------------------------------------------------
Fix optee missing-field-initializers warning
----------------------------------------------------------------
Mark-PK Tsai (1):
tee: optee: ffa: Fix missing-field-initializers warning
drivers/tee/optee/ffa_abi.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Hello arm-soc maintainers,
Please pull this small patch to the OP-TEE driver that adds a timemout
parameter when OP-TEE is waiting for a notification via RPC.
Thanks,
Jens
The following changes since commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6:
Linux 6.9 (2024-05-12 14:12:29 -0700)
are available in the Git repository at:
https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-notif-wait-timeout-for-v6.11
for you to fetch changes up to 14ca6401d8703725c7297dcc4bf8de73323411ac:
optee: add timeout value to optee_notif_wait() to support timeout (2024-05-30 10:19:28 +0200)
----------------------------------------------------------------
optee: add timeout parameter for notification wait
----------------------------------------------------------------
Gavin Liu (1):
optee: add timeout value to optee_notif_wait() to support timeout
drivers/tee/optee/notif.c | 9 +++++++--
drivers/tee/optee/optee_private.h | 5 ++++-
drivers/tee/optee/optee_rpc_cmd.h | 1 +
drivers/tee/optee/rpc.c | 10 ++++++++--
4 files changed, 20 insertions(+), 5 deletions(-)
Hi Guys,
I am working on enabling BTI (and PAC) in trusted-services and I have a question about the topic.
If BTI is disabled in OPTEE, but someone tries to load an SP which was compiled with BTI (contains the related gnu note property) it will be successful.
This seems to be a security rish and I am thinking of either panicking or at least sending an error message to remind the user that the requested protection will not be enabled.
As I know there are common parts between TA-s and SP-s loaded by ldelf so I am not sure whether panicking in this scenario will result in any problems or not.
What do you think of this proposal?
Do you know of any reasons why BTI protected SP-s should be loadable by BTI disabled OPTEE?
Thanks in advance!
Gábor
Main updates from version V6:
------------------------------------------
- Fix kernel robot build report on in tee_rproc_find_loaded_rsc_table() inline
default definition.
Main updates from version V5[1][2]:
------------------------------------------
1) Rework resource table management
- Rework tee_rproc_parse_fw to temporary map the resource table address
to create a cached_table (similar to what is done in
rproc_elf_load_rsc_table()).
- Rename tee_rproc_get_loaded_rsc_table to tee_rproc_find_loaded_rsc_table
- Introduce rproc_pa_to_va() allowing to translate the resource table
physical address to virtual address based on remoteproc carveouts.
2) Merge the 2 "st,stm32-rproc.yaml" bindings patch in one
As the st,rproc-id" is linked to the introduction of the
"st,stm32mp1-m4-tee" compatible, merge following patches to address
Krzysztof concern.
- [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
- [PATCH v5 3/7] dt-bindings: remoteproc: Add processor identifier property
More details on updates are listed in commits messages.
[1] https://lore.kernel.org/lkml/Zlil4YSjHxb0FRgf@p14s/T/
[2] https://lore.kernel.org/lkml/20240521122458.3517054-1-arnaud.pouliquen@foss…
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
Description of the feature:
--------------------------
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating
and loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc…
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem…
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact.the user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (5):
remoteproc: core: Introduce rproc_pa_to_va helper
remoteproc: Add TEE support
dt-bindings: remoteproc: Add compatibility for TEE support
remoteproc: stm32: Create sub-functions to request shutdown and
release
remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
.../bindings/remoteproc/st,stm32-rproc.yaml | 58 ++-
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_core.c | 74 ++-
drivers/remoteproc/stm32_rproc.c | 147 ++++--
drivers/remoteproc/tee_remoteproc.c | 451 ++++++++++++++++++
include/linux/remoteproc.h | 7 +
include/linux/tee_remoteproc.h | 100 ++++
8 files changed, 802 insertions(+), 46 deletions(-)
create mode 100644 drivers/remoteproc/tee_remoteproc.c
create mode 100644 include/linux/tee_remoteproc.h
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
--
2.25.1
Hi,
Next week on Tuesday, it's time for another LOC monthly meeting. For
time and connection details see the calendar at
https://www.trustedfirmware.org/meetings/
We discussed fTPM last time with some actions (see notes at
http://bit.ly/loc-notes):
- Jan to get approval for sharing code using the new crypto API
We have an upcoming OP-TEE release, 4.3.0, July 12th.
Any other topics?
Cheers,
Jens
Hi,
This patch set introduces a new RPMB subsystem, based on patches from [1],
[2], and [3]. The RPMB subsystem aims at providing access to RPMB
partitions to other kernel drivers, in particular the OP-TEE driver. A new
user space ABI isn't needed, we can instead continue using the already
present ABI when writing the RPMB key during production.
I've added and removed things to keep only what is needed by the OP-TEE
driver. Since the posting of [3], there has been major changes in the MMC
subsystem so "mmc: block: register RPMB partition with the RPMB subsystem"
is in practice completely rewritten.
With this OP-TEE can access RPMB during early boot instead of having to
wait for user space to become available as in the current design [4].
This will benefit the efi variables [5] since we won't rely on userspace as
well as some TPM issues [6] that were solved.
The OP-TEE driver finds the correct RPMB device to interact with by
iterating over available devices until one is found with a programmed
authentication matching the one OP-TEE is using. This enables coexisting
users of other RPMBs since the owner can be determined by who knows the
authentication key.
The corresponding secure world OP-TEE patches are available at [7].
I've put myself as a maintainer for the RPMB subsystem as I have an
interest in the OP-TEE driver to keep this in good shape. However, if you'd
rather see someone else taking the maintainership that's fine too. I'll
help keep the subsystem updated regardless.
[1] https://lore.kernel.org/lkml/20230722014037.42647-1-shyamsaini@linux.micros…
[2] https://lore.kernel.org/lkml/20220405093759.1126835-2-alex.bennee@linaro.or…
[3] https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.wi…
[4] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html#rpm…
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[7] https://github.com/jenswi-linaro/optee_os/tree/rpmb_probe_v7
Thanks,
Jens
Changes since v6:
* Add Tested-by: Manuel Traut <manut(a)mecka.net> provided for the v6
* Add a new patch "tee: add tee_device_set_dev_groups()" needed later in
the patch set
* Reintroduce the rpmb_class as requested by Greg, this affects the patches
"rpmb: add Replay Protected Memory Block (RPMB) subsystem" and
"optee: probe RPMB device using RPMB subsystem"
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem":
- rpmb_interface_{,un}register() are now based on
class_interface_{,un}register()
- Embed a separate device in struct rpmb_dev for life cycle
management etc
* "optee: probe RPMB device using RPMB subsystem"
- Add an internal blocking_notifier to deal with the struct
class_interface callback
- Add a rpmb_routing_model variable in sysfs to help integration with
systemd, requested by Mikko Rapeli
- Add an RPMB probe capability flag in the ABI shared with the secure
world, both SMC and FF-A ABI, needed to support the rpmb_routing_model
variable
- optee_rpc_cmd() is strict whether an RPMB RPC request should be
forwarded to tee-supplicant or routed via the RPMB subsystem, depending
on the reported RPMB routing model
Changes since v5:
Manuel Traut reported and investigated an error on an i.MX8MM, the root
cause was identified as insufficient alignment on frames sent to the RPMB
device. Fixed in the OP-TEE driver as described below.
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Adding a missing EXPORT_SYMBOL_GPL()
* "optee: probe RPMB device using RPMB subsystem"
- Replacing the old OPTEE_RPC_CMD_RPMB ABI with OPTEE_RPC_CMD_RPMB_FRAMES
to get rid of the small header struct rpmb_req (now removed) causing
the problem.
- Matching changes on the secure side + support for re-initializing
RPMB in case a boot stage has used RPMB, the latter also reported by
Manuel Traut.
Changes since v4:
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Describing struct rpmb_descr as RPMB description instead of descriptor
* "mmc: block: register RPMB partition with the RPMB subsystem"
- Addressing review comments
- Adding more comments for struct rpmb_frame
- Fixing assignment of reliable_wr_count and capacity in mmc_blk_rpmb_add()
* "optee: probe RPMB device using RPMB subsystem"
- Updating struct rpmb_dev_info to match changes in "rpmb: add Replay
Protected Memory Block (RPMB) subsystem"
Changes since v3:
* Move struct rpmb_frame into the MMC driver since the format of the RPMB
frames depend on the implementation, one format for eMMC, another for
UFS, and so on
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Adding Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
- Adding more description of the API functions
- Removing the set_dev_info() op from struct rpmb_ops, the needed information
is supplied in the arguments to rpmb_dev_register() instead.
- Getting rid of struct rpmb_ops since only the route_frames() op was
remaining, store that op directly in struct rpmb_dev
- Changed rpmb_interface_register() and rpmb_interface_unregister() to use
notifier_block instead of implementing the same thing ourselves
* "mmc: block: register RPMB partition with the RPMB subsystem"
- Moving the call to rpmb_dev_register() to be done at the end of
mmc_blk_probe() when the device is fully available
* "optee: probe RPMB device using RPMB subsystem"
- Use IS_REACHABLE(CONFIG_RPMB) to determine if the RPMB subsystem is
available
- Translate TEE_ERROR_STORAGE_NOT_AVAILABLE if encountered in get_devices()
to recognize the error in optee_rpmb_scan()
- Simplified optee_rpmb_scan() and optee_rpmb_intf_rdev()
Changes since v2:
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Fixing documentation issues
- Adding a "depends on MMC" in the Kconfig
- Removed the class-device and the embedded device, struct rpmb_dev now
relies on the parent device for reference counting as requested
- Removed the now unneeded rpmb_ops get_resources() and put_resources()
since references are already taken in mmc_blk_alloc_rpmb_part() before
rpmb_dev_register() is called
- Added rpmb_interface_{,un}register() now that
class_interface_{,un}register() can't be used ay longer
* "mmc: block: register RPMB partition with the RPMB subsystem"
- Adding the missing error cleanup in alloc_idata()
- Taking the needed reference to md->disk in mmc_blk_alloc_rpmb_part()
instead of in mmc_rpmb_chrdev_open() and rpmb_op_mmc_get_resources()
* "optee: probe RPMB device using RPMB subsystem"
- Registering to get a notification when an RPMB device comes online
- Probes for RPMB devices each time an RPMB device comes online, until
a usable device is found
- When a usable RPMB device is found, call
optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB)
- Pass type of rpmb in return value from OPTEE_RPC_CMD_RPMB_PROBE_NEXT
Changes since Shyam's RFC:
* Removed the remaining leftover rpmb_cdev_*() function calls
* Refactored the struct rpmb_ops with all the previous ops replaced, in
some sense closer to [3] with the route_frames() op
* Added rpmb_route_frames()
* Added struct rpmb_frame, enum rpmb_op_result, and enum rpmb_type from [3]
* Removed all functions not needed in the OP-TEE use case
* Added "mmc: block: register RPMB partition with the RPMB subsystem", based
on the commit with the same name in [3]
* Added "optee: probe RPMB device using RPMB subsystem" for integration
with OP-TEE
* Moved the RPMB driver into drivers/misc/rpmb-core.c
* Added my name to MODULE_AUTHOR() in rpmb-core.c
* Added an rpmb_mutex to serialize access to the IDA
* Removed the target parameter from all rpmb_*() functions since it's
currently unused
Jens Wiklander (4):
rpmb: add Replay Protected Memory Block (RPMB) subsystem
mmc: block: register RPMB partition with the RPMB subsystem
tee: add tee_device_set_dev_groups()
optee: probe RPMB device using RPMB subsystem
Documentation/ABI/testing/sysfs-class-tee | 15 ++
MAINTAINERS | 8 +
drivers/misc/Kconfig | 10 +
drivers/misc/Makefile | 1 +
drivers/misc/rpmb-core.c | 232 +++++++++++++++++++++
drivers/mmc/core/block.c | 241 +++++++++++++++++++++-
drivers/tee/optee/core.c | 96 ++++++++-
drivers/tee/optee/device.c | 7 +
drivers/tee/optee/ffa_abi.c | 14 ++
drivers/tee/optee/optee_ffa.h | 2 +
drivers/tee/optee/optee_private.h | 26 ++-
drivers/tee/optee/optee_rpc_cmd.h | 35 ++++
drivers/tee/optee/optee_smc.h | 2 +
drivers/tee/optee/rpc.c | 177 ++++++++++++++++
drivers/tee/optee/smc_abi.c | 14 ++
drivers/tee/tee_core.c | 19 +-
include/linux/rpmb.h | 123 +++++++++++
include/linux/tee_drv.h | 12 ++
18 files changed, 1024 insertions(+), 10 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-tee
create mode 100644 drivers/misc/rpmb-core.c
create mode 100644 include/linux/rpmb.h
--
2.34.1
Main updates from the previous version [1][2]:
------------------------------------------
1) Rework resource table management
- Rework tee_rproc_parse_fw to temporary map the resource table address
to create a cached_table (similar to what is done in
rproc_elf_load_rsc_table()).
- Rename tee_rproc_get_loaded_rsc_table to tee_rproc_find_loaded_rsc_table
- Introduce rproc_pa_to_va() allowing to translate the resource table
physical address to virtual address based on remoteproc carveouts.
2) Merge the 2 "st,stm32-rproc.yaml" bindings patch in one
As the st,rproc-id" is linked to the introduction of the
"st,stm32mp1-m4-tee" compatible, merge following patches to address
Krzysztof concern.
- [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
- [PATCH v5 3/7] dt-bindings: remoteproc: Add processor identifier property
More details on updates are listed in commits messages.
[1] https://lore.kernel.org/lkml/Zlil4YSjHxb0FRgf@p14s/T/
[2] https://lore.kernel.org/lkml/20240521122458.3517054-1-arnaud.pouliquen@foss…
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
Description of the feature:
--------------------------
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating
and loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc…
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem…
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact.the user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (5):
remoteproc: core: Introduce rproc_pa_to_va helper
remoteproc: Add TEE support
dt-bindings: remoteproc: Add compatibility for TEE support
remoteproc: stm32: Create sub-functions to request shutdown and
release
remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
.../bindings/remoteproc/st,stm32-rproc.yaml | 58 ++-
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_core.c | 74 ++-
drivers/remoteproc/stm32_rproc.c | 147 ++++--
drivers/remoteproc/tee_remoteproc.c | 451 ++++++++++++++++++
include/linux/remoteproc.h | 7 +
include/linux/tee_remoteproc.h | 99 ++++
8 files changed, 801 insertions(+), 46 deletions(-)
create mode 100644 drivers/remoteproc/tee_remoteproc.c
create mode 100644 include/linux/tee_remoteproc.h
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
--
2.25.1
Main updates from the previous version [1]:
------------------------------------------
1) use proc->table_ptr as unique reference to point to the resource table
--> update remoteproc_core.c to implement management of the resource table
base on rproc->rproc->tee_interface new field:
- on start get the resource table address from TEE remoteproc instead
of finding it in firmware (ops choice to confirm)
- on stop unmap the resource table before updating the
proc->table_ptr pointer.
2) retrieve the TEE rproc Identifier from the device tree instead of
hardcoding it
--> Add a new "st,proc-id" property in device tree.
More details on updates are listed in commits messages
[1] https://lore.kernel.org/linux-arm-kernel/20240115135249.296822-1-arnaud.pou…
base-commit: c8d8f841e95bcc07ac8c5621fc171a24f1fd5cdb
Description of the feature:
--------------------------
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating
and loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc…
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem…
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact.the user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (7):
remoteproc: Add TEE support
dt-bindings: remoteproc: Add compatibility for TEE support
dt-bindings: remoteproc: Add processor identifier property
remoteproc: core introduce rproc_set_rsc_table_on_start function
remoteproc: core: support of the tee interface
remoteproc: stm32: Create sub-functions to request shutdown and
release
remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
.../bindings/remoteproc/st,stm32-rproc.yaml | 58 ++-
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_core.c | 135 +++---
drivers/remoteproc/stm32_rproc.c | 149 ++++--
drivers/remoteproc/tee_remoteproc.c | 429 ++++++++++++++++++
include/linux/remoteproc.h | 4 +
include/linux/tee_remoteproc.h | 99 ++++
8 files changed, 784 insertions(+), 101 deletions(-)
create mode 100644 drivers/remoteproc/tee_remoteproc.c
create mode 100644 include/linux/tee_remoteproc.h
--
2.25.1
Hi,
When building master as of today with:
make PLATFORM=vexpress PLATFORM_FLAVOR=juno CFG_CRYPTOLIB_NAME=mbedtls CFG_CRYPTOLIB_DIR=lib/libmbedtls
I get the following build failure:
core/lib/libtomcrypt/aes_accel.c: In function ‘aes_ctr_encrypt_nblocks’:
core/lib/libtomcrypt/aes_accel.c:182:21: error: ‘CTR_COUNTER_LITTLE_ENDIAN’ undeclared (first use in this function)
182 | if (mode == CTR_COUNTER_LITTLE_ENDIAN) {
I can fix the build with:
diff --git a/core/lib/libtomcrypt/src/headers/tomcrypt_cipher.h b/core/lib/libtomcrypt/src/headers/tomcrypt_cipher.h
index aa94698de..760aa70e1 100644
--- a/core/lib/libtomcrypt/src/headers/tomcrypt_cipher.h
+++ b/core/lib/libtomcrypt/src/headers/tomcrypt_cipher.h
@@ -925,12 +925,12 @@ int cbc_setiv(const unsigned char *IV, unsigned long len, symmetric_CBC *cbc);
int cbc_done(symmetric_CBC *cbc);
#endif
-#ifdef LTC_CTR_MODE
-
#define CTR_COUNTER_LITTLE_ENDIAN 0x0000
#define CTR_COUNTER_BIG_ENDIAN 0x1000
#define LTC_CTR_RFC3686 0x2000
+#ifdef LTC_CTR_MODE
+
int ctr_start( int cipher,
const unsigned char *IV,
const unsigned char *key, int keylen,
------------------
Does this look like a proper fix ? If so, can I send patches to the mailing list, or do I need to go via a github pull-request ?
Regards
Jacob
Tomorrow (Tuesday), it's time for another LOC monthly meeting. For
time and connection details see the calendar at
https://www.trustedfirmware.org/meetings/
We discussed fTPM last time with some actions (see notes at
http://bit.ly/loc-notes):
- Linaro to talk to members etc
- Jan to continue discussions internally
Any other topics?
Cheers,
Jens
Hi,
This patch set introduces a new RPMB subsystem, based on patches from [1],
[2], and [3]. The RPMB subsystem aims at providing access to RPMB
partitions to other kernel drivers, in particular the OP-TEE driver. A new
user space ABI isn't needed, we can instead continue using the already
present ABI when writing the RPMB key during production.
I've added and removed things to keep only what is needed by the OP-TEE
driver. Since the posting of [3], there has been major changes in the MMC
subsystem so "mmc: block: register RPMB partition with the RPMB subsystem"
is in practice completely rewritten.
With this OP-TEE can access RPMB during early boot instead of having to
wait for user space to become available as in the current design [4].
This will benefit the efi variables [5] since we wont rely on userspace as
well as some TPM issues [6] that were solved.
The OP-TEE driver finds the correct RPMB device to interact with by
iterating over available devices until one is found with a programmed
authentication matching the one OP-TEE is using. This enables coexisting
users of other RPMBs since the owner can be determined by who knows the
authentication key.
The corresponding secure world OP-TEE patches are available at [7].
I've put myself as a maintainer for the RPMB subsystem as I have an
interest in the OP-TEE driver to keep this in good shape. However, if you'd
rather see someone else taking the maintainership that's fine too. I'll
help keep the subsystem updated regardless.
[1] https://lore.kernel.org/lkml/20230722014037.42647-1-shyamsaini@linux.micros…
[2] https://lore.kernel.org/lkml/20220405093759.1126835-2-alex.bennee@linaro.or…
[3] https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.wi…
[4] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html#rpm…
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[7] https://github.com/jenswi-linaro/optee_os/tree/rpmb_probe_v6
Thanks,
Jens
Changes since v5:
Manuel Traut reported and investigated an error on an i.MX8MM, the root
cause was identified as insufficient alignment on frames sent to the RPMB
device. Fixed in the OP-TEE driver as described below.
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Adding a missing EXPORT_SYMBOL_GPL()
* "optee: probe RPMB device using RPMB subsystem"
- Replacing the old OPTEE_RPC_CMD_RPMB ABI with OPTEE_RPC_CMD_RPMB_FRAMES
to get rid of the small header struct rpmb_req (now removed) causing
the problem.
- Matching changes on the secure side + support for re-initializing
RPMB in case a boot stage has used RPMB, the latter also reported by
Manuel Traut.
Changes since v4:
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Describing struct rpmb_descr as RPMB description instead of descriptor
* "mmc: block: register RPMB partition with the RPMB subsystem"
- Addressing review comments
- Adding more comments for struct rpmb_frame
- Fixing assignment of reliable_wr_count and capacity in mmc_blk_rpmb_add()
* "optee: probe RPMB device using RPMB subsystem"
- Updating struct rpmb_dev_info to match changes in "rpmb: add Replay
Protected Memory Block (RPMB) subsystem"
Changes since v3:
* Move struct rpmb_frame into the MMC driver since the format of the RPMB
frames depend on the implementation, one format for eMMC, another for
UFS, and so on
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Adding Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
- Adding more description of the API functions
- Removing the set_dev_info() op from struct rpmb_ops, the needed information
is supplied in the arguments to rpmb_dev_register() instead.
- Getting rid of struct rpmb_ops since only the route_frames() op was
remaining, store that op directly in struct rpmb_dev
- Changed rpmb_interface_register() and rpmb_interface_unregister() to use
notifier_block instead of implementing the same thing ourselves
* "mmc: block: register RPMB partition with the RPMB subsystem"
- Moving the call to rpmb_dev_register() to be done at the end of
mmc_blk_probe() when the device is fully available
* "optee: probe RPMB device using RPMB subsystem"
- Use IS_REACHABLE(CONFIG_RPMB) to determine if the RPMB subsystem is
available
- Translate TEE_ERROR_STORAGE_NOT_AVAILABLE if encountered in get_devices()
to recognize the error in optee_rpmb_scan()
- Simplified optee_rpmb_scan() and optee_rpmb_intf_rdev()
Changes since v2:
* "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
- Fixing documentation issues
- Adding a "depends on MMC" in the Kconfig
- Removed the class-device and the embedded device, struct rpmb_dev now
relies on the parent device for reference counting as requested
- Removed the now unneeded rpmb_ops get_resources() and put_resources()
since references are already taken in mmc_blk_alloc_rpmb_part() before
rpmb_dev_register() is called
- Added rpmb_interface_{,un}register() now that
class_interface_{,un}register() can't be used ay longer
* "mmc: block: register RPMB partition with the RPMB subsystem"
- Adding the missing error cleanup in alloc_idata()
- Taking the needed reference to md->disk in mmc_blk_alloc_rpmb_part()
instead of in mmc_rpmb_chrdev_open() and rpmb_op_mmc_get_resources()
* "optee: probe RPMB device using RPMB subsystem"
- Registering to get a notification when an RPMB device comes online
- Probes for RPMB devices each time an RPMB device comes online, until
a usable device is found
- When a usable RPMB device is found, call
optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB)
- Pass type of rpmb in return value from OPTEE_RPC_CMD_RPMB_PROBE_NEXT
Changes since Shyam's RFC:
* Removed the remaining leftover rpmb_cdev_*() function calls
* Refactored the struct rpmb_ops with all the previous ops replaced, in
some sense closer to [3] with the route_frames() op
* Added rpmb_route_frames()
* Added struct rpmb_frame, enum rpmb_op_result, and enum rpmb_type from [3]
* Removed all functions not needed in the OP-TEE use case
* Added "mmc: block: register RPMB partition with the RPMB subsystem", based
on the commit with the same name in [3]
* Added "optee: probe RPMB device using RPMB subsystem" for integration
with OP-TEE
* Moved the RPMB driver into drivers/misc/rpmb-core.c
* Added my name to MODULE_AUTHOR() in rpmb-core.c
* Added an rpmb_mutex to serialize access to the IDA
* Removed the target parameter from all rpmb_*() functions since it's
currently unused
Jens Wiklander (3):
rpmb: add Replay Protected Memory Block (RPMB) subsystem
mmc: block: register RPMB partition with the RPMB subsystem
optee: probe RPMB device using RPMB subsystem
MAINTAINERS | 7 +
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile | 1 +
drivers/misc/rpmb-core.c | 233 +++++++++++++++++++++++++++++
drivers/mmc/core/block.c | 241 +++++++++++++++++++++++++++++-
drivers/tee/optee/core.c | 30 ++++
drivers/tee/optee/device.c | 7 +
drivers/tee/optee/ffa_abi.c | 8 +
drivers/tee/optee/optee_private.h | 21 ++-
drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
drivers/tee/optee/rpc.c | 166 ++++++++++++++++++++
drivers/tee/optee/smc_abi.c | 7 +
include/linux/rpmb.h | 136 +++++++++++++++++
13 files changed, 899 insertions(+), 3 deletions(-)
create mode 100644 drivers/misc/rpmb-core.c
create mode 100644 include/linux/rpmb.h
--
2.34.1
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