From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Chris Johnson <CJohnson-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Karan Jhavar <kjhavar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Matthew Longnecker
<MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Joseph Lo <josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] ARM: tegra: add basic SecureOS support
Date: Thu, 06 Jun 2013 10:44:48 -0600 [thread overview]
Message-ID: <51B0BC80.9040007@wwwdotorg.org> (raw)
In-Reply-To: <1370503687-17767-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
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:-(
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.
> diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt
> +node:
> +
> + nvidia,secure-os: enable SecureOS.
... as such, I think some work is needed here to allow specification of
which secure monitor is present and/or which secure monitor ABI it
implements. The suggestion to use a specific DT node, and hence use
compatible values for this, seems reasonable. Alternatively, perhaps:
nvidia,secure-monitor = "name_of_vendor_or_SMC_ABI";
might be reasonable, although using a node would allow ABI-specific
additional properties to be defined should they be needed, so I guess I
would lean towards that.
Similar comments may apply to the CONFIG_ option and description,
filenames, etc.
> diff --git a/arch/arm/mach-tegra/secureos.c b/arch/arm/mach-tegra/secureos.c
> +void __init tegra_init_secureos(void)
> +{
> + struct device_node *node = of_find_node_by_path("/chosen");
> +
> + if (node && of_property_read_bool(node, "nvidia,secure-os"))
> + register_firmware_ops(&tegra_firmware_ops);
> +}
I'm tempted to think that function should /always/ exist an be called
(so no dummy inline in secureos.h).
In particular, what happens when a kernel without CONFIG_SECUREOS
enabled is booted under a secure monitor. Presumably we want the init
code to explicitly check for this condition, and either BUG(), or do
something to disable any features (like SMP) that require SVCs?
So, the algorithm here might be more like:
find node
if node exists
if (!IS_ENABLED(SECURE_OS))
BUG/WARN/...
else
register_firmware_ops()
?
next prev parent reply other threads:[~2013-06-06 16:44 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
[not found] ` <1370503687-17767-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-06-06 9:35 ` Russell King - ARM Linux
[not found] ` <20130606093524.GM18614-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
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
[not found] ` <20130606110240.GA3320-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2013-06-07 7:25 ` Alexandre Courbot
2013-06-07 17:30 ` Dave Martin
2013-06-10 7:47 ` Alexandre Courbot
[not found] ` <CAAVeFuJuf2hrMaM5keoai65vAAg6JLrjDUvYm4e2zQvsw64_8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-10 9:10 ` Russell King - ARM Linux
2013-06-06 12:26 ` Jassi Brar
[not found] ` <CABb+yY2SFfejMbbYOebMCUuMtAZF3u-yc+6z_MJTG2oOeSwL_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-07 7:13 ` Alexandre Courbot
[not found] ` <CAAVeFuKxRuLdhO+-+YHG=c-TNGUUJbDj5AHj+K5e8y1JDEDksg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-07 8:52 ` Jassi Brar
2013-06-06 16:44 ` Stephen Warren [this message]
2013-06-06 18:08 ` Dave Martin
[not found] ` <20130606180824.GC3320-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2013-06-06 18:29 ` Stephen Warren
[not found] ` <51B0D4FA.5070500-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-06-07 17:47 ` Dave Martin
2013-06-07 9:03 ` Alexandre Courbot
[not found] ` <CAAVeFuJkV3VVfeinLrjCCef9ZqJNvKurQwVWnJsW-bZqniTQ1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-07 18:13 ` Dave Martin
[not found] ` <20130607181318.GC29344-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2013-06-10 8:05 ` Alexandre Courbot
[not found] ` <CAAVeFuKsa=GsxexQOSOYPYvkAXaEZXfW1+zRmv25CtFEY=T_GQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-10 11:20 ` Dave Martin
[not found] ` <51B0BC80.9040007-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-06-07 8:11 ` Alexandre Courbot
[not found] ` <CAAVeFu+by44HnOzv_85kwgeCx5b9TxiMhr27x69QcUj9GRbk8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-07 16:33 ` Stephen Warren
2013-06-10 8:11 ` Alexandre Courbot
[not found] ` <CAAVeFu+UMZikdWO20c9chvBcieOAUgOhz-nTEUpevFWnPNC_ZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-10 9:14 ` Russell King - ARM Linux
[not found] ` <20130610091415.GS18614-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
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=51B0BC80.9040007@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=CJohnson-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=kjhavar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@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 NNTP newsgroup(s).