linux-kernel - Re: [PATCH V3 2/2] tee: add OP-TEE driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <887DE856-552A-4A21-8CC7-CFB9B80033E4@javigon.com>
Date:	Wed, 20 May 2015 16:11:05 +0200
From:	Javier González <javier@...igon.com>
To:	Jens Wiklander <jens.wiklander@...aro.org>
Cc:	Mark Rutland <mark.rutland@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Rob Herring <robh+dt@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"tpmdd-devel@...ts.sourceforge.net" 
	<tpmdd-devel@...ts.sourceforge.net>,
	"valentin.manea@...wei.com" <valentin.manea@...wei.com>,
	"jean-michel.delorme@...com" <jean-michel.delorme@...com>,
	"emmanuel.michel@...com" <emmanuel.michel@...com>
Subject: Re: [PATCH V3 2/2] tee: add OP-TEE driver

Hi,
Just for completeness,

> On 20 May 2015, at 14:16, Jens Wiklander <jens.wiklander@...aro.org> wrote:
> 
> Hi,
> 
> On Mon, May 18, 2015 at 02:18:50PM +0100, Mark Rutland wrote:
>> Hi,
>> 
>> On Fri, May 15, 2015 at 07:34:27AM +0100, Jens Wiklander wrote:
> 
[…]

>> 
>> I'm also very concerned that the interface exposed to userspace is
>> hideously low-level. Surely we'd expect kernel-side drivers to be doing
>> the bulk of direct communication to the OP-TEE instance? In the lack of
>> a provided rationale I don't see why the current messaging interface
>> would make sense.
> The kernel-side does all the direct communication since there's where
> the SMC is done, but one level above most of the communication is
> terminated in user space. Loading of Trusted Applications and other file
> system access is done in by a helper process in user space,
> tee-supplicant. A large part of the OP-TEE message protocol is
> transparent to the kernel.
> 
> We're trying to not exclude any TEE implementation by having this low
> level TEE_IOC_CMD instead of a high level interface. The problem with
> the different TEEs is that they are designed differently and we haven't
> been able to find a high level interface that suits all. Applications
> aren't expected to use TEE_IOC_CMD directly, instead there's supposed to
> be a client lib wich wraps the kernel interface and provides a higher
> level interface, for instance a Global Platform Client API in the case
> of a GP TEE.
> 
> For OP-TEE we're using the same protocol all the way down to user space,
> the advantage is that it's only one protocol to keep track of and we
> don't need to translate the entire message (we do need to copy it,
> excluding the payload) each time the message is passed to the next
> memory space. In the presence of a hypervisor we have
> user space -> kernel -> hypervisor -> secure world
> Unfortunately some fields has a different meaning in user space and
> kernel space. I'll address this in the documentation.
> 
> The OP-TEE helper process, tee-supplicant, is specific to only OP-TEE.
> Other TEEs uses helper processes too, but what they do depend on the
> design of the TEE. As a consequence more or less all TEEs needs
> something specific for that particular TEE in user space to be fully
> functional.
> 
> To summarize, the current assumption is that all TEEs can't use the same
> high level interface. Instead we need to provide a way for each TEE to
> have their own low level interface which should be wrapped in a user
> space library to provide a more reasonable interface to the client
> application.
> 
> 

This design aims to be TEE agnostic.

As Jens mentioned, user space applications are supposed to use client-side
API’s (e.g., Global Platform). It is convenient that these APIs reside in user
space together with the wrapper using the kernel TEE interface. Note that
GP’s APIs have changed much since they were first released. It would be
a lot of work to keep them updated in the kernel and we would eventually
run into the issue that they are not backwards compatible, thus making  user
space applications break.

Also, we want to eventually support kernel submodules to use the TEE subsystem.
In this case, having a simple in-kernel interface makes things easier. Again,
having a rich API such as GP in the kernel would not add any value.

[…]

Javier.


Download attachment "signature.asc" of type "application/pgp-signature" (843 bytes)