From: Greg Bellows <greg.bellows-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Christoffer Dall
<christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Peter Maydell
<peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: Secure resources in device trees
Date: Tue, 20 Jan 2015 13:15:51 -0600 [thread overview]
Message-ID: <CAOgzsHVpXZTHoq7HyfrGeGe92onnb6=BQr30PvKrg04h=0De0w@mail.gmail.com> (raw)
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.
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.
* 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.
The drawbacks to this approach are:
* Additional secure state details. potentially unrecognized by current
consumers, would need to be added to the device tree.
* Unless a mechanism already exists, the new secure property runs the
risk of breaking backwards compatibility.
* Secure firmware is responsible for understanding and possibly
filtering the secure device tree data.
Feedback welcomed.
Greg
--
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
next reply other threads:[~2015-01-20 19:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 19:15 Greg Bellows [this message]
[not found] ` <CAOgzsHVpXZTHoq7HyfrGeGe92onnb6=BQr30PvKrg04h=0De0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-21 16:21 ` Secure resources in device trees Rob Herring
[not found] ` <CAL_Jsq+rN07CfdNjErhLipKNJJj3uoczR98YuWSAwjMRW1xVag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-21 16:29 ` Grant Likely
2015-01-21 17:23 ` Greg Bellows
2015-01-21 18:08 ` Pawel Moll
2015-01-22 11:09 ` Peter Maydell
2015-01-21 16:29 ` Mark Rutland
2015-01-21 17:43 ` Rob Herring
[not found] ` <CAL_JsqJDNziqcX-8cq0PkSE61NVpmSBUM+fo3vmD3WrBG3=R7Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-22 18:27 ` Mark Rutland
2015-01-21 18:01 ` Greg Bellows
[not found] ` <CAOgzsHWyissYN+v5XHvUic3tp0EMHvrwTnLou2RRbyBp_9MmdQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-21 18:05 ` Christoffer Dall
[not found] ` <CAMJs5B_0sOSh4dLB9EyM2vaJq21YaXV6bX_zAv8Vmweq99DARA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-21 18:07 ` Greg Bellows
2015-01-22 11:14 ` Peter Maydell
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='CAOgzsHVpXZTHoq7HyfrGeGe92onnb6=BQr30PvKrg04h=0De0w@mail.gmail.com' \
--to=greg.bellows-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).