questions about arm trustzone

questions about arm trustzone

[sen wang]

we need to build a little os in the secure mode,and run linux in the
normal world.but, can I use gcc to compile the special instructions like 'smc'.
which gcc version can work? and where can i find the example code
switching between the secure and normal worlds?

questions about arm trustzone

[sen wang]

we need to build a little os in the secure mode,and run linux in the
normal world.but, can I use gcc to compile the special instructions like 'smc'.
which gcc version can work? and where can i find the example code
switching between the secure and normal worlds?

Re: questions about arm trustzone

[David Brown]

On Mon, Jan 24 2011, sen wang wrote:

> we need to build a little os in the secure mode,and run linux in the
> normal world.but, can I use gcc to compile the special instructions like 'smc'.
> which gcc version can work? and where can i find the example code
> switching between the secure and normal worlds?

In the 2.6.38-rc2 kernel, arch/arm/mach-msm/scm.c does this.  I don't
think there is any other code in the kernel, yet.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

questions about arm trustzone

[David Brown]

On Mon, Jan 24 2011, sen wang wrote:

> we need to build a little os in the secure mode,and run linux in the
> normal world.but, can I use gcc to compile the special instructions like 'smc'.
> which gcc version can work? and where can i find the example code
> switching between the secure and normal worlds?

In the 2.6.38-rc2 kernel, arch/arm/mach-msm/scm.c does this.  I don't
think there is any other code in the kernel, yet.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: questions about arm trustzone

[sen wang]

thanks,
It seems linux run in the normal world, and the "scm.c"  is the path
to the monitor mode.
where can I find the example code for monitor and secure world?



2011/1/25 David Brown <davidb@codeaurora.org>:
> On Mon, Jan 24 2011, sen wang wrote:
>
>> we need to build a little os in the secure mode,and run linux in the
>> normal world.but, can I use gcc to compile the special instructions like 'smc'.
>> which gcc version can work? and where can i find the example code
>> switching between the secure and normal worlds?
>
> In the 2.6.38-rc2 kernel, arch/arm/mach-msm/scm.c does this.  I don't
> think there is any other code in the kernel, yet.
>
> David
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>

questions about arm trustzone

[sen wang]

thanks,
It seems linux run in the normal world, and the "scm.c" ?is the path
to the monitor mode.
where can I find the example code for monitor and secure world?



2011/1/25 David Brown <davidb@codeaurora.org>:
> On Mon, Jan 24 2011, sen wang wrote:
>
>> we need to build a little os in the secure mode,and run linux in the
>> normal world.but, can I use gcc to compile the special instructions like 'smc'.
>> which gcc version can work? and where can i find the example code
>> switching between the secure and normal worlds?
>
> In the 2.6.38-rc2 kernel, arch/arm/mach-msm/scm.c does this. ?I don't
> think there is any other code in the kernel, yet.
>
> David
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>

Re: questions about arm trustzone

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 05:19:16PM +0800, sen wang wrote:
> It seems linux run in the normal world, and the "scm.c"  is the path
> to the monitor mode.
> where can I find the example code for monitor and secure world?

OMAP also uses smc: arch/arm/mach-omap2/omap44xx-smc.S

There's no interface defined for smc because it's highly vendor and
implementation specific.  It's just like a SWI (or svc) where it
causes entry via a vector into a priviledged mode, which can be
thought of being similar to a branch to a vector with a mode switch.

questions about arm trustzone

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 05:19:16PM +0800, sen wang wrote:
> It seems linux run in the normal world, and the "scm.c" ?is the path
> to the monitor mode.
> where can I find the example code for monitor and secure world?

OMAP also uses smc: arch/arm/mach-omap2/omap44xx-smc.S

There's no interface defined for smc because it's highly vendor and
implementation specific.  It's just like a SWI (or svc) where it
causes entry via a vector into a priviledged mode, which can be
thought of being similar to a branch to a vector with a mode switch.

RE: questions about arm trustzone

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-
> arm-kernel-bounces@lists.infradead.org] On Behalf Of Russell King -
> ARM Linux
> Sent: Tuesday, January 25, 2011 3:57 PM
> To: sen wang
> Cc: David Brown; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: questions about arm trustzone
>
> On Tue, Jan 25, 2011 at 05:19:16PM +0800, sen wang wrote:
> > It seems linux run in the normal world, and the "scm.c"  is the
> path
> > to the monitor mode.
> > where can I find the example code for monitor and secure world?
>
> OMAP also uses smc: arch/arm/mach-omap2/omap44xx-smc.S
>
> There's no interface defined for smc because it's highly vendor and
> implementation specific.  It's just like a SWI (or svc) where it
> causes entry via a vector into a priviledged mode, which can be
> thought of being similar to a branch to a vector with a mode switch.
>
The code above won't give major details of how the monitor mode is
implemented.  But as Russell said, it's pretty much vendor specific.

On OMAP, We have standard API interfaces to enter into monitor
world. One of the parameter denotes the kind of service, is
requested.

Regards,
Santosh

questions about arm trustzone

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of Russell King -
> ARM Linux
> Sent: Tuesday, January 25, 2011 3:57 PM
> To: sen wang
> Cc: David Brown; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: questions about arm trustzone
>
> On Tue, Jan 25, 2011 at 05:19:16PM +0800, sen wang wrote:
> > It seems linux run in the normal world, and the "scm.c" ?is the
> path
> > to the monitor mode.
> > where can I find the example code for monitor and secure world?
>
> OMAP also uses smc: arch/arm/mach-omap2/omap44xx-smc.S
>
> There's no interface defined for smc because it's highly vendor and
> implementation specific.  It's just like a SWI (or svc) where it
> causes entry via a vector into a priviledged mode, which can be
> thought of being similar to a branch to a vector with a mode switch.
>
The code above won't give major details of how the monitor mode is
implemented.  But as Russell said, it's pretty much vendor specific.

On OMAP, We have standard API interfaces to enter into monitor
world. One of the parameter denotes the kind of service, is
requested.

Regards,
Santosh

Re: questions about arm trustzone

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 05:16:19PM +0530, Santosh Shilimkar wrote:
> The code above won't give major details of how the monitor mode is
> implemented.  But as Russell said, it's pretty much vendor specific.
> 
> On OMAP, We have standard API interfaces to enter into monitor
> world. One of the parameter denotes the kind of service, is
> requested.

In much the same way as we do with r7 with the kernels userspace syscall
interface via swi/svc.

questions about arm trustzone

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 05:16:19PM +0530, Santosh Shilimkar wrote:
> The code above won't give major details of how the monitor mode is
> implemented.  But as Russell said, it's pretty much vendor specific.
> 
> On OMAP, We have standard API interfaces to enter into monitor
> world. One of the parameter denotes the kind of service, is
> requested.

In much the same way as we do with r7 with the kernels userspace syscall
interface via swi/svc.

Re: questions about arm trustzone

[Dave Martin]

On Tue, Jan 25, 2011 at 11:46 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-
>> arm-kernel-bounces@lists.infradead.org] On Behalf Of Russell King -
>> ARM Linux
>> Sent: Tuesday, January 25, 2011 3:57 PM
>> To: sen wang
>> Cc: David Brown; linux-kernel@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org
>> Subject: Re: questions about arm trustzone
>>
>> On Tue, Jan 25, 2011 at 05:19:16PM +0800, sen wang wrote:
>> > It seems linux run in the normal world, and the "scm.c"  is the
>> path
>> > to the monitor mode.
>> > where can I find the example code for monitor and secure world?
>>
>> OMAP also uses smc: arch/arm/mach-omap2/omap44xx-smc.S
>>
>> There's no interface defined for smc because it's highly vendor and
>> implementation specific.  It's just like a SWI (or svc) where it
>> causes entry via a vector into a priviledged mode, which can be
>> thought of being similar to a branch to a vector with a mode switch.
>>
> The code above won't give major details of how the monitor mode is
> implemented.  But as Russell said, it's pretty much vendor specific.
>
> On OMAP, We have standard API interfaces to enter into monitor
> world. One of the parameter denotes the kind of service, is
> requested.

I'm going off on a bit of a tangent here, but do you know whether the
Secure World code on OMAP can cope with being called from Thumb?  In
particular, if the Secure World tries to read the comment field from
the SMC instruction (which I notice is non-zero in some cases for
OMAP), it would need to be specifically coded to cope with the Thumb
case for this to work.

Avoiding this complexity is one of the motivations for using r7 for
the syscall number with CONFIG_EABI (instead of using the SVC comment
field).

Currently in my efforts to get the OMAP kernel working in Thumb-2, I
have assumed for simplicity that the Secure World will choke on SMCs
from Thumb code, but it would be nice to minimise the amount of code
which we need to build as ARM in the CONFIG_THUMB2_KERNEL case.  In
principle, everything could be Thumb code, now that the SWP
instruction usage is gone.

Cheers
---Dave

questions about arm trustzone

[Dave Martin]

On Tue, Jan 25, 2011 at 11:46 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
>> arm-kernel-bounces at lists.infradead.org] On Behalf Of Russell King -
>> ARM Linux
>> Sent: Tuesday, January 25, 2011 3:57 PM
>> To: sen wang
>> Cc: David Brown; linux-kernel at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: questions about arm trustzone
>>
>> On Tue, Jan 25, 2011 at 05:19:16PM +0800, sen wang wrote:
>> > It seems linux run in the normal world, and the "scm.c" ?is the
>> path
>> > to the monitor mode.
>> > where can I find the example code for monitor and secure world?
>>
>> OMAP also uses smc: arch/arm/mach-omap2/omap44xx-smc.S
>>
>> There's no interface defined for smc because it's highly vendor and
>> implementation specific. ?It's just like a SWI (or svc) where it
>> causes entry via a vector into a priviledged mode, which can be
>> thought of being similar to a branch to a vector with a mode switch.
>>
> The code above won't give major details of how the monitor mode is
> implemented. ?But as Russell said, it's pretty much vendor specific.
>
> On OMAP, We have standard API interfaces to enter into monitor
> world. One of the parameter denotes the kind of service, is
> requested.

I'm going off on a bit of a tangent here, but do you know whether the
Secure World code on OMAP can cope with being called from Thumb?  In
particular, if the Secure World tries to read the comment field from
the SMC instruction (which I notice is non-zero in some cases for
OMAP), it would need to be specifically coded to cope with the Thumb
case for this to work.

Avoiding this complexity is one of the motivations for using r7 for
the syscall number with CONFIG_EABI (instead of using the SVC comment
field).

Currently in my efforts to get the OMAP kernel working in Thumb-2, I
have assumed for simplicity that the Secure World will choke on SMCs
from Thumb code, but it would be nice to minimise the amount of code
which we need to build as ARM in the CONFIG_THUMB2_KERNEL case.  In
principle, everything could be Thumb code, now that the SWP
instruction usage is gone.

Cheers
---Dave

Re: questions about arm trustzone

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 12:24:13PM +0000, Dave Martin wrote:
> Avoiding this complexity is one of the motivations for using r7 for
> the syscall number with CONFIG_EABI (instead of using the SVC comment
> field).

Your history is not entirely correct.

I had the kernel side of Thumb userspace support in place long before EABI
came along.  Thumb doesn't have a large enough comment field to store the
Linux syscall number, so to get around that problem, I decided to use r7
for the syscall number.  You'll find 2.4 kernels support Thumb instructions
in userspace.

As part of the EABI switch for ARM mode - which created an incompatible
SWI interface anyway, we decided that we could reduce data cache pollution
by eliminating the read of the SWI instruction, so we adopted the r7
method for ARM EABI mode.

questions about arm trustzone

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 12:24:13PM +0000, Dave Martin wrote:
> Avoiding this complexity is one of the motivations for using r7 for
> the syscall number with CONFIG_EABI (instead of using the SVC comment
> field).

Your history is not entirely correct.

I had the kernel side of Thumb userspace support in place long before EABI
came along.  Thumb doesn't have a large enough comment field to store the
Linux syscall number, so to get around that problem, I decided to use r7
for the syscall number.  You'll find 2.4 kernels support Thumb instructions
in userspace.

As part of the EABI switch for ARM mode - which created an incompatible
SWI interface anyway, we decided that we could reduce data cache pollution
by eliminating the read of the SWI instruction, so we adopted the r7
method for ARM EABI mode.

Re: questions about arm trustzone

[Dave Martin]

On Tue, Jan 25, 2011 at 12:45 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 25, 2011 at 12:24:13PM +0000, Dave Martin wrote:
>> Avoiding this complexity is one of the motivations for using r7 for
>> the syscall number with CONFIG_EABI (instead of using the SVC comment
>> field).
>
> Your history is not entirely correct.
>
> I had the kernel side of Thumb userspace support in place long before EABI
> came along.  Thumb doesn't have a large enough comment field to store the
> Linux syscall number, so to get around that problem, I decided to use r7
> for the syscall number.  You'll find 2.4 kernels support Thumb instructions
> in userspace.
>
> As part of the EABI switch for ARM mode - which created an incompatible
> SWI interface anyway, we decided that we could reduce data cache pollution
> by eliminating the read of the SWI instruction, so we adopted the r7
> method for ARM EABI mode.
>

Fair enough -- I was glossing over things a bit and I'm not familiar
with all the history.  So, I guess there were plenty of other good
reasons.

Cheers
---Dave

questions about arm trustzone

[Dave Martin]

On Tue, Jan 25, 2011 at 12:45 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 25, 2011 at 12:24:13PM +0000, Dave Martin wrote:
>> Avoiding this complexity is one of the motivations for using r7 for
>> the syscall number with CONFIG_EABI (instead of using the SVC comment
>> field).
>
> Your history is not entirely correct.
>
> I had the kernel side of Thumb userspace support in place long before EABI
> came along. ?Thumb doesn't have a large enough comment field to store the
> Linux syscall number, so to get around that problem, I decided to use r7
> for the syscall number. ?You'll find 2.4 kernels support Thumb instructions
> in userspace.
>
> As part of the EABI switch for ARM mode - which created an incompatible
> SWI interface anyway, we decided that we could reduce data cache pollution
> by eliminating the read of the SWI instruction, so we adopted the r7
> method for ARM EABI mode.
>

Fair enough -- I was glossing over things a bit and I'm not familiar
with all the history.  So, I guess there were plenty of other good
reasons.

Cheers
---Dave

Re: questions about arm trustzone

[shiraz hashim]

Hello Santosh,

On Tue, Jan 25, 2011 at 5:16 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
[...]

> The code above won't give major details of how the monitor mode is
> implemented.  But as Russell said, it's pretty much vendor specific.
>
> On OMAP, We have standard API interfaces to enter into monitor
> world. One of the parameter denotes the kind of service, is
> requested.

Sorry if following are very naive.
What should be the attributes of a monitor implementation.
- Should it be un-modifiable.
- Does it run in normal (non-secure) mode ?
- Who programs the monitor (and its vector addresses) ?
- Would monitor intend to provide fixed services and how does it
decides that the request for a particular service is valid enough to
enter secure world ?
- Are monitors debuggable ?

thanks in advance for any kind help.

-- 
regards
Shiraz Hashim

questions about arm trustzone

[shiraz hashim]

Hello Santosh,

On Tue, Jan 25, 2011 at 5:16 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
[...]

> The code above won't give major details of how the monitor mode is
> implemented. ?But as Russell said, it's pretty much vendor specific.
>
> On OMAP, We have standard API interfaces to enter into monitor
> world. One of the parameter denotes the kind of service, is
> requested.

Sorry if following are very naive.
What should be the attributes of a monitor implementation.
- Should it be un-modifiable.
- Does it run in normal (non-secure) mode ?
- Who programs the monitor (and its vector addresses) ?
- Would monitor intend to provide fixed services and how does it
decides that the request for a particular service is valid enough to
enter secure world ?
- Are monitors debuggable ?

thanks in advance for any kind help.

-- 
regards
Shiraz Hashim