From: Stephen Warren <swarren@wwwdotorg.org>
To: Alexandre Courbot <gnurou@gmail.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>,
Joseph Lo <josephl@nvidia.com>, Karan Jhavar <kjhavar@nvidia.com>,
Varun Wadekar <vwadekar@nvidia.com>,
Chris Johnson <CJohnson@nvidia.com>,
Matthew Longnecker <MLongnecker@nvidia.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: tegra: add basic SecureOS support
Date: Fri, 07 Jun 2013 10:33:10 -0600 [thread overview]
Message-ID: <51B20B46.4030501@wwwdotorg.org> (raw)
In-Reply-To: <CAAVeFu+by44HnOzv_85kwgeCx5b9TxiMhr27x69QcUj9GRbk8A@mail.gmail.com>
On 06/07/2013 02:11 AM, Alexandre Courbot wrote:
> On Fri, Jun 7, 2013 at 1:44 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
>>> Boot loaders on some Tegra devices can be unlocked but do not let the
>>> system operate without SecureOS. SecureOS prevents access to some
>>> registers and requires the operating system to perform certain
>>> operations through Secure Monitor Calls instead of directly accessing
>>> the hardware.
>>>
>>> This patch introduces basic SecureOS support for Tegra. SecureOS support
>>> can be enabled by adding a "nvidia,secure-os" property to the "chosen"
>>> node of the device tree.
>>
>> I suspect "SecureOS" here is the name of a specific implementation of a
>> secure monitor, right? It's certainly a very unfortunate name, since it
>> sounds like a generic concept rather than a specific implementation:-(
>
> Right. Using the actual name (Trusted Foundations) is probably better.
> I don't think the SecureOS denomination is used by anyone else but
> NVIDIA.
>
>> There certainly could be (and I believe are in practice?) multiple
>> implementation of a secure monitor for Tegra. Presumably, each of those
>> implementations has (or could have) a different definition for what SVC
>> calls it supports, their parameters, etc.
>>
>> I think we need to separate the concept of support for *a* secure
>> monitor, from support for a *particular* secure monitor.
>
> Agreed. In this case, can we assume that support for a specific secure
> monitor is not arch-specific, and that this patch should be moved
> outside of arch-tegra and down to arch/arm? In other words, the ABI of
> a particular secure monitor should be the same no matter the chip,
> shouldn't it?
I would like to believe that the Trusted Foundations monitor had the
same ABI irrespective of which Soc it was running on. However, I have
absolutely no idea at all if that's true. Even if there's some common
subset of the ABI that is identical across all SoCs, I wouldn't be too
surprised if there were custom extensions for each different SoC, or
just perhaps even each product.
Can you research this and find out the answer?
What we can always do is make a compatible property that lists
everything[1], and have the driver match on the most specific value for
now, but relax the driver's matching later if it turns out that the ABI
is indeed common.
[1] That'd need to be at least secure OS name, and secure OS version.
Perhaps the SoC and board data can be deduced from the DT's top-level
compatible properties; nvidia,tegra114-shield, nvidia,tegra114?
next prev parent reply other threads:[~2013-06-07 16:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 7:28 [PATCH] ARM: tegra: add basic SecureOS support Alexandre Courbot
2013-06-06 9:35 ` Russell King - ARM Linux
2013-06-06 10:23 ` Alex Courbot
2013-06-06 10:17 ` Tomasz Figa
2013-06-06 10:37 ` Alex Courbot
2013-06-06 16:28 ` Stephen Warren
2013-06-06 11:11 ` Dave Martin
2013-06-06 11:02 ` Dave Martin
2013-06-07 7:25 ` Alexandre Courbot
2013-06-07 17:30 ` Dave Martin
2013-06-10 7:47 ` Alexandre Courbot
2013-06-10 9:10 ` Russell King - ARM Linux
2013-06-06 12:26 ` Jassi Brar
2013-06-07 7:13 ` Alexandre Courbot
2013-06-07 8:52 ` Jassi Brar
2013-06-06 16:44 ` Stephen Warren
2013-06-06 18:08 ` Dave Martin
2013-06-06 18:29 ` Stephen Warren
2013-06-07 17:47 ` Dave Martin
2013-06-07 9:03 ` Alexandre Courbot
2013-06-07 18:13 ` Dave Martin
2013-06-10 8:05 ` Alexandre Courbot
2013-06-10 11:20 ` Dave Martin
2013-06-07 8:11 ` Alexandre Courbot
2013-06-07 16:33 ` Stephen Warren [this message]
2013-06-10 8:11 ` Alexandre Courbot
2013-06-10 9:14 ` Russell King - ARM Linux
2013-06-10 16:35 ` Stephen Warren
2013-06-10 11:16 ` Dave Martin
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=51B20B46.4030501@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=CJohnson@nvidia.com \
--cc=MLongnecker@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=gnurou@gmail.com \
--cc=josephl@nvidia.com \
--cc=kjhavar@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=vwadekar@nvidia.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