Re: Secure resources in device trees

On Wed, Jan 21, 2015 at 7:01 PM, Greg Bellows [off-list ref] wrote:

Thanks Mark, comments inline.

On Wed, Jan 21, 2015 at 10:29 AM, Mark Rutland [off-list ref] wrote:

quoted

On Tue, Jan 20, 2015 at 07:15:51PM +0000, Greg Bellows wrote:

quoted

The addition of ARM security extension (TrustZone) support to QEMU has
exposed the issue of how secure resources are communicated to secure
software responsible for booting the HLOS.  The natural choice for
communicating these details is the device tree.

In the case of real hardware, the device tree supplied to the HLOS
only needs to describe non-secure resources as secure software can
rely on static knowledge about the hardware.  This also holds true for
QEMU machines modeled after actual fixed hardware configurations.
However, this is not the case with QEMU's virtual machine models, such
as machvirt, where the hardware configuration can change over time.

When you say this changes over time, I assume you mean for the lifetime
of the project, as opposed to the lifetime of a running instance? i.e.
non-probeable devices are not dynamically injected to a running system.

Correct, the project.  The QEMU machvirt device can be adapted over
time to include additional resources.

quoted

quoted

In this case, secure software is dependent on QEMU's dynamically
constructed device tree to describe the hardware, making it impossible
for secure software to know ahead of time what is secure, non-secure,
or both.

Two possible approaches for handling this particular case are:

1) Create two device tree blobs; one describing the non-secure
configuration and the other the full configuration.  This would allow
secure software to see the full hardware picture including secure
resources while the non-secure world would only see the non-secure
device tree configuration.  The QEMU virt machine would be responsible
for producing the device tree blobs.

The drawbacks to this approach are:
* There are 2 device trees to manage
* The two DTBs will typically be almost identical.
* Not possible to identify whether a device is shared or not between
the secure and non-secure worlds.
* Identifying device available only to the secure world require
cumbersome comparison of the two device trees.

I'm not sure I follow why such identification is necessary?

Identifying secure resources would be necessary in cases where secure
resources are removed prior to passing to the next level.  In some
cases, it may also be an indicator that the resource needs
initialization by secure SW.

quoted

quoted

* A mechanism would be needed to pass an additional device tree.

2) Modify the standard device tree blob to include annotations or
modifications to describe which resources are secure or not.  In this
case, secure software would use the single device tree to identify the
secure resources.  The added information could be used by secure
software to trim the device tree before passing it.  Alternatively,
the information could be passed on to non-secure software with the
expectation that it would honor the device security.   It would be
crucial that any data added to the device tree adhere to existing
conventions or expectations.

This approach assumes assumes that the secure and non-secure physical
address spaces are identical bar some portions being masked out on the
non-secure side. This is not necessarily the case.

Architecturally the secure and non-secure physical address spaces are
entiorely separate, and do not necessarily mirror each other.

Considering that the secure world can access both the secure and
non-secure address spaces, it seems imperative that the resource
include information on whether it is secure or non-secure so the
correct address can be used.

quoted

It's entirely valid for some devices/RAM to only exist in one of the
address spaces (we typically see secure-only devices, but
non-secure-only devices are also possible). It's also entirely valid for
the same device to be mapped at different addresses in each address
space (e.g. the same UART could be mapped at both S:0xffff0000 and also
at NS:0xcccc0000 and nowhere else in either address space).

This certainly throws a wrench into things.  Short of adding a
parallel "non-secure" indicator, approach #2 would fall short.

quoted

So approach (2) does not fit the architecture generally. From what I
recall of previous discussions, we eventually figured out that you
either need separate trees or a higher level container to address the
secure vs nonsecure split.

I was unaware of past discussions but it sounds like the two DT
approach was decidedly more preferable.  It also sounds like the 2 DT
approach must include 2 full DTs rather than a secure-only and
non-secure only.  The latter approach would not allow non-secure only
resources to be distinguishable from shared non-secure resources.

Using separate DTs, would there be any way for secure firmware to
identify a device mapped at S:0xFOO and NS:0xBAR as being actually the
same device?

-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html