mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jason Cooper <jason@lakedaemon.net>
To: "Javier González" <javier@javigon.com>
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
	joshc@codeaurora.org, johannes.thumshirn@men.de,
	kheitke@codeaurora.org,
	laurent.pinchart+renesas@ideasonboard.com,
	geert+renesas@glider.be, horms+renesas@verge.net.au,
	damm@opensource.se, tomi.valkeinen@ti.com, mbohan@codeaurora.org,
	michal.simek@xilinx.com, pawel.moll@arm.com,
	Andrew.Thoelke@arm.com
Subject: Re: [RFC PATCH 0/3] Generic TrustZone Driver in Linux Kernel
Date: Sat, 29 Nov 2014 13:18:53 -0500	[thread overview]
Message-ID: <20141129181853.GR22670@titan.lakedaemon.net> (raw)
In-Reply-To: <1417187016-7731-1-git-send-email-javier@javigon.com>

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.

  parent reply	other threads:[~2014-11-29 18:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28 15:03 Javier González
2014-11-28 15:03 ` [RFC PATCH 1/3] Add generic TrustZone driver Javier González
2014-11-28 19:15   ` Greg KH
2014-11-28 21:09     ` Javier González
2014-11-28 22:16       ` Greg KH
2014-11-28 22:41         ` Javier González
2014-11-28 15:03 ` [RFC PATCH 2/3] Open Virtualization driver Javier González
2014-11-28 15:03 ` [RFC PATCH 3/3] TrustZone driver: wrap OV driver Javier González
2014-11-29 18:18 ` Jason Cooper [this message]
2014-11-29 18:48   ` [RFC PATCH 0/3] Generic TrustZone Driver in Linux Kernel Greg KH
2014-11-30 12:14   ` Javier González

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141129181853.GR22670@titan.lakedaemon.net \
    --to=jason@lakedaemon.net \
    --cc=Andrew.Thoelke@arm.com \
    --cc=damm@opensource.se \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms+renesas@verge.net.au \
    --cc=javier@javigon.com \
    --cc=johannes.thumshirn@men.de \
    --cc=joshc@codeaurora.org \
    --cc=kheitke@codeaurora.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mbohan@codeaurora.org \
    --cc=michal.simek@xilinx.com \
    --cc=pawel.moll@arm.com \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®