[ARM ATTEND] Trustzone-based security solution for ARM Linux

[ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

For the moment, there is strong markting requirement from
IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
IVI as an example, Auto requires security enviorment to access CAN bus
and other car busses. Auto requires security enviorment to show
rearview/surround view from cameras and play alert audio. on the other
hand, IVI system is generically working as a video streaming sink and
HDMI sink instead of a source. To support HDCP and widevine, we need
to make sure private keys and video buffers are only visible to
security mode. With CAN stack, video playback backend and more tasks,
generically it requires a multi-task RTOS running in security mode
parallel with Linux in non-security mode.

Linux is a generic purpose OS with UI and all kinds of software, but
we need to make sure even the Linux is ROOTed, RTOS in security mode
is still active. We are able to find some opensource projects like
SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
Linux has no rich support for this kind of architecture:
1. hypervisor running in monitor mode
2. RTOS running in security mode
3. Linux running in non-security mode

So the point is that we need generic support for this, especially for
IVI and other markets which want Trustzone technology a lot and have
complex user scenarios.
1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
is not permitted to happen on Linux
2. IPC support for communication between RTOS in security mode and
Linux in non-security mode, as we need to communicate rich commands
and buffers
3. as some CPU time is stolen by security mode, so the scheduler need
to get this for load balance

For IPC, RPMsg is kind of popular for commucating cross HMP. For
example, OMAP uses it as the IPC between M3 and A9; XilinX uses it as
IPC between two A9, one with FreeRTOS, the other one with Linux; ST-E
uses it to connect ARM with modem MCU. So we are also considering the
possibility to involve RPMsg as the backend for communication between
RTOS in security mode and Linux in non-security mode. then we get much
benefit from virtio, and some drivers will be usable directly.

So for this topic, I want a presentation session with about 5 slides
to show the high-level architecture and requirement for a real and
complex Trustzone user case. Hoping we can get some rich support from
Linux for this architecture.

On the other hand, if people can discuss Android mainlining project
more, i like much. for the moment, most Android patches have been
mainlined, but we still need to maintain both branches as there are
rebased patches from Google. So i want to get input about best
pratice.

[1]SafeG (Safety Gate):
http://www.toppers.jp/en/safeg.html
[2]Green Hills Multivisor:
http://www.ghs.com/products/rtos/integrity_virtualization.html
[3]SierraVisor:
http://www.openvirtualization.org/

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Greg KH]

On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
> For the moment, there is strong markting requirement from
> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
> IVI as an example, Auto requires security enviorment to access CAN bus
> and other car busses. Auto requires security enviorment to show
> rearview/surround view from cameras and play alert audio. on the other
> hand, IVI system is generically working as a video streaming sink and
> HDMI sink instead of a source. To support HDCP and widevine, we need
> to make sure private keys and video buffers are only visible to
> security mode. With CAN stack, video playback backend and more tasks,
> generically it requires a multi-task RTOS running in security mode
> parallel with Linux in non-security mode.
> 
> Linux is a generic purpose OS with UI and all kinds of software, but
> we need to make sure even the Linux is ROOTed, RTOS in security mode
> is still active. We are able to find some opensource projects like
> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
> Linux has no rich support for this kind of architecture:
> 1. hypervisor running in monitor mode
> 2. RTOS running in security mode
> 3. Linux running in non-security mode

"Linux" is just a kernel, not a whole operating system :)

Anyway, why can't Linux be the RTOS kernel as well?  What are the
requirements for that kernel that Linux does not currently meet?

> So the point is that we need generic support for this, especially for
> IVI and other markets which want Trustzone technology a lot and have
> complex user scenarios.
> 1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
> is not permitted to happen on Linux

Isn't that up to the hardware?  Nothing that Linux can do about that.

> 2. IPC support for communication between RTOS in security mode and
> Linux in non-security mode, as we need to communicate rich commands
> and buffers

What about using the virtual protocols we already have today for the
existing hypervisors?  Don't reinvent something new if you don't have
to.

> 3. as some CPU time is stolen by security mode, so the scheduler need
> to get this for load balance

Does the kernel know this time is gone?  Or is it not aware of it (like
MSIs on x86?)

thanks,

greg k-h

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Jassi Brar]

On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>> For the moment, there is strong markting requirement from
>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>> IVI as an example, Auto requires security enviorment to access CAN bus
>> and other car busses. Auto requires security enviorment to show
>> rearview/surround view from cameras and play alert audio. on the other
>> hand, IVI system is generically working as a video streaming sink and
>> HDMI sink instead of a source. To support HDCP and widevine, we need
>> to make sure private keys and video buffers are only visible to
>> security mode. With CAN stack, video playback backend and more tasks,
>> generically it requires a multi-task RTOS running in security mode
>> parallel with Linux in non-security mode.
>>
>> Linux is a generic purpose OS with UI and all kinds of software, but
>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>> is still active. We are able to find some opensource projects like
>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>> Linux has no rich support for this kind of architecture:
>> 1. hypervisor running in monitor mode
>> 2. RTOS running in security mode
>> 3. Linux running in non-security mode
>
> "Linux" is just a kernel, not a whole operating system :)
>
> Anyway, why can't Linux be the RTOS kernel as well?  What are the
> requirements for that kernel that Linux does not currently meet?
>
Yes, in fact at least during development Linux usually runs in Secure mode.
Ideally I would love to see 2 instances of Linux running - one in
NonSecure mode and another in Secure mode, getting capabilities via 2
corresponding DTBs reflecting the h/w partitioning done by the TZ.

>
>> 3. as some CPU time is stolen by security mode, so the scheduler need
>> to get this for load balance
>
> Does the kernel know this time is gone?  Or is it not aware of it (like
> MSIs on x86?)
>
The TrustedOS could share time on the same cpu as the UnTrustedOS or
be assigned a dedicated cpu on an MP.

cheers.
-jassi

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
> On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
>> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>>> For the moment, there is strong markting requirement from
>>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>>> IVI as an example, Auto requires security enviorment to access CAN bus
>>> and other car busses. Auto requires security enviorment to show
>>> rearview/surround view from cameras and play alert audio. on the other
>>> hand, IVI system is generically working as a video streaming sink and
>>> HDMI sink instead of a source. To support HDCP and widevine, we need
>>> to make sure private keys and video buffers are only visible to
>>> security mode. With CAN stack, video playback backend and more tasks,
>>> generically it requires a multi-task RTOS running in security mode
>>> parallel with Linux in non-security mode.
>>>
>>> Linux is a generic purpose OS with UI and all kinds of software, but
>>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>>> is still active. We are able to find some opensource projects like
>>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>>> Linux has no rich support for this kind of architecture:
>>> 1. hypervisor running in monitor mode
>>> 2. RTOS running in security mode
>>> 3. Linux running in non-security mode
>>
>> "Linux" is just a kernel, not a whole operating system :)
>>
>> Anyway, why can't Linux be the RTOS kernel as well?  What are the
>> requirements for that kernel that Linux does not currently meet?

we will run rtos+linux instead of linux+linux. typically, Auto
industry has long history to use rtos. on the other hand, we need to
boot the rtos very fast in hundreds of milliseconds to make sure
rearview, early audio have been ready.

>>
> Yes, in fact at least during development Linux usually runs in Secure mode.
> Ideally I would love to see 2 instances of Linux running - one in
> NonSecure mode and another in Secure mode, getting capabilities via 2
> corresponding DTBs reflecting the h/w partitioning done by the TZ.

not real. i think there are similar users in linux already. at least
omap and exynos have some chip specific codes like omap-smc.S,
sleep34xx.S, exynos-smc.S and so on.

and i have explained why we don't use linux+linux.

>
>>
>>> 3. as some CPU time is stolen by security mode, so the scheduler need
>>> to get this for load balance
>>
>> Does the kernel know this time is gone?  Or is it not aware of it (like
>> MSIs on x86?)
>>
> The TrustedOS could share time on the same cpu as the UnTrustedOS or
> be assigned a dedicated cpu on an MP.

no. TrustedOS will not hold a whole CPU and we don't put a whole core
to RTOS as it has low CPU loading.
Linux need to know how much time has been taken by TrustOS for every
core, and do load balance considering stolen time by TrustOS.

>
> cheers.
> -jassi

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Greg KH]

On Thu, Aug 15, 2013 at 03:45:13PM +0800, Barry Song wrote:
> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
> > On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
> >>> For the moment, there is strong markting requirement from
> >>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
> >>> IVI as an example, Auto requires security enviorment to access CAN bus
> >>> and other car busses. Auto requires security enviorment to show
> >>> rearview/surround view from cameras and play alert audio. on the other
> >>> hand, IVI system is generically working as a video streaming sink and
> >>> HDMI sink instead of a source. To support HDCP and widevine, we need
> >>> to make sure private keys and video buffers are only visible to
> >>> security mode. With CAN stack, video playback backend and more tasks,
> >>> generically it requires a multi-task RTOS running in security mode
> >>> parallel with Linux in non-security mode.
> >>>
> >>> Linux is a generic purpose OS with UI and all kinds of software, but
> >>> we need to make sure even the Linux is ROOTed, RTOS in security mode
> >>> is still active. We are able to find some opensource projects like
> >>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
> >>> Linux has no rich support for this kind of architecture:
> >>> 1. hypervisor running in monitor mode
> >>> 2. RTOS running in security mode
> >>> 3. Linux running in non-security mode
> >>
> >> "Linux" is just a kernel, not a whole operating system :)
> >>
> >> Anyway, why can't Linux be the RTOS kernel as well?  What are the
> >> requirements for that kernel that Linux does not currently meet?
> 
> we will run rtos+linux instead of linux+linux. typically, Auto
> industry has long history to use rtos. on the other hand, we need to
> boot the rtos very fast in hundreds of milliseconds to make sure
> rearview, early audio have been ready.

But Linux is a RTOS, and a really good one at that.  Linux already boots
that fast, and solves the rearview/early audio issue just fine (I've
seen it demoed), so please don't think that Linux can't do this.

Again, what is the requirements of this RTOS that prevent you from using
Linux instead in that "secure" part of the chip?  What do we need to
change in order to meet this need?

> > Yes, in fact at least during development Linux usually runs in Secure mode.
> > Ideally I would love to see 2 instances of Linux running - one in
> > NonSecure mode and another in Secure mode, getting capabilities via 2
> > corresponding DTBs reflecting the h/w partitioning done by the TZ.
> 
> not real. i think there are similar users in linux already. at least
> omap and exynos have some chip specific codes like omap-smc.S,
> sleep34xx.S, exynos-smc.S and so on.
> 
> and i have explained why we don't use linux+linux.

I still don't understand why not.  Boot/audio don't seem like good
reasons, again because other people have used Linux just fine for that
application, meeting those legal requirements, in IVI systems.  I know
of a number of companies that will sell you Linux for that very
application, so you could just buy it from someone else if you don't
want to build it yourself :)

> >>> 3. as some CPU time is stolen by security mode, so the scheduler need
> >>> to get this for load balance
> >>
> >> Does the kernel know this time is gone?  Or is it not aware of it (like
> >> MSIs on x86?)
> >>
> > The TrustedOS could share time on the same cpu as the UnTrustedOS or
> > be assigned a dedicated cpu on an MP.
> 
> no. TrustedOS will not hold a whole CPU and we don't put a whole core
> to RTOS as it has low CPU loading.
> Linux need to know how much time has been taken by TrustOS for every
> core, and do load balance considering stolen time by TrustOS.

How will it be told that it just lost an amount of time?  How is that
loss of time supposed to affect the scheduler?  What do you expect the
scheduler to do in response to this loss?

thanks,

greg k-h

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/15 Greg KH <greg@kroah.com>:
> On Thu, Aug 15, 2013 at 03:45:13PM +0800, Barry Song wrote:
>> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
>> > On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
>> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>> >>> For the moment, there is strong markting requirement from
>> >>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>> >>> IVI as an example, Auto requires security enviorment to access CAN bus
>> >>> and other car busses. Auto requires security enviorment to show
>> >>> rearview/surround view from cameras and play alert audio. on the other
>> >>> hand, IVI system is generically working as a video streaming sink and
>> >>> HDMI sink instead of a source. To support HDCP and widevine, we need
>> >>> to make sure private keys and video buffers are only visible to
>> >>> security mode. With CAN stack, video playback backend and more tasks,
>> >>> generically it requires a multi-task RTOS running in security mode
>> >>> parallel with Linux in non-security mode.
>> >>>
>> >>> Linux is a generic purpose OS with UI and all kinds of software, but
>> >>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>> >>> is still active. We are able to find some opensource projects like
>> >>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>> >>> Linux has no rich support for this kind of architecture:
>> >>> 1. hypervisor running in monitor mode
>> >>> 2. RTOS running in security mode
>> >>> 3. Linux running in non-security mode
>> >>
>> >> "Linux" is just a kernel, not a whole operating system :)
>> >>
>> >> Anyway, why can't Linux be the RTOS kernel as well?  What are the
>> >> requirements for that kernel that Linux does not currently meet?
>>
>> we will run rtos+linux instead of linux+linux. typically, Auto
>> industry has long history to use rtos. on the other hand, we need to
>> boot the rtos very fast in hundreds of milliseconds to make sure
>> rearview, early audio have been ready.
>
> But Linux is a RTOS, and a really good one at that.  Linux already boots
> that fast, and solves the rearview/early audio issue just fine (I've
> seen it demoed), so please don't think that Linux can't do this.
>

i think my key point is it doesn't really matter whether linux or rtos
will work as backend, my key point is that we need one OS running in
security mode, the other one running in non-security mode. if linux is
good enough, linux can be the RTOS of backend.

i believe linux can do early audio/rearview well as CSR has delivered
this kind of solution already with some ugly hacking in kernel. it is
not easy to upstream them.

we have product lines for camera and auto, camera has used non-linux
RTOS not linux for a long term, so we need to re-use codes of ISP as
many as possible. BTW, Auto industry customers don't like putting CAN
stack to linux as they have a long history without linux, they are
using Auto RTOS.


> Again, what is the requirements of this RTOS that prevent you from using
> Linux instead in that "secure" part of the chip?  What do we need to
> change in order to meet this need?

if we have linux+linux, we need same changes in linux as well.

>
>> > Yes, in fact at least during development Linux usually runs in Secure mode.
>> > Ideally I would love to see 2 instances of Linux running - one in
>> > NonSecure mode and another in Secure mode, getting capabilities via 2
>> > corresponding DTBs reflecting the h/w partitioning done by the TZ.
>>
>> not real. i think there are similar users in linux already. at least
>> omap and exynos have some chip specific codes like omap-smc.S,
>> sleep34xx.S, exynos-smc.S and so on.
>>
>> and i have explained why we don't use linux+linux.
>
> I still don't understand why not.  Boot/audio don't seem like good
> reasons, again because other people have used Linux just fine for that
> application, meeting those legal requirements, in IVI systems.  I know
> of a number of companies that will sell you Linux for that very
> application, so you could just buy it from someone else if you don't
> want to build it yourself :)

let's just ignore the issue whether backend should be linux or another
rtos as that doesn't change my requirement about linux :-)

>
>> >>> 3. as some CPU time is stolen by security mode, so the scheduler need
>> >>> to get this for load balance
>> >>
>> >> Does the kernel know this time is gone?  Or is it not aware of it (like
>> >> MSIs on x86?)
>> >>
>> > The TrustedOS could share time on the same cpu as the UnTrustedOS or
>> > be assigned a dedicated cpu on an MP.
>>
>> no. TrustedOS will not hold a whole CPU and we don't put a whole core
>> to RTOS as it has low CPU loading.
>> Linux need to know how much time has been taken by TrustOS for every
>> core, and do load balance considering stolen time by TrustOS.
>
> How will it be told that it just lost an amount of time?  How is that
> loss of time supposed to affect the scheduler?  What do you expect the
> scheduler to do in response to this loss?

i think in kvm and xen, we need to implement a callback to tell linux
about stolen time. but now we just trap into security, we need to tell
linux as well.

stolen time will affect the "power" of the core, so affect the loading
which is equal with loading/power. after time is stolen, power will be
less, so with same linux loading, the core with stolen time will
result in more actual loading as its power is lower, scheduler will
know it and balance linux tasks.

>
> thanks,
>
> greg k-h

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Greg KH]

On Thu, Aug 15, 2013 at 04:22:18PM +0800, Barry Song wrote:
> 2013/8/15 Greg KH <greg@kroah.com>:
> > On Thu, Aug 15, 2013 at 03:45:13PM +0800, Barry Song wrote:
> >> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
> >> > On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
> >> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
> >> >>> For the moment, there is strong markting requirement from
> >> >>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
> >> >>> IVI as an example, Auto requires security enviorment to access CAN bus
> >> >>> and other car busses. Auto requires security enviorment to show
> >> >>> rearview/surround view from cameras and play alert audio. on the other
> >> >>> hand, IVI system is generically working as a video streaming sink and
> >> >>> HDMI sink instead of a source. To support HDCP and widevine, we need
> >> >>> to make sure private keys and video buffers are only visible to
> >> >>> security mode. With CAN stack, video playback backend and more tasks,
> >> >>> generically it requires a multi-task RTOS running in security mode
> >> >>> parallel with Linux in non-security mode.
> >> >>>
> >> >>> Linux is a generic purpose OS with UI and all kinds of software, but
> >> >>> we need to make sure even the Linux is ROOTed, RTOS in security mode
> >> >>> is still active. We are able to find some opensource projects like
> >> >>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
> >> >>> Linux has no rich support for this kind of architecture:
> >> >>> 1. hypervisor running in monitor mode
> >> >>> 2. RTOS running in security mode
> >> >>> 3. Linux running in non-security mode
> >> >>
> >> >> "Linux" is just a kernel, not a whole operating system :)
> >> >>
> >> >> Anyway, why can't Linux be the RTOS kernel as well?  What are the
> >> >> requirements for that kernel that Linux does not currently meet?
> >>
> >> we will run rtos+linux instead of linux+linux. typically, Auto
> >> industry has long history to use rtos. on the other hand, we need to
> >> boot the rtos very fast in hundreds of milliseconds to make sure
> >> rearview, early audio have been ready.
> >
> > But Linux is a RTOS, and a really good one at that.  Linux already boots
> > that fast, and solves the rearview/early audio issue just fine (I've
> > seen it demoed), so please don't think that Linux can't do this.
> >
> 
> i think my key point is it doesn't really matter whether linux or rtos
> will work as backend, my key point is that we need one OS running in
> security mode, the other one running in non-security mode. if linux is
> good enough, linux can be the RTOS of backend.

Great, I'm glad we agree :)

> i believe linux can do early audio/rearview well as CSR has delivered
> this kind of solution already with some ugly hacking in kernel. it is
> not easy to upstream them.

What specific "hacks" did you have to do?  Do you have a pointer to them
anywhere so that we can see what we need to integrate into mainline?
Have you tried to merge them and gotten push-back?

> > Again, what is the requirements of this RTOS that prevent you from using
> > Linux instead in that "secure" part of the chip?  What do we need to
> > change in order to meet this need?
> 
> if we have linux+linux, we need same changes in linux as well.

I agree, do you have pointers to where you have made these changes
already to show that it can be done?

> let's just ignore the issue whether backend should be linux or another
> rtos as that doesn't change my requirement about linux :-)

Fair enough :)

> >> >>> 3. as some CPU time is stolen by security mode, so the scheduler need
> >> >>> to get this for load balance
> >> >>
> >> >> Does the kernel know this time is gone?  Or is it not aware of it (like
> >> >> MSIs on x86?)
> >> >>
> >> > The TrustedOS could share time on the same cpu as the UnTrustedOS or
> >> > be assigned a dedicated cpu on an MP.
> >>
> >> no. TrustedOS will not hold a whole CPU and we don't put a whole core
> >> to RTOS as it has low CPU loading.
> >> Linux need to know how much time has been taken by TrustOS for every
> >> core, and do load balance considering stolen time by TrustOS.
> >
> > How will it be told that it just lost an amount of time?  How is that
> > loss of time supposed to affect the scheduler?  What do you expect the
> > scheduler to do in response to this loss?
> 
> i think in kvm and xen, we need to implement a callback to tell linux
> about stolen time. but now we just trap into security, we need to tell
> linux as well.

For kvm and xen we don't have a callback into the scheduler (or at least
if we do, I don't know about it, do you have a pointer to it?)

> stolen time will affect the "power" of the core, so affect the loading
> which is equal with loading/power. after time is stolen, power will be
> less, so with same linux loading, the core with stolen time will
> result in more actual loading as its power is lower, scheduler will
> know it and balance linux tasks.

Ah, so do you say this ties into the "power scheduling" changes that
people are proposing?  Have you looked at those patches?  Otherwise,
just like with kvm and xen and vmware and hyperv, the scheduler doesn't
know anything about the "lost" ticks, nor does it need to, as it's only
concerned about scheduing the tasks it has control over, not the ones it
can't do anything about (i.e. the "stolen" time.)

thanks,

greg k-h

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/16 Greg KH <greg@kroah.com>:
> On Thu, Aug 15, 2013 at 04:22:18PM +0800, Barry Song wrote:
>> 2013/8/15 Greg KH <greg@kroah.com>:
>> > On Thu, Aug 15, 2013 at 03:45:13PM +0800, Barry Song wrote:
>> >> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
>> >> > On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
>> >> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>> >> >>> For the moment, there is strong markting requirement from
>> >> >>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>> >> >>> IVI as an example, Auto requires security enviorment to access CAN bus
>> >> >>> and other car busses. Auto requires security enviorment to show
>> >> >>> rearview/surround view from cameras and play alert audio. on the other
>> >> >>> hand, IVI system is generically working as a video streaming sink and
>> >> >>> HDMI sink instead of a source. To support HDCP and widevine, we need
>> >> >>> to make sure private keys and video buffers are only visible to
>> >> >>> security mode. With CAN stack, video playback backend and more tasks,
>> >> >>> generically it requires a multi-task RTOS running in security mode
>> >> >>> parallel with Linux in non-security mode.
>> >> >>>
>> >> >>> Linux is a generic purpose OS with UI and all kinds of software, but
>> >> >>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>> >> >>> is still active. We are able to find some opensource projects like
>> >> >>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>> >> >>> Linux has no rich support for this kind of architecture:
>> >> >>> 1. hypervisor running in monitor mode
>> >> >>> 2. RTOS running in security mode
>> >> >>> 3. Linux running in non-security mode
>> >> >>
>> >> >> "Linux" is just a kernel, not a whole operating system :)
>> >> >>
>> >> >> Anyway, why can't Linux be the RTOS kernel as well?  What are the
>> >> >> requirements for that kernel that Linux does not currently meet?
>> >>
>> >> we will run rtos+linux instead of linux+linux. typically, Auto
>> >> industry has long history to use rtos. on the other hand, we need to
>> >> boot the rtos very fast in hundreds of milliseconds to make sure
>> >> rearview, early audio have been ready.
>> >
>> > But Linux is a RTOS, and a really good one at that.  Linux already boots
>> > that fast, and solves the rearview/early audio issue just fine (I've
>> > seen it demoed), so please don't think that Linux can't do this.
>> >
>>
>> i think my key point is it doesn't really matter whether linux or rtos
>> will work as backend, my key point is that we need one OS running in
>> security mode, the other one running in non-security mode. if linux is
>> good enough, linux can be the RTOS of backend.
>
> Great, I'm glad we agree :)
>
>> i believe linux can do early audio/rearview well as CSR has delivered
>> this kind of solution already with some ugly hacking in kernel. it is
>> not easy to upstream them.
>
> What specific "hacks" did you have to do?  Do you have a pointer to them
> anywhere so that we can see what we need to integrate into mainline?
> Have you tried to merge them and gotten push-back?

in the system, we use normal big rootfs in external SD/NAND. but we
put some user non-mechanism policy, for example, move i2c
initialization earlier(camera sensor needs i2c), move lcd earlies, and
if anytime users touch the key, a kernel thread in video driver will
call lcd directly to show the rearview. that makes us not need to wait
for userspace and other drivers ready.
some things like
https://git.kernel.org/cgit/linux/kernel/git/baohua/linux.git/commit/?h=sirf-devel&id=e8982f9f81bc4757fd73aebf16dd441eff00e941
https://git.kernel.org/cgit/linux/kernel/git/baohua/linux.git/commit/?h=sirf-devel&id=74bb0f76d2d94984667a1a522dae94598c50c680
https://git.kernel.org/cgit/linux/kernel/git/baohua/linux.git/commit/?h=sirf-devel&id=2f342ed9cc734c7b80cf4018a5020d9daab7e75e

as they are totally ugly, so they are just in local tree.

>
>> > Again, what is the requirements of this RTOS that prevent you from using
>> > Linux instead in that "secure" part of the chip?  What do we need to
>> > change in order to meet this need?
>>
>> if we have linux+linux, we need same changes in linux as well.
>
> I agree, do you have pointers to where you have made these changes
> already to show that it can be done?
>
>> let's just ignore the issue whether backend should be linux or another
>> rtos as that doesn't change my requirement about linux :-)
>
> Fair enough :)
>
>> >> >>> 3. as some CPU time is stolen by security mode, so the scheduler need
>> >> >>> to get this for load balance
>> >> >>
>> >> >> Does the kernel know this time is gone?  Or is it not aware of it (like
>> >> >> MSIs on x86?)
>> >> >>
>> >> > The TrustedOS could share time on the same cpu as the UnTrustedOS or
>> >> > be assigned a dedicated cpu on an MP.
>> >>
>> >> no. TrustedOS will not hold a whole CPU and we don't put a whole core
>> >> to RTOS as it has low CPU loading.
>> >> Linux need to know how much time has been taken by TrustOS for every
>> >> core, and do load balance considering stolen time by TrustOS.
>> >
>> > How will it be told that it just lost an amount of time?  How is that
>> > loss of time supposed to affect the scheduler?  What do you expect the
>> > scheduler to do in response to this loss?
>>
>> i think in kvm and xen, we need to implement a callback to tell linux
>> about stolen time. but now we just trap into security, we need to tell
>> linux as well.
>
> For kvm and xen we don't have a callback into the scheduler (or at least
> if we do, I don't know about it, do you have a pointer to it?)
>
>> stolen time will affect the "power" of the core, so affect the loading
>> which is equal with loading/power. after time is stolen, power will be
>> less, so with same linux loading, the core with stolen time will
>> result in more actual loading as its power is lower, scheduler will
>> know it and balance linux tasks.
>
> Ah, so do you say this ties into the "power scheduling" changes that
> people are proposing?  Have you looked at those patches?  Otherwise,
> just like with kvm and xen and vmware and hyperv, the scheduler doesn't
> know anything about the "lost" ticks, nor does it need to, as it's only
> concerned about scheduing the tasks it has control over, not the ones it
> can't do anything about (i.e. the "stolen" time.)

i am not saying "power scheduling", here the power i said is the
calculation ability of the cpu(the MIPS), not the power consumption.
for example, a higher frequency core has higher power. CFS will think
the real loading =  tasks loading / core power. so if core A has lower
power, core B has higher power, with same tasks, CFS knows core A is
busier than core B, will not put tasks to core A.
if you refer to: http://lxr.linux.no/#linux+v3.10.7/kernel/sched/fair.c#L4930

4959                /*
4960                 * For the load comparisons with the other cpu's, consider
4961                 * the weighted_cpuload() scaled with the cpu power, so that
4962                 * the load can be moved away from the cpu that is
potentially
4963                 * running at a lower capacity.
4964                 */
4965                wl = (wl * SCHED_POWER_SCALE) / power;


for IRQ, stolen time, realtime tasks, CFS will adjust the power based
on how much time has been taken away by them. more time is taken away
from IRQ/RT/non-Linux, lower power will be given to the core:

#if defined(CONFIG_IRQ_TIME_ACCOUNTING) ||
defined(CONFIG_PARAVIRT_TIME_ACCOUNTING)
        if ((irq_delta + steal) && sched_feat(NONTASK_POWER))
                sched_rt_avg_update(rq, irq_delta + steal);
#endif

unsigned long scale_rt_power(int cpu)
{
?
      available = total - rq->rt_avg;

      return div_u64(available, total);
}

 static void update_cpu_power(struct sched_domain *sd, int cpu)
 {
        ?

       power *= scale_rt_power(cpu);
       power >>= SCHED_LOAD_SHIFT;

      ?
}


in kvm, the way of calculating stolen time is:

static inline u64 paravirt_steal_clock(int cpu)
{
        return PVOP_CALL1(u64, pv_time_ops.steal_clock, cpu);
}

pv_time_ops.steal_clock = kvm_steal_clock;

static u64 kvm_steal_clock(int cpu)
{
        u64 steal;
        struct kvm_steal_time *src;
        int version;

        src = &per_cpu(steal_time, cpu);
        do {
                version = src->version;
                rmb();
                steal = src->steal;
                rmb();
        } while ((version & 1) || (version != src->version));

        return steal;
}


here, with trustzone-enabled, when linux traps into security mode,
linux doesn't know how much time has been taken away by security mode,
that will not result in enough information to scheduler for load
balance.

for example,
core A: 1 linux task + 90% security time by SMC(monitor mode call like
SWI for trapping into kernel from userspace)
core B: 5 linux task + 1% security time by SMC

Linux will think core B is much busier than core A, then move B tasks
to core A, but actually A has lost power due to 90% time is not
available to Linux.

just an example, it might not make lots of senses for real user
scenerios. but it is enough to explain my problem.


>
> thanks,
>
> greg k-h

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Ard Biesheuvel]

On 15 August 2013 10:05, Greg KH <greg@kroah.com> wrote:
> On Thu, Aug 15, 2013 at 03:45:13PM +0800, Barry Song wrote:
>> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
>> > On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
>> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:

[...]]

>> we will run rtos+linux instead of linux+linux. typically, Auto
>> industry has long history to use rtos. on the other hand, we need to
>> boot the rtos very fast in hundreds of milliseconds to make sure
>> rearview, early audio have been ready.
>
> But Linux is a RTOS, and a really good one at that.  Linux already boots
> that fast, and solves the rearview/early audio issue just fine (I've
> seen it demoed), so please don't think that Linux can't do this.
>
> Again, what is the requirements of this RTOS that prevent you from using
> Linux instead in that "secure" part of the chip?  What do we need to
> change in order to meet this need?
>

In my experience, there are two similar yet different use cases:
- the desire to co-host a RTOS on the CPU next to Linux, to perform
real-time tasks like software defined radio, fast boot times etc.
- the desire to secure devices using TrustZone, without putting a full
fledged kernel on the secure side due to memory constraints (note that
in many designs, the only secure memory is the on-SoC SRAM)

As the requirements are almost orthogonal, we should not pretend they
are the same thing.

>> > Yes, in fact at least during development Linux usually runs in Secure mode.
>> > Ideally I would love to see 2 instances of Linux running - one in
>> > NonSecure mode and another in Secure mode, getting capabilities via 2
>> > corresponding DTBs reflecting the h/w partitioning done by the TZ.
>>
>> not real. i think there are similar users in linux already. at least
>> omap and exynos have some chip specific codes like omap-smc.S,
>> sleep34xx.S, exynos-smc.S and so on.
>>
>> and i have explained why we don't use linux+linux.
>
> I still don't understand why not.  Boot/audio don't seem like good
> reasons, again because other people have used Linux just fine for that
> application, meeting those legal requirements, in IVI systems.  I know
> of a number of companies that will sell you Linux for that very
> application, so you could just buy it from someone else if you don't
> want to build it yourself :)
>
>> >>> 3. as some CPU time is stolen by security mode, so the scheduler need
>> >>> to get this for load balance
>> >>
>> >> Does the kernel know this time is gone?  Or is it not aware of it (like
>> >> MSIs on x86?)
>> >>
>> > The TrustedOS could share time on the same cpu as the UnTrustedOS or
>> > be assigned a dedicated cpu on an MP.
>>
>> no. TrustedOS will not hold a whole CPU and we don't put a whole core
>> to RTOS as it has low CPU loading.
>> Linux need to know how much time has been taken by TrustOS for every
>> core, and do load balance considering stolen time by TrustOS.
>
> How will it be told that it just lost an amount of time?  How is that
> loss of time supposed to affect the scheduler?  What do you expect the
> scheduler to do in response to this loss?
>
> thanks,
>
> greg k-h
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Greg KH]

On Thu, Aug 15, 2013 at 10:24:41AM +0200, Ard Biesheuvel wrote:
> On 15 August 2013 10:05, Greg KH <greg@kroah.com> wrote:
> > On Thu, Aug 15, 2013 at 03:45:13PM +0800, Barry Song wrote:
> >> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
> >> > On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
> >> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
> 
> [...]]
> 
> >> we will run rtos+linux instead of linux+linux. typically, Auto
> >> industry has long history to use rtos. on the other hand, we need to
> >> boot the rtos very fast in hundreds of milliseconds to make sure
> >> rearview, early audio have been ready.
> >
> > But Linux is a RTOS, and a really good one at that.  Linux already boots
> > that fast, and solves the rearview/early audio issue just fine (I've
> > seen it demoed), so please don't think that Linux can't do this.
> >
> > Again, what is the requirements of this RTOS that prevent you from using
> > Linux instead in that "secure" part of the chip?  What do we need to
> > change in order to meet this need?
> >
> 
> In my experience, there are two similar yet different use cases:
> - the desire to co-host a RTOS on the CPU next to Linux, to perform
> real-time tasks like software defined radio, fast boot times etc.
> - the desire to secure devices using TrustZone, without putting a full
> fledged kernel on the secure side due to memory constraints (note that
> in many designs, the only secure memory is the on-SoC SRAM)
> 
> As the requirements are almost orthogonal, we should not pretend they
> are the same thing.

I'm not pretending they are the same thing, but I am wanting to know how
Linux doesn't work for either of those requirements, as I want to see
Linux be the solution for this "trusted" kernel as well.

thanks,

greg k-h

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Ard Biesheuvel]

On 15 August 2013 17:56, Greg KH <greg@kroah.com> wrote:
>
> On Thu, Aug 15, 2013 at 10:24:41AM +0200, Ard Biesheuvel wrote:
> > On 15 August 2013 10:05, Greg KH <greg@kroah.com> wrote:
> > > On Thu, Aug 15, 2013 at 03:45:13PM +0800, Barry Song wrote:
> > >> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
> > >> > On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
> > >> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
> >
> > [...]]
> >
> > >> we will run rtos+linux instead of linux+linux. typically, Auto
> > >> industry has long history to use rtos. on the other hand, we need to
> > >> boot the rtos very fast in hundreds of milliseconds to make sure
> > >> rearview, early audio have been ready.
> > >
> > > But Linux is a RTOS, and a really good one at that.  Linux already boots
> > > that fast, and solves the rearview/early audio issue just fine (I've
> > > seen it demoed), so please don't think that Linux can't do this.
> > >
> > > Again, what is the requirements of this RTOS that prevent you from using
> > > Linux instead in that "secure" part of the chip?  What do we need to
> > > change in order to meet this need?
> > >
> >
> > In my experience, there are two similar yet different use cases:
> > - the desire to co-host a RTOS on the CPU next to Linux, to perform
> > real-time tasks like software defined radio, fast boot times etc.
> > - the desire to secure devices using TrustZone, without putting a full
> > fledged kernel on the secure side due to memory constraints (note that
> > in many designs, the only secure memory is the on-SoC SRAM)
> >
> > As the requirements are almost orthogonal, we should not pretend they
> > are the same thing.
>
> I'm not pretending they are the same thing, but I am wanting to know how
> Linux doesn't work for either of those requirements, as I want to see
> Linux be the solution for this "trusted" kernel as well.
>

For the former case, there is the assumption (or misconception) that
Linux cannot deliver the boot speed or bounded worst case response
time requirements imposed by things like software defined radio. Also,
there is the existing codebase of RTOS hosted CAN stacks etc, that
have been certified by the [automotive] customer and are moved from a
dedicated MCU into the application CPU as a cost saving measure. This
means that even if Linux does fit the bill in principle, many will
still have no choice other than to go with non-Linux.

For the latter case, it depends on the compatibility of Linux with the
restricted secure world environment, most notably the secure memory.
256k of on chip SRAM is sufficient to do plenty of interesting things
in the secure world, but sadly, running Linux is not one of them. (I
know PoP DDR is considered to be secure memory by some vendors as
well, but its application is not as widespread in the automotive
world)


Regards,

--
Ard.

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Greg KH]

On Thu, Aug 15, 2013 at 07:41:46PM +0200, Ard Biesheuvel wrote:
> > I'm not pretending they are the same thing, but I am wanting to know how
> > Linux doesn't work for either of those requirements, as I want to see
> > Linux be the solution for this "trusted" kernel as well.
> >
> 
> For the former case, there is the assumption (or misconception) that
> Linux cannot deliver the boot speed or bounded worst case response
> time requirements imposed by things like software defined radio.

So, what can we do to address this?  Technically I think Linux can
handle this just fine, as others have pointed out it is used in these
situations.

> Also, there is the existing codebase of RTOS hosted CAN stacks etc,
> that have been certified by the [automotive] customer and are moved
> from a dedicated MCU into the application CPU as a cost saving
> measure. This means that even if Linux does fit the bill in principle,
> many will still have no choice other than to go with non-Linux.

That's their decision, which is fine.  Getting the Linux CAN stack
"certified" might be a good goal for a manufacturer who wants to ship
Linux for this type of system, although we all know how much those
things really matter when it comes to technical issues :)

> For the latter case, it depends on the compatibility of Linux with the
> restricted secure world environment, most notably the secure memory.
> 256k of on chip SRAM is sufficient to do plenty of interesting things
> in the secure world, but sadly, running Linux is not one of them. (I
> know PoP DDR is considered to be secure memory by some vendors as
> well, but its application is not as widespread in the automotive
> world)

Ah, yeah, 256K of ram might be tough to slim Linux down to, but system
sizes keep increasing, so those limitations might be resolved soon
without us having to do anything...

thanks,

greg k-h

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Russell King - ARM Linux]

On Thu, Aug 15, 2013 at 11:26:00AM -0700, Greg KH wrote:
> That's their decision, which is fine.  Getting the Linux CAN stack
> "certified" might be a good goal for a manufacturer who wants to ship
> Linux for this type of system, although we all know how much those
> things really matter when it comes to technical issues :)

If response times matter, and you're relying on software to produce
those response times, then you really need to look at threaded IRQs.
The standard Linux interrupt model sucks, especially if you have USB
enabled.

I'm still seeing upwards of 2.6ms servicing times for USB keyboards
and nice, which given that they are just a set of keys and a position
sensor is totally crazy.

The alternative is we need to throw out the idea that IRQs should be
disabled when servicing hard interrupts and have real interrupt
priorities, where we can nest quicker interrupt handling inside the
slow stuff.

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Greg KH]

On Thu, Aug 15, 2013 at 07:33:19PM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 15, 2013 at 11:26:00AM -0700, Greg KH wrote:
> > That's their decision, which is fine.  Getting the Linux CAN stack
> > "certified" might be a good goal for a manufacturer who wants to ship
> > Linux for this type of system, although we all know how much those
> > things really matter when it comes to technical issues :)
> 
> If response times matter, and you're relying on software to produce
> those response times, then you really need to look at threaded IRQs.
> The standard Linux interrupt model sucks, especially if you have USB
> enabled.

Using USB withing a "trusted OS" situation isn't very wise for a number
of reasons :)

There is work happening on making USB host controllers use threaded
interrups, the first round of changes just went into the usb-next branch
in linux-next, and will show up in 3.12.  It reduces the overhead of USB
on ARM systems by a measurable ammount.  There are more patches coming
for this as well to fix up other related issues, and USB host
controllers.

> I'm still seeing upwards of 2.6ms servicing times for USB keyboards
> and nice, which given that they are just a set of keys and a position
> sensor is totally crazy.

USB is not exactly a low-latency protocol.  A lot happens for just those
"key press" packets to make it to the machine.

thanks,

greg k-h

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Jassi Brar]

On Thu, Aug 15, 2013 at 1:15 PM, Barry Song <21cnbao@gmail.com> wrote:
> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
>> On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
>>> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>>>> For the moment, there is strong markting requirement from
>>>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>>>> IVI as an example, Auto requires security enviorment to access CAN bus
>>>> and other car busses. Auto requires security enviorment to show
>>>> rearview/surround view from cameras and play alert audio. on the other
>>>> hand, IVI system is generically working as a video streaming sink and
>>>> HDMI sink instead of a source. To support HDCP and widevine, we need
>>>> to make sure private keys and video buffers are only visible to
>>>> security mode. With CAN stack, video playback backend and more tasks,
>>>> generically it requires a multi-task RTOS running in security mode
>>>> parallel with Linux in non-security mode.
>>>>
>>>> Linux is a generic purpose OS with UI and all kinds of software, but
>>>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>>>> is still active. We are able to find some opensource projects like
>>>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>>>> Linux has no rich support for this kind of architecture:
>>>> 1. hypervisor running in monitor mode
>>>> 2. RTOS running in security mode
>>>> 3. Linux running in non-security mode
>>>
>>> "Linux" is just a kernel, not a whole operating system :)
>>>
>>> Anyway, why can't Linux be the RTOS kernel as well?  What are the
>>> requirements for that kernel that Linux does not currently meet?
>
> we will run rtos+linux instead of linux+linux. typically, Auto
> industry has long history to use rtos. on the other hand, we need to
> boot the rtos very fast in hundreds of milliseconds to make sure
> rearview, early audio have been ready.
>
Why do you think optimized linux can't boot up in "hundereds of millisecs"?

>>>
>> Yes, in fact at least during development Linux usually runs in Secure mode.
>> Ideally I would love to see 2 instances of Linux running - one in
>> NonSecure mode and another in Secure mode, getting capabilities via 2
>> corresponding DTBs reflecting the h/w partitioning done by the TZ.
>
> not real. i think there are similar users in linux already. at least
> omap and exynos have some chip specific codes like omap-smc.S,
> sleep34xx.S, exynos-smc.S and so on.
>
... and there are socs that has TZ but don't implement SMC (yet).

> and i have explained why we don't use linux+linux.
>
>>
>>>
>>>> 3. as some CPU time is stolen by security mode, so the scheduler need
>>>> to get this for load balance
>>>
>>> Does the kernel know this time is gone?  Or is it not aware of it (like
>>> MSIs on x86?)
>>>
>> The TrustedOS could share time on the same cpu as the UnTrustedOS or
>> be assigned a dedicated cpu on an MP.
>
> no. TrustedOS will not hold a whole CPU and we don't put a whole core
> to RTOS as it has low CPU loading.
>
 If by "we" you mean you and your device, I can understand. Otherwise
please have a look at some TZ whitepaper. It is possible to run in AMP
mode where SecureOS has dedicated cpu core(s).

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
> On Thu, Aug 15, 2013 at 1:15 PM, Barry Song <21cnbao@gmail.com> wrote:
>> 2013/8/15 Jassi Brar <jassisinghbrar@gmail.com>:
>>> On Thu, Aug 15, 2013 at 9:58 AM, Greg KH <greg@kroah.com> wrote:
>>>> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>>>>> For the moment, there is strong markting requirement from
>>>>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>>>>> IVI as an example, Auto requires security enviorment to access CAN bus
>>>>> and other car busses. Auto requires security enviorment to show
>>>>> rearview/surround view from cameras and play alert audio. on the other
>>>>> hand, IVI system is generically working as a video streaming sink and
>>>>> HDMI sink instead of a source. To support HDCP and widevine, we need
>>>>> to make sure private keys and video buffers are only visible to
>>>>> security mode. With CAN stack, video playback backend and more tasks,
>>>>> generically it requires a multi-task RTOS running in security mode
>>>>> parallel with Linux in non-security mode.
>>>>>
>>>>> Linux is a generic purpose OS with UI and all kinds of software, but
>>>>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>>>>> is still active. We are able to find some opensource projects like
>>>>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>>>>> Linux has no rich support for this kind of architecture:
>>>>> 1. hypervisor running in monitor mode
>>>>> 2. RTOS running in security mode
>>>>> 3. Linux running in non-security mode
>>>>
>>>> "Linux" is just a kernel, not a whole operating system :)
>>>>
>>>> Anyway, why can't Linux be the RTOS kernel as well?  What are the
>>>> requirements for that kernel that Linux does not currently meet?
>>
>> we will run rtos+linux instead of linux+linux. typically, Auto
>> industry has long history to use rtos. on the other hand, we need to
>> boot the rtos very fast in hundreds of milliseconds to make sure
>> rearview, early audio have been ready.
>>
> Why do you think optimized linux can't boot up in "hundereds of millisecs"?

yes. i think linux can boot up in "hundereds of millisecs" if we do
decrease the drivers, refine our drivers and don't mount a big
filesystem running on slow storage.
but just like linux has a strong eco-system, auto has strong auto
eco-system. even we put linux+linux, our customers will replace the
backend linux by its own rtos.

>
>>>>
>>> Yes, in fact at least during development Linux usually runs in Secure mode.
>>> Ideally I would love to see 2 instances of Linux running - one inrs
>>> NonSecure mode and another in Secure mode, getting capabilities via 2
>>> corresponding DTBs reflecting the h/w partitioning done by the TZ.
>>
>> not real. i think there are similar users in linux already. at least
>> omap and exynos have some chip specific codes like omap-smc.S,
>> sleep34xx.S, exynos-smc.S and so on.
>>
> ... and there are socs that has TZ but don't implement SMC (yet).
>
yes. that is because they don't need.
markting input for automotive industry requires TZ. without it, we
still need other replacement like NoC firewall. TZ turns out to the
best one integrated well in ARM SoC.


>> and i have explained why we don't use linux+linux.
>>
>>>
>>>>
>>>>> 3. as some CPU time is stolen by security mode, so the scheduler need
>>>>> to get this for load balance
>>>>
>>>> Does the kernel know this time is gone?  Or is it not aware of it (like
>>>> MSIs on x86?)
>>>>
>>> The TrustedOS could share time on the same cpu as the UnTrustedOS or
>>> be assigned a dedicated cpu on an MP.
>>
>> no. TrustedOS will not hold a whole CPU and we don't put a whole core
>> to RTOS as it has low CPU loading.
>>
>  If by "we" you mean you and your device, I can understand. Otherwise
> please have a look at some TZ whitepaper. It is possible to run in AMP
> mode where SecureOS has dedicated cpu core(s).

yes. i do agree. i saw xilinx zynq has a mode, "CPU0 with freertos
+CPU1 with linux". but i talked with xilinx guys, even some xilinx
guys think it is not flexible enough.

anyway, this arch is not ok to me and my devices. this is a waster of
cpu resource.

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/15 Greg KH <greg@kroah.com>:
> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>> For the moment, there is strong markting requirement from
>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>> IVI as an example, Auto requires security enviorment to access CAN bus
>> and other car busses. Auto requires security enviorment to show
>> rearview/surround view from cameras and play alert audio. on the other
>> hand, IVI system is generically working as a video streaming sink and
>> HDMI sink instead of a source. To support HDCP and widevine, we need
>> to make sure private keys and video buffers are only visible to
>> security mode. With CAN stack, video playback backend and more tasks,
>> generically it requires a multi-task RTOS running in security mode
>> parallel with Linux in non-security mode.
>>
>> Linux is a generic purpose OS with UI and all kinds of software, but
>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>> is still active. We are able to find some opensource projects like
>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>> Linux has no rich support for this kind of architecture:
>> 1. hypervisor running in monitor mode
>> 2. RTOS running in security mode
>> 3. Linux running in non-security mode
>
> "Linux" is just a kernel, not a whole operating system :)

do agree. but  i am not saying i want linux kernel to do all these
things. i just want kernel is able to integrate into the system.

>
> Anyway, why can't Linux be the RTOS kernel as well?  What are the
> requirements for that kernel that Linux does not currently meet?
>
>> So the point is that we need generic support for this, especially for
>> IVI and other markets which want Trustzone technology a lot and have
>> complex user scenarios.
>> 1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
>> is not permitted to happen on Linux
>
> Isn't that up to the hardware?  Nothing that Linux can do about that.

right. but linux need to assign interrupts to right group in GIC
hardware. now it doesn't care.

>
>> 2. IPC support for communication between RTOS in security mode and
>> Linux in non-security mode, as we need to communicate rich commands
>> and buffers
>
> What about using the virtual protocols we already have today for the
> existing hypervisors?  Don't reinvent something new if you don't have
> to.
>
>> 3. as some CPU time is stolen by security mode, so the scheduler need
>> to get this for load balance
>
> Does the kernel know this time is gone?  Or is it not aware of it (like
> MSIs on x86?)

for the moment, no if we don't have hooks similar with kvm, xen for it.

>
> thanks,
>
> greg k-h

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Stephen Warren]

On 08/15/2013 01:36 AM, Barry Song wrote:
> 2013/8/15 Greg KH <greg@kroah.com>:
>> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
>>> For the moment, there is strong markting requirement from
>>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>>> IVI as an example, Auto requires security enviorment to access CAN bus
>>> and other car busses. Auto requires security enviorment to show
>>> rearview/surround view from cameras and play alert audio. on the other
>>> hand, IVI system is generically working as a video streaming sink and
>>> HDMI sink instead of a source. To support HDCP and widevine, we need
>>> to make sure private keys and video buffers are only visible to
>>> security mode. With CAN stack, video playback backend and more tasks,
>>> generically it requires a multi-task RTOS running in security mode
>>> parallel with Linux in non-security mode.
>>>
>>> Linux is a generic purpose OS with UI and all kinds of software, but
>>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>>> is still active. We are able to find some opensource projects like
>>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>>> Linux has no rich support for this kind of architecture:
>>> 1. hypervisor running in monitor mode
>>> 2. RTOS running in security mode
>>> 3. Linux running in non-security mode
>>
>> "Linux" is just a kernel, not a whole operating system :)
> 
> do agree. but  i am not saying i want linux kernel to do all these
> things. i just want kernel is able to integrate into the system.
> 
>>
>> Anyway, why can't Linux be the RTOS kernel as well?  What are the
>> requirements for that kernel that Linux does not currently meet?
>>
>>> So the point is that we need generic support for this, especially for
>>> IVI and other markets which want Trustzone technology a lot and have
>>> complex user scenarios.
>>> 1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
>>> is not permitted to happen on Linux
>>
>> Isn't that up to the hardware?  Nothing that Linux can do about that.
> 
> right. but linux need to assign interrupts to right group in GIC
> hardware. now it doesn't care.

I strongly hope that whatever is the secure OS is setting up these
routings, and the HW prevents the non-secure OS from modifying them and
hence never attempts to. Otherwise, the non-secure OS is able to affect
the functioning of the secure OS, which seems like a bad thing.

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Dave Martin]

On Thu, Aug 15, 2013 at 10:03:42AM -0600, Stephen Warren wrote:
> On 08/15/2013 01:36 AM, Barry Song wrote:
> > 2013/8/15 Greg KH <greg@kroah.com>:
> >> On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
> >>> For the moment, there is strong markting requirement from
> >>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
> >>> IVI as an example, Auto requires security enviorment to access CAN bus
> >>> and other car busses. Auto requires security enviorment to show
> >>> rearview/surround view from cameras and play alert audio. on the other
> >>> hand, IVI system is generically working as a video streaming sink and
> >>> HDMI sink instead of a source. To support HDCP and widevine, we need
> >>> to make sure private keys and video buffers are only visible to
> >>> security mode. With CAN stack, video playback backend and more tasks,
> >>> generically it requires a multi-task RTOS running in security mode
> >>> parallel with Linux in non-security mode.
> >>>
> >>> Linux is a generic purpose OS with UI and all kinds of software, but
> >>> we need to make sure even the Linux is ROOTed, RTOS in security mode
> >>> is still active. We are able to find some opensource projects like
> >>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
> >>> Linux has no rich support for this kind of architecture:
> >>> 1. hypervisor running in monitor mode
> >>> 2. RTOS running in security mode
> >>> 3. Linux running in non-security mode
> >>
> >> "Linux" is just a kernel, not a whole operating system :)
> > 
> > do agree. but  i am not saying i want linux kernel to do all these
> > things. i just want kernel is able to integrate into the system.
> > 
> >>
> >> Anyway, why can't Linux be the RTOS kernel as well?  What are the
> >> requirements for that kernel that Linux does not currently meet?
> >>
> >>> So the point is that we need generic support for this, especially for
> >>> IVI and other markets which want Trustzone technology a lot and have
> >>> complex user scenarios.
> >>> 1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
> >>> is not permitted to happen on Linux
> >>
> >> Isn't that up to the hardware?  Nothing that Linux can do about that.
> > 
> > right. but linux need to assign interrupts to right group in GIC
> > hardware. now it doesn't care.
> 
> I strongly hope that whatever is the secure OS is setting up these
> routings, and the HW prevents the non-secure OS from modifying them and
> hence never attempts to. Otherwise, the non-secure OS is able to affect
> the functioning of the secure OS, which seems like a bad thing.

Typically, the master controls are hard-wired for Secure-only access in
hardware: so assigning GIC interrupts to groups is something the secure
OS/firmware has to take care of.

Of course, if Linux is acting as secure OS, it might have to understand
what controls exist and to do some of that configuration itself.

Cheers
---Dave

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

>> >>
>> >> Isn't that up to the hardware?  Nothing that Linux can do about that.
>> >
>> > right. but linux need to assign interrupts to right group in GIC
>> > hardware. now it doesn't care.
>>
>> I strongly hope that whatever is the secure OS is setting up these
>> routings, and the HW prevents the non-secure OS from modifying them and
>> hence never attempts to. Otherwise, the non-secure OS is able to affect
>> the functioning of the secure OS, which seems like a bad thing.
>
> Typically, the master controls are hard-wired for Secure-only access in
> hardware: so assigning GIC interrupts to groups is something the secure
> OS/firmware has to take care of.
>
> Of course, if Linux is acting as secure OS, it might have to understand
> what controls exist and to do some of that configuration itself.

that is just what i want. linux need to realize whether it is running
in security or non-security.
for example, if one irq is assigned to security, even though users
want to get it in non-security, linux should make it fail.
linux need security/non-security realization in GIC.

>
> Cheers
> ---Dave

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Dave Martin]

On Fri, Aug 16, 2013 at 10:39:20AM +0800, Barry Song wrote:
> >> >>
> >> >> Isn't that up to the hardware?  Nothing that Linux can do about that.
> >> >
> >> > right. but linux need to assign interrupts to right group in GIC
> >> > hardware. now it doesn't care.
> >>
> >> I strongly hope that whatever is the secure OS is setting up these
> >> routings, and the HW prevents the non-secure OS from modifying them and
> >> hence never attempts to. Otherwise, the non-secure OS is able to affect
> >> the functioning of the secure OS, which seems like a bad thing.
> >
> > Typically, the master controls are hard-wired for Secure-only access in
> > hardware: so assigning GIC interrupts to groups is something the secure
> > OS/firmware has to take care of.
> >
> > Of course, if Linux is acting as secure OS, it might have to understand
> > what controls exist and to do some of that configuration itself.
> 
> that is just what i want. linux need to realize whether it is running
> in security or non-security.
> for example, if one irq is assigned to security, even though users
> want to get it in non-security, linux should make it fail.
> linux need security/non-security realization in GIC.

For just telling Linux where it is and what peripherals are available,
DT feels like the right answer: if Linux is booted Secure, it would have
a different DT from the one it would be given in the Normal World.

The DT provided to Linux in the Normal World might depend on configuration
choices made in the Secure World -- so it might be generated from the
Secure World DT and passed to the Normal World boot stack.  But initially
it's simpler to keep all that stuff static.

Cheers
---Dave

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Jassi Brar]

On Fri, Aug 16, 2013 at 8:09 AM, Barry Song <21cnbao@gmail.com> wrote:
>>> >>
>>> >> Isn't that up to the hardware?  Nothing that Linux can do about that.
>>> >
>>> > right. but linux need to assign interrupts to right group in GIC
>>> > hardware. now it doesn't care.
>>>
>>> I strongly hope that whatever is the secure OS is setting up these
>>> routings, and the HW prevents the non-secure OS from modifying them and
>>> hence never attempts to. Otherwise, the non-secure OS is able to affect
>>> the functioning of the secure OS, which seems like a bad thing.
>>
>> Typically, the master controls are hard-wired for Secure-only access in
>> hardware: so assigning GIC interrupts to groups is something the secure
>> OS/firmware has to take care of.
>>
>> Of course, if Linux is acting as secure OS, it might have to understand
>> what controls exist and to do some of that configuration itself.
>
> that is just what i want. linux need to realize whether it is running
> in security or non-security.
>
TZ should be seen as two platforms tied together. "DTB" for each mode
should reflect what's available in that mode (dtb for NS kernel
shouldn't/can't specify any Secure asset and while that of Secure
kernel should specify anything that is not accessible from NS mode).
So ideally there should just be the control passing mechanism (like
SMC command) to be told to the kernel running in NS mode.

> for example, if one irq is assigned to security, even though users
> want to get it in non-security, linux should make it fail.
> linux need security/non-security realization in GIC.
>
If there is an 'alias' for the secure asset in NS mode, it is better
to leave it for NS kernel to manage it.
If some asset is visible in Secure mode only, the NS kernel shouldn't
be able to simply do an SMC call to have it manipulated. Otherwise we
leave room for some rooted NS kernel to hack the TrustedOS.

Point of the rant being, perhaps we don't need new kernel
policies/designs to enforce TZ security. We just need properly
partitioned h/w and s/w flow control routed from NS via SMC directly
to SecureApps(not the Secure Kernel).

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/16 Jassi Brar <jassisinghbrar@gmail.com>:
> On Fri, Aug 16, 2013 at 8:09 AM, Barry Song <21cnbao@gmail.com> wrote:
>>>> >>
>>>> >> Isn't that up to the hardware?  Nothing that Linux can do about that.
>>>> >
>>>> > right. but linux need to assign interrupts to right group in GIC
>>>> > hardware. now it doesn't care.
>>>>
>>>> I strongly hope that whatever is the secure OS is setting up these
>>>> routings, and the HW prevents the non-secure OS from modifying them and
>>>> hence never attempts to. Otherwise, the non-secure OS is able to affect
>>>> the functioning of the secure OS, which seems like a bad thing.
>>>
>>> Typically, the master controls are hard-wired for Secure-only access in
>>> hardware: so assigning GIC interrupts to groups is something the secure
>>> OS/firmware has to take care of.
>>>
>>> Of course, if Linux is acting as secure OS, it might have to understand
>>> what controls exist and to do some of that configuration itself.
>>
>> that is just what i want. linux need to realize whether it is running
>> in security or non-security.
>>
> TZ should be seen as two platforms tied together. "DTB" for each mode
> should reflect what's available in that mode (dtb for NS kernel
> shouldn't/can't specify any Secure asset and while that of Secure
> kernel should specify anything that is not accessible from NS mode).
> So ideally there should just be the control passing mechanism (like
> SMC command) to be told to the kernel running in NS mode.

we have implemented a prototype which run linux+linux together based
on TZ on mach-prima2.
in the prototype, we did give two different dtb to security-mode linux
and non-security-mode linux.

>
>> for example, if one irq is assigned to security, even though users
>> want to get it in non-security, linux should make it fail.
>> linux need security/non-security realization in GIC.
>>
> If there is an 'alias' for the secure asset in NS mode, it is better
> to leave it for NS kernel to manage it.
> If some asset is visible in Secure mode only, the NS kernel shouldn't
> be able to simply do an SMC call to have it manipulated. Otherwise we
> leave room for some rooted NS kernel to hack the TrustedOS.
>
> Point of the rant being, perhaps we don't need new kernel
> policies/designs to enforce TZ security. We just need properly
> partitioned h/w and s/w flow control routed from NS via SMC directly
> to SecureApps(not the Secure Kernel).

we don't need to implement a new kernel. we need to refine a few
drivers to have both security and non-security mode(like GIC and L2
cache), and implement high-level IPC for communication in the two
modes and stolen-time realization for scheduler.

all of above don't mean a new kernel, but mean some refine/cleanup,
TZ- based callbacks and middle-level source codes which can be shared
by all ARM SoC.

-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/15 Greg KH <greg@kroah.com>:
[snip]
>
>> 2. IPC support for communication between RTOS in security mode and
>> Linux in non-security mode, as we need to communicate rich commands
>> and buffers
>
> What about using the virtual protocols we already have today for the
> existing hypervisors?  Don't reinvent something new if you don't have
> to.

yes. i agree. that is why i am saying virtio and RPMsg.

-barry

[ARM ATTEND] Trustzone-based security solution for ARM Linux

[Ben Dooks]

On 15/08/13 04:44, Barry Song wrote:
> For the moment, there is strong markting requirement from
> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
> IVI as an example, Auto requires security enviorment to access CAN bus
> and other car busses. Auto requires security enviorment to show
> rearview/surround view from cameras and play alert audio. on the other
> hand, IVI system is generically working as a video streaming sink and
> HDMI sink instead of a source. To support HDCP and widevine, we need
> to make sure private keys and video buffers are only visible to
> security mode. With CAN stack, video playback backend and more tasks,
> generically it requires a multi-task RTOS running in security mode
> parallel with Linux in non-security mode.

Personally, I just don't trust anything that is running on the main cpu
not to get compromised in some form. There has been too little thought
put in to securing these devices.

> Linux is a generic purpose OS with UI and all kinds of software, but
> we need to make sure even the Linux is ROOTed, RTOS in security mode
> is still active. We are able to find some opensource projects like
> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
> Linux has no rich support for this kind of architecture:
> 1. hypervisor running in monitor mode
> 2. RTOS running in security mode
> 3. Linux running in non-security mode
>
> So the point is that we need generic support for this, especially for
> IVI and other markets which want Trustzone technology a lot and have
> complex user scenarios.
> 1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
> is not permitted to happen on Linux
> 2. IPC support for communication between RTOS in security mode and
> Linux in non-security mode, as we need to communicate rich commands
> and buffers
> 3. as some CPU time is stolen by security mode, so the scheduler need
> to get this for load balance

With information being passed to the RTOS from the non-secure OS adds
a method of attacking the secure world.

> For IPC, RPMsg is kind of popular for commucating cross HMP. For
> example, OMAP uses it as the IPC between M3 and A9; XilinX uses it as
> IPC between two A9, one with FreeRTOS, the other one with Linux; ST-E
> uses it to connect ARM with modem MCU. So we are also considering the
> possibility to involve RPMsg as the backend for communication between
> RTOS in security mode and Linux in non-security mode. then we get much
> benefit from virtio, and some drivers will be usable directly.
>
> So for this topic, I want a presentation session with about 5 slides
> to show the high-level architecture and requirement for a real and
> complex Trustzone user case. Hoping we can get some rich support from
> Linux for this architecture.
>
> On the other hand, if people can discuss Android mainlining project
> more, i like much. for the moment, most Android patches have been
> mainlined, but we still need to maintain both branches as there are
> rebased patches from Google. So i want to get input about best
> pratice.
>
> [1]SafeG (Safety Gate):
> http://www.toppers.jp/en/safeg.html
> [2]Green Hills Multivisor:
> http://www.ghs.com/products/rtos/integrity_virtualization.html
> [3]SierraVisor:
> http://www.openvirtualization.org/



-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

[ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/15 Ben Dooks <ben.dooks@codethink.co.uk>:
> On 15/08/13 04:44, Barry Song wrote:
>>
>> For the moment, there is strong markting requirement from
>> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
>> IVI as an example, Auto requires security enviorment to access CAN bus
>> and other car busses. Auto requires security enviorment to show
>> rearview/surround view from cameras and play alert audio. on the other
>> hand, IVI system is generically working as a video streaming sink and
>> HDMI sink instead of a source. To support HDCP and widevine, we need
>> to make sure private keys and video buffers are only visible to
>> security mode. With CAN stack, video playback backend and more tasks,
>> generically it requires a multi-task RTOS running in security mode
>> parallel with Linux in non-security mode.
>
>
> Personally, I just don't trust anything that is running on the main cpu
> not to get compromised in some form. There has been too little thought
> put in to securing these devices.

Trustzone is a hardware mechanism to stop as much as possible.

>
>
>> Linux is a generic purpose OS with UI and all kinds of software, but
>> we need to make sure even the Linux is ROOTed, RTOS in security mode
>> is still active. We are able to find some opensource projects like
>> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
>> Linux has no rich support for this kind of architecture:
>> 1. hypervisor running in monitor mode
>> 2. RTOS running in security mode
>> 3. Linux running in non-security mode
>>
>> So the point is that we need generic support for this, especially for
>> IVI and other markets which want Trustzone technology a lot and have
>> complex user scenarios.
>> 1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
>> is not permitted to happen on Linux
>> 2. IPC support for communication between RTOS in security mode and
>> Linux in non-security mode, as we need to communicate rich commands
>> and buffers
>> 3. as some CPU time is stolen by security mode, so the scheduler need
>> to get this for load balance
>
>
> With information being passed to the RTOS from the non-secure OS adds
> a method of attacking the secure world.

that doesn't matter. the hardware firewall for private keys storage
and memory based on trustzone will stop any people in non-security to
access them as hardware stops that.
you can get information as much as possible, for example, the base
address of video buffer, but you can't access it.


>
>
>> For IPC, RPMsg is kind of popular for commucating cross HMP. For
>> example, OMAP uses it as the IPC between M3 and A9; XilinX uses it as
>> IPC between two A9, one with FreeRTOS, the other one with Linux; ST-E
>> uses it to connect ARM with modem MCU. So we are also considering the
>> possibility to involve RPMsg as the backend for communication between
>> RTOS in security mode and Linux in non-security mode. then we get much
>> benefit from virtio, and some drivers will be usable directly.
>>
>> So for this topic, I want a presentation session with about 5 slides
>> to show the high-level architecture and requirement for a real and
>> complex Trustzone user case. Hoping we can get some rich support from
>> Linux for this architecture.
>>
>> On the other hand, if people can discuss Android mainlining project
>> more, i like much. for the moment, most Android patches have been
>> mainlined, but we still need to maintain both branches as there are
>> rebased patches from Google. So i want to get input about best
>> pratice.
>>
>> [1]SafeG (Safety Gate):
>> http://www.toppers.jp/en/safeg.html
>> [2]Green Hills Multivisor:
>> http://www.ghs.com/products/rtos/integrity_virtualization.html
>> [3]SierraVisor:
>> http://www.openvirtualization.org/
>
>
>
>
> --
> Ben Dooks                               http://www.codethink.co.uk/
> Senior Engineer                         Codethink - Providing Genius

-barry

[ARM ATTEND] Trustzone-based security solution for ARM Linux

[Dave Martin]

On Thu, Aug 15, 2013 at 11:44:30AM +0800, Barry Song wrote:
> For the moment, there is strong markting requirement from
> IVI(In-Vehicle Infotainment) or mobile to use ARM Trustzone. We take
> IVI as an example, Auto requires security enviorment to access CAN bus
> and other car busses. Auto requires security enviorment to show
> rearview/surround view from cameras and play alert audio. on the other
> hand, IVI system is generically working as a video streaming sink and
> HDMI sink instead of a source. To support HDCP and widevine, we need
> to make sure private keys and video buffers are only visible to
> security mode. With CAN stack, video playback backend and more tasks,
> generically it requires a multi-task RTOS running in security mode
> parallel with Linux in non-security mode.
> 
> Linux is a generic purpose OS with UI and all kinds of software, but
> we need to make sure even the Linux is ROOTed, RTOS in security mode
> is still active. We are able to find some opensource projects like
> SafeG[1], Multivisor[2], SierraVisor[3], but it turns out that ARM
> Linux has no rich support for this kind of architecture:
> 1. hypervisor running in monitor mode
> 2. RTOS running in security mode
> 3. Linux running in non-security mode
> 
> So the point is that we need generic support for this, especially for
> IVI and other markets which want Trustzone technology a lot and have
> complex user scenarios.
> 1. Dispatch FIQ to security, dispatch IRQ to Linux, for this case, FIQ
> is not permitted to happen on Linux
> 2. IPC support for communication between RTOS in security mode and
> Linux in non-security mode, as we need to communicate rich commands
> and buffers
> 3. as some CPU time is stolen by security mode, so the scheduler need
> to get this for load balance
> 
> For IPC, RPMsg is kind of popular for commucating cross HMP. For
> example, OMAP uses it as the IPC between M3 and A9; XilinX uses it as
> IPC between two A9, one with FreeRTOS, the other one with Linux; ST-E
> uses it to connect ARM with modem MCU. So we are also considering the
> possibility to involve RPMsg as the backend for communication between
> RTOS in security mode and Linux in non-security mode. then we get much
> benefit from virtio, and some drivers will be usable directly.

Needless to say, there are multiple proprietary blobs out there which
do much what you describe, though these are closed and locked down.


As others have said, the Secure World is just another execution space,
so there's no technical reason not to have some FOSS running in there,
be it an RTOS, uClinux or Linux.

However, the ways in which resources can be shared between the Secure
World and Normal World are inflexible compared with the kind of sharing
you get from a normal hypervisor.  The Secure World doesn't have any
true virtualisation capabilities.


The real challenge would be getting sufficiently open hardware, with
sufficient documentation, and/or finding a friendly hardware vendor who
can be persuaded of the merits of supporting or investing in an open
solution.  The rest is "just software".

Cheers
---Dave

> So for this topic, I want a presentation session with about 5 slides
> to show the high-level architecture and requirement for a real and
> complex Trustzone user case. Hoping we can get some rich support from
> Linux for this architecture.
> 
> On the other hand, if people can discuss Android mainlining project
> more, i like much. for the moment, most Android patches have been
> mainlined, but we still need to maintain both branches as there are
> rebased patches from Google. So i want to get input about best
> pratice.
> 
> [1]SafeG (Safety Gate):
> http://www.toppers.jp/en/safeg.html
> [2]Green Hills Multivisor:
> http://www.ghs.com/products/rtos/integrity_virtualization.html
> [3]SierraVisor:
> http://www.openvirtualization.org/
> 
> -barry
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

[snip]
>
> Needless to say, there are multiple proprietary blobs out there which
> do much what you describe, though these are closed and locked down.
>
yes. i have listed [1][2][3] as examples.
[1]SafeG (Safety Gate): http://www.toppers.jp/en/safeg.html
[2]Green Hills Multivisor:
http://www.ghs.com/products/rtos/integrity_virtualization.html
[3]SierraVisor: http://www.openvirtualization.org/

>
> As others have said, the Secure World is just another execution space,
> so there's no technical reason not to have some FOSS running in there,
> be it an RTOS, uClinux or Linux.
>

non-security world need to know how much time is taken away from
security world whatewer OS security world uses.

> However, the ways in which resources can be shared between the Secure
> World and Normal World are inflexible compared with the kind of sharing
> you get from a normal hypervisor.  The Secure World doesn't have any
> true virtualisation capabilities.
>

except the stolen time issue, actually a high-level msg protocol like
virtio and RPMsg will help rich information sharing between
non-security and security world than a simple SMC call.
these communication channels are not specific to CSR chips, can be
re-used by all SoCs if they have similar scenarios. so i am thinking
whether we can have some generic framework for that in ARM Linux.

>
> The real challenge would be getting sufficiently open hardware, with
> sufficient documentation, and/or finding a friendly hardware vendor who
> can be persuaded of the merits of supporting or investing in an open
> solution.  The rest is "just software".

yes. let's handle the "just software" issues here, leave the hardware
issues to IC guys.

>
> Cheers
> ---Dave
>
-barry

[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux

[Barry Song]

2013/8/16 Dave Martin <Dave.Martin@arm.com>:
> On Fri, Aug 16, 2013 at 10:49:30AM +0800, Barry Song wrote:
>> [snip]
>> >
>> > Needless to say, there are multiple proprietary blobs out there which
>> > do much what you describe, though these are closed and locked down.
>> >
>> yes. i have listed [1][2][3] as examples.
>> [1]SafeG (Safety Gate): http://www.toppers.jp/en/safeg.html
>> [2]Green Hills Multivisor:
>> http://www.ghs.com/products/rtos/integrity_virtualization.html
>> [3]SierraVisor: http://www.openvirtualization.org/
>>
>> >
>> > As others have said, the Secure World is just another execution space,
>> > so there's no technical reason not to have some FOSS running in there,
>> > be it an RTOS, uClinux or Linux.
>> >
>>
>> non-security world need to know how much time is taken away from
>> security world whatewer OS security world uses.
>>
>> > However, the ways in which resources can be shared between the Secure
>> > World and Normal World are inflexible compared with the kind of sharing
>> > you get from a normal hypervisor.  The Secure World doesn't have any
>> > true virtualisation capabilities.
>> >
>>
>> except the stolen time issue, actually a high-level msg protocol like
>> virtio and RPMsg will help rich information sharing between
>> non-security and security world than a simple SMC call.
>> these communication channels are not specific to CSR chips, can be
>> re-used by all SoCs if they have similar scenarios. so i am thinking
>> whether we can have some generic framework for that in ARM Linux.
>
> Despite what I said about TZ not supporting true virtualisation, there
> are a lot similar issues.  This things you mention (IPC, timekeeping,
> blackout avoidance etc.) don't sound like unique problems.

yes. there are similar issues with a real virtualisation. here the
unique problems are callbacks and frameworks which help hook TZ into
virtualization-similar architecture without enabling the whole
virtualization in kernel. we can have a generic TZ implementation
instead of per-soc instance.

>
> I suppose this may indeed be viewed as a special, limited case of
> virtualisation, where physical memory is statically partitioned and not
> virtualised, and there is only one guest*
>
>
> I guess it would be worth getting ideas from the KVM guys about what
> concepts can be applied here, even if the code is not directly re-usable.
>

agree.

> Cheers
> ---Dave
>

-barry