[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 at 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).