From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Greg Bellows
<greg.bellows-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Christoffer Dall
<christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Peter Maydell
<peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: Re: Secure resources in device trees
Date: Thu, 22 Jan 2015 18:27:07 +0000 [thread overview]
Message-ID: <20150122182707.GD12911@leverpostej> (raw)
In-Reply-To: <CAL_JsqJDNziqcX-8cq0PkSE61NVpmSBUM+fo3vmD3WrBG3=R7Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[...]
> >> * 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.
>
> True, but I would guess this is the common case.
In practically every system I can think of, the address spaces are
essentially the same bar masking.
However, if we're trying to model the architectural envelope, then the
fact that a single DTB can't encode that needs some consideration in
this matter.
> > Architecturally the secure and non-secure physical address spaces are
> > entiorely separate, and do not necessarily mirror each other.
> >
> > 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).
> >
> > 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.
>
> Though there's no reason both approaches can't be supported. If the 2
> views are radically different, then use 2 DTs. If they are similar and
> just a matter of partitioning, then you can fix up the DT before
> passing to non-secure world (or even do this with a script offline
> (i.e. 1 dts and 2 dtb's)).
That sounds possible, yes.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-01-22 18:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 19:15 Secure resources in device trees Greg Bellows
[not found] ` <CAOgzsHVpXZTHoq7HyfrGeGe92onnb6=BQr30PvKrg04h=0De0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-21 16:21 ` 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 [this message]
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=20150122182707.GD12911@leverpostej \
--to=mark.rutland-5wv7dgnigg8@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=greg.bellows-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@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).