From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: smccc-call: Use r12 to route secure monitor calls on TI platforms
Date: Tue, 19 Sep 2017 15:19:54 +0100 [thread overview]
Message-ID: <20170919141953.GH30715@leverpostej> (raw)
In-Reply-To: <20170918205005.30235-1-afd@ti.com>
On Mon, Sep 18, 2017 at 03:50:04PM -0500, Andrew F. Davis wrote:
> Our ROM Secure Monitor(SM) uses the value in r12 to determine which
> service is being requested by an SMC call. This inline with the ARM
> recommended SMC Calling Convention(SMCCC), which partitions the values
> in R0 for this task, OP-TEE's SM follows the ARM recommended convention.
I can't parse this last sentence. What exactly is inline with the SMCCC?
AFAICT, the SMCCC says r12 is "The Intra-Procedure-call scratch
register", which is not a paramter, service ID, etc.
> We need a way to signal that a call is for the OP-TEE SM and not for
> the ROM SM in a way that is safe for the ROM SM, in case it is still
> present. We do this by putting a value of 0x200 in r12 when the call
> is for OP-TEE or any other ARM by modifying the SMCCC caller function.
So IIUC, you have a secure monitor which is not SMCCC compliant, but you
want to use it at the same time as OP-TEE, which is SMCCC compliant.
It would be much better to have a new version of that monitor that was
SMCCC compliant, and have to update the code for that, than to have to
move OP-TEE away from standards compliance.
> There are four combinations of events:
>
> If the ROM SM is present and we make a legacy style SMC call, as we
> do in early boot, the call will not have r12 set to 0x200 as these
> calls go through existing mach-omap2/ SMC handlers, so all is well.
>
> If the ROM SM is present and we make an SMCCC style call, r12 will be
> set to 0x200 and ROM SM will see this as an invalid service call and
> safely return to the normal world.
So you're going to describe OP-TEE as present even when it's not!?
That's simply wrong.
> If OP-TEE is present and we make a legacy style SMC call, r12 will
> not be set to 0x200, and OP-TEE will emulate the functionality that
> the call is requesting.
AFAICT this means that OP-TEE completely replaces your existing monitor.
Please fix this properly. Implement SMCCC-compliant versions of those
calls you wish to retain, and come up with a new binding for those.
Describe that in the DT for systems which have OP-TEE providing these
services.
Systems with the old monitor should have that descrbied in their DT, and
not OP-TEE.
That completely removes the need to come up with a new OP-TEE binding
extension, and aligns your FW for forward compatibility with future
services.
Thanks,
Mark.
next parent reply other threads:[~2017-09-19 14:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170918205005.30235-1-afd@ti.com>
2017-09-19 14:19 ` Mark Rutland [this message]
2017-09-19 15:07 ` [PATCH 1/2] ARM: smccc-call: Use r12 to route secure monitor calls on TI platforms Andrew F. Davis
2017-09-21 14:47 ` Mark Rutland
[not found] ` <20170918205005.30235-2-afd@ti.com>
2017-09-19 13:36 ` [PATCH 2/2] tee: optee: allow selection of ti-smc as a calling method Rob Herring
2017-09-19 15:54 ` Andrew F. Davis
2017-09-19 21:10 ` Rob Herring
2017-09-19 14:09 ` Mark Rutland
2017-09-20 0:27 ` kbuild test robot
2017-09-20 0:44 ` kbuild test robot
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=20170919141953.GH30715@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.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