Hi,
On Wed, 17 Jul 2024 at 18:01, Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
>
> Adding TEE mailing list and maintainers to the CC list.
Thanks. I am not going to reiterate what Jens said in the other thread
but going to cover some additional points.
>
> Amirreza, please include them in future even if you are not going to use
> the framework.
>
>
> On Wed, Jul 10, 2024 at 09:16:48AM GMT, Amirreza Zarrabi 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).
> >
> >
> > >> Does TEE subsystem fit requirements of a capability based system?
Just to make things clear, first you should have involved TEE
subsystem maintainers to discuss QTEE requirements and see how we can
evolve the TEE subsystem rather than complaining about the opposite.
What happens if another proprietary TEE implementation comes up to
reuse this capability based system as you have described for QTEE? The
reason we have a generic TEE subsystem is to allow common
functionality to be reused within the kernel to interface with
different TEE implementations.
> > >> -----------------------------------------------------------------
> > >> 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).
> >
First of all, we need an open source reference user-space
implementation to better understand how these capabilities are going
to be used in real world use-cases. Is there any enforcement done from
the kernel side or it's purely a user-space concept?
> > >
> > >> 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.
> >
> > 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).
