Re: [RFC PATCH 0/3] Generic TrustZone Driver in Linux Kernel

[Javier González]

Jason,

On 29 Nov 2014, at 19:18, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote:

> Javier,
> 
> On Fri, Nov 28, 2014 at 04:03:33PM +0100, Javier González wrote:
>> Hi all,
>> 
>> This set of patches is a first iteration to introduce a generic
>> TrustZone driver to the Linux Kernel. Since there is no place to add
>> drivers related to secure processors, a new subsystem for secure
>> hardware in general (drivers/sechw) is also introduced. TPM is a good
>> candidate to me moved here if this change is accepted.
>> 
>> Today, TrustZone solutions are implementation specific. In user space,
>> mobile devices are normally compliant with Global Platform's API
>> <http://www.globalplatform.org>. However, there is no common TrustZone
>> interface for kernel space, as it exists for Trusted Computing Module
>> (TPM). As a result, different TrustZone frameworks use different kernel
>> loadable modules to provide the context to communicate with the Trusted
>> Execution Environment leveraged by TrustZone's secure world.
>> 
>> Regarding use cases, TrustZone has traditionally been used for
>> offloading secure tasks to the secure world. Examples include banking
>> applications, Digital Rights Management (DRM), or specific secure
>> solutions. As more and more frameworks enabling TrustZone appear, new
>> use cases are starting to emerge: key management, encryption, integrity
>> checking, etc. Extreme cases today involve running a RTOS in the secure
>> world, or using the secure world toimplement usage control policies
>> governing the normal world. The advent of ARMv8 will only expand this
>> list.
>> 
>> This set of patches introduce a generic TrustZone driver for kernel
>> space. The first design goal is to be flexible enough as to NOT
>> introduce policy regarding the TrustZone interface. In this way, we
>> introduce a session-based open/close read/write interface where
>> several TrustZone drivers can potentially be used. The design is
>> simple and it consist on an interface that different TrustZone drivers
>> can implement to communicate with the specific frameworks.
>> 
>> Major TODO's:
>> * Patch has TODOs, FIXMEs and XXXs that need to be cleaned.
>> * Refactor part of Open Virtualization's driver. Some part are complex
>> * and can be simplified.
>> * Add support for different boards. At the moment only zynq-7000 ZC702
>> is supported. A sepparate patch containing the patch for ZC702 will be
>> sent sepparately - rebasing from 3.8 to 3.17 at the moment.
>> 
>> Development is taking place at:
>> 	https://github.com/TrustZoneGenericDriver/linux-xlnx tz_driver
>> At 14.5_trd_tz_driver_generic it can be found the same driver together
>> with TEE support for Zynq ZC702 in 3.8
>> 
>> Since all testing is being done in the Xilinx ZC702 board, using
>> Xilinx's Linux tree is convenient. Once the board rebasing to 3.17 is
>> completed, development will move to:
>> 	https://github.com/TrustZoneGenericDriver/linux
>> 
>> Feedback regarding the code, the interface, or its placement in
>> drivers/sechw is more than welcome. The idea is to refine ths TrustZone
>> driver while working on supporting more targets.
> 
> Please add me to the Cc: on future revisions.
> 
Sure thing.

> You don't mention a mailinglist.  Is there one for this project?  Also,
> TrustZone is a specious marketing name.  

There is no mailing list yet, but I will create one that I will share along with
the next patch revision. For now I rely on github’s issue tracker as a meeting 
point for people interested in the driver. 

> For those of us not actively
> working with it, wtf is it in engineering terms?  Apparently it can do
> virtualization w/o virtualization extensions?

TrustZone is a set of security extensions present in Cortex-A ARM processors.
In general terms it provides an extra privilege mode, so you can think of a 
TrustZone-enabled processor as having user space, kernel space, and secure
space. Normally the execution environment running in secure space is referred
to as secure world; the rest is referred to as normal world.

Today, there is a number of frameworks that leverage TrustZone (it has been
out for 10 years now…). Some of these frameworks adhere to ARM mobile use 
cases (e.g., banking, DRM), and implement Global Platform’s API for user space 
applications; others use TrustZone as a “cheap” way of providing paravitualization. 
For example, I know that some are using TrustZone to support a RTOS running 
in the secure world, parallel to the normal world. Still, TrustZone *does not* provide
hardware virtualization, so in the latter case performance can become an issue.

Independently from the use case, each framework implements its own driver to
switch worlds. This is normally done as a loadable module. There are two issues
with the current situation: 
(i) While user applications can be ported from one framework to another - as long 
as both (apps and frameworks) support Global Platform’s API-, kernel submodules 
cannot, due to the lack of a common kernel interface. As a product, people using 
TrustZone end up having to patch their kernels with specific interfaces for the 
framework(s) they want to support. Apart from the engineering nightmare, this 
prevents kernel submodules from providing generic secure services (e.g., secure
storage, key management, attestation) that could potentially be provided in ARM 
processors. IMA is an example of a module that would benefit from this from day 
one.
(ii) The lack of a kernel interface also prevents TrustZone adoption in the open 
source community. I personally think this is a big issue. If we had such an interface 
drivers for the few open source frameworks leveraging TrustZone will rapidly be 
ported and most probably TrustZone’s adoption would expand quickly. Hopefully 
this would also mean that more secure/trusted services would appear and spread quickly.

Here, you need to understand that TrustZone *only* provides the secure world, it 
does not provide any specification for the secure tasks. On the down side this
means that TrustZone cannot be used as a Trusted Platform Module (TPM) - which
does  provide an specification. On the good side, the possibilities are unlimited. I
think of the secure world as a way of providing “secure system primitives” which
can be seen as secure system calls. These can evolve with time and provide new
secure services by simply providing software updates. Before we get there however,
we need a generic TrustZone driver interface as the one I propose. 

From an engineering perspective, the challenge is to provide an interface that does
not introduce policy for the TrustZone use cases. My proposal is a simple open/close
read/write interface where kernel submodules can open a connection to the secure 
world and send commands to it. These commands respond to the secure system 
primitives. User applications can also use this through a Global Platform’s API exposed
to user space. I have implemented part of the API to test my driver. It works and
performs pretty good.

There is also an extra challenge that is not covered in these patches. In TrustZone, 
any device can potentially be mapped to the secure world at boot time. This means 
that the memory for each device needs to be mapped to a different address space 
depending on the world the device belongs to. This is difficult to generalise since the 
base addresses for each device are target-specific Here, the frameworks I know 
directly hardcode addresses. I have approached this issue by adding a tag to each 
device in the device tree where the world to which they are mapped to is specified. 
Then, when the devices are given I/O memory at boot time this tag is used to assign 
them to different base addresses, therefore allowing the secure world to control them.
I have it working on 3.8 for the Zynq ZC702. I am not porting it to 3.17. This is a 
different problem, and I will send these patches when they are ready. I mention it here 
for completeness.

> Wouldn't a lot of the trustworthiness depend on the lack of
> vulnerabilities in this API or other communications interfaces?  Can end
> users choose to load a different binary (say, OpenVZ) than the DRM that
> came with the phone?  How is that handled?  How does this fit into a
> trusted boot sequence?

The API is definitely an attack vector, and it needs to be clean and well tested. However,
it all depends on the attack model. If we assume a malicious root, then the kernel can
be compromised even if the interface is bug-free. Here we enter in how to design the
secure world tasks and interfaces (in the secure side) so that it can detect malicious 
behaviour and be resilient. My research is focused on how to approach these issues
using a usage control engine in the secure world to monitor the kernel’s activity (i.e, 
memory, crypto operations, etc.). I attach a presentation where I describe these
issues [1].

Regarding using different binaries, the answer is not simple. Today, it is not very
probably since most phones are locked to specific first stage boot loaders. If we
assume that this is not an issue, not counting on a common interface from within the
kernel makes switching the framework leveraging TrustZone not viable. I attach also
an article where we describe how this can be done using TrustZone and a Secure
Element [2]. This is one of the use cases in which the TrustZone driver I am sending is
being used. 


On 29 Nov 2014, at 19:48, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

> On Sat, Nov 29, 2014 at 01:18:53PM -0500, Jason Cooper wrote:
>> 
>> And as GregKH mentioned, this definitely needs some cleanup before
>> expecting others to spend time reviewing.  If this code is working for
>> your usecase, perhaps the staging tree might be a better place to
>> start.
> 
> No, it needs lots of work before the staging tree can accept it (hint,
> the FIXMEs are good places to start...)

It does. All the FIXMEs are however located in the driver I ported for Open Virtualization.
I will work on it from monday and hopefully submit a new version by the end of next week.
Getting a version of the driver in the staging tree would be a good start, also to get good
feedback from more experienced kernel people :)

I would however appreciate having early feedback on: 
(i) The interface itself: drivers/sechw/trustzone/trustzone.c
(ii) Creating a new submodule for secure hardware, where TPM could potentially be moved.


> 
> thx,
> 
> Jason.

Attachements:
[1]  http://www.itu.dk/people/jgon/XSWG_runtime_security-Oct20.pdf
[2]  http://www.researchgate.net/publication/267039927_A_Practical_Hardware-Assisted_Approach_to_Customize_Trusted_Boot_for_Mobile_Devices

Best,

p.s. Sorry for double sending. I answered from my personal laptop and forgot setting plain text...

Javier

> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




On 29 Nov 2014, at 19:18, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote:

> Javier,
> 
> On Fri, Nov 28, 2014 at 04:03:33PM +0100, Javier González wrote:
>> Hi all,
>> 
>> This set of patches is a first iteration to introduce a generic
>> TrustZone driver to the Linux Kernel. Since there is no place to add
>> drivers related to secure processors, a new subsystem for secure
>> hardware in general (drivers/sechw) is also introduced. TPM is a good
>> candidate to me moved here if this change is accepted.
>> 
>> Today, TrustZone solutions are implementation specific. In user space,
>> mobile devices are normally compliant with Global Platform's API
>> <http://www.globalplatform.org>. However, there is no common TrustZone
>> interface for kernel space, as it exists for Trusted Computing Module
>> (TPM). As a result, different TrustZone frameworks use different kernel
>> loadable modules to provide the context to communicate with the Trusted
>> Execution Environment leveraged by TrustZone's secure world.
>> 
>> Regarding use cases, TrustZone has traditionally been used for
>> offloading secure tasks to the secure world. Examples include banking
>> applications, Digital Rights Management (DRM), or specific secure
>> solutions. As more and more frameworks enabling TrustZone appear, new
>> use cases are starting to emerge: key management, encryption, integrity
>> checking, etc. Extreme cases today involve running a RTOS in the secure
>> world, or using the secure world toimplement usage control policies
>> governing the normal world. The advent of ARMv8 will only expand this
>> list.
>> 
>> This set of patches introduce a generic TrustZone driver for kernel
>> space. The first design goal is to be flexible enough as to NOT
>> introduce policy regarding the TrustZone interface. In this way, we
>> introduce a session-based open/close read/write interface where
>> several TrustZone drivers can potentially be used. The design is
>> simple and it consist on an interface that different TrustZone drivers
>> can implement to communicate with the specific frameworks.
>> 
>> Major TODO's:
>> * Patch has TODOs, FIXMEs and XXXs that need to be cleaned.
>> * Refactor part of Open Virtualization's driver. Some part are complex
>> * and can be simplified.
>> * Add support for different boards. At the moment only zynq-7000 ZC702
>> is supported. A sepparate patch containing the patch for ZC702 will be
>> sent sepparately - rebasing from 3.8 to 3.17 at the moment.
>> 
>> Development is taking place at:
>> 	https://github.com/TrustZoneGenericDriver/linux-xlnx tz_driver
>> At 14.5_trd_tz_driver_generic it can be found the same driver together
>> with TEE support for Zynq ZC702 in 3.8
>> 
>> Since all testing is being done in the Xilinx ZC702 board, using
>> Xilinx's Linux tree is convenient. Once the board rebasing to 3.17 is
>> completed, development will move to:
>> 	https://github.com/TrustZoneGenericDriver/linux
>> 
>> Feedback regarding the code, the interface, or its placement in
>> drivers/sechw is more than welcome. The idea is to refine ths TrustZone
>> driver while working on supporting more targets.
> 
> Please add me to the Cc: on future revisions.
> 
> You don't mention a mailinglist.  Is there one for this project?  Also,
> TrustZone is a specious marketing name.  For those of us not actively
> working with it, wtf is it in engineering terms?  Apparently it can do
> virtualization w/o virtualization extensions?
> 
> Wouldn't a lot of the trustworthiness depend on the lack of
> vulnerabilities in this API or other communications interfaces?  Can end
> users choose to load a different binary (say, OpenVZ) than the DRM that
> came with the phone?  How is that handled?  How does this fit into a
> trusted boot sequence?
> 
> And as GregKH mentioned, this definitely needs some cleanup before
> expecting others to spend time reviewing.  If this code is working for
> your usecase, perhaps the staging tree might be a better place to
> start.
> 
> thx,
> 
> Jason.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail