[Ksummit-2013-discuss] [ARM ATTEND] Trustzone-based security solution for ARM Linux
21cnbao at gmail.com
Mon Aug 19 19:13:12 EDT 2013
2013/8/16 Dave Martin <Dave.Martin at arm.com>:
> On Fri, Aug 16, 2013 at 10:49:30AM +0800, Barry Song wrote:
>> > 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  as examples.
>> SafeG (Safety Gate): http://www.toppers.jp/en/safeg.html
>> Green Hills Multivisor:
>> 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.
More information about the linux-arm-kernel