From: ben.dooks@codethink.co.uk (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [ARM ATTEND] Trustzone-based security solution for ARM Linux
Date: Thu, 15 Aug 2013 08:57:53 +0100 [thread overview]
Message-ID: <520C8A01.2070808@codethink.co.uk> (raw)
In-Reply-To: <CAGsJ_4xnivwNW_Pvhv7Jg62a94d5FChwqEwnNX3Miqd5fAxNHA@mail.gmail.com>
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
next prev parent reply other threads:[~2013-08-15 7:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-15 3:44 [ARM ATTEND] Trustzone-based security solution for ARM Linux Barry Song
2013-08-15 4:28 ` [Ksummit-2013-discuss] " Greg KH
2013-08-15 5:14 ` Jassi Brar
2013-08-15 7:45 ` Barry Song
2013-08-15 8:05 ` Greg KH
2013-08-15 8:22 ` Barry Song
2013-08-15 16:01 ` Greg KH
2013-08-16 2:08 ` Barry Song
2013-08-15 8:24 ` Ard Biesheuvel
2013-08-15 15:56 ` Greg KH
2013-08-15 17:41 ` Ard Biesheuvel
2013-08-15 18:26 ` Greg KH
2013-08-15 18:33 ` Russell King - ARM Linux
2013-08-15 18:44 ` Greg KH
2013-08-15 8:17 ` Jassi Brar
2013-08-15 8:36 ` Barry Song
2013-08-15 7:36 ` Barry Song
2013-08-15 16:03 ` Stephen Warren
2013-08-15 17:43 ` Dave Martin
2013-08-16 2:39 ` Barry Song
2013-08-16 11:14 ` Dave Martin
2013-08-16 11:17 ` Jassi Brar
2013-08-19 23:31 ` Barry Song
2013-08-15 9:05 ` Barry Song
2013-08-15 7:57 ` Ben Dooks [this message]
2013-08-15 8:06 ` Barry Song
2013-08-15 14:08 ` Dave Martin
2013-08-16 2:49 ` Barry Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520C8A01.2070808@codethink.co.uk \
--to=ben.dooks@codethink.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.