Hi Heyi,
Please find some comments inline marked [AG].
On 23/11/2020, 11:27, "Heyi Guo" guoheyi@linux.alibaba.com wrote:
Hi Achin,
Thanks a lot for your reply.
OP-TEE running MM as a trusted application seems to be workable solution, however there may be some other troubles:
1. MM is responsible for RAS and secure uefi variable right now; running on EL0 makes it difficult to access RAS related system registers which are only accessible by EL1 or more privileged ELs. The modules in MM are more like device drivers rather than unprivileged applications.
[AG] Fair point. An MM partition would not be able to access RAS system registers irrespective of whether it runs under EL3 or S-EL1. Is kernel first handling not the preferred approach for error records in system registers?
I guess a para-virt interface would be required to let the MM partition access system registers?
2. The solution binds MM to OP-TEE only; it is not workable for other TEE implementations.
[AG] I am not sure about the binding bit. The intent is to ensure that an MM partition that works today with TF-A at EL3 also works with OP-TEE at S-EL1. So as long as the TEE implements the right interfaces, an existing MM partition should "just" work.
How about making MM as an individual secure partition, which can be dispatched parallelly with TEE and extended to run on S-EL1 in the future?
[AG] There are two points here.
1. Running MM in S-EL1 on a pre-v8.4 system loses the security benefit of sandboxing it in S-EL0. It would end up adding EDK2 code to the TCB which is not desirable. This model is more suitable for v8.4+ systems with S-EL2 is enabled. An MM SP could run in S-EL1.
2. Dispatching an MM SP parallelly with the TEE on a pre-v8.4 system increases the complexity in TF-A in EL3. Again, this is a model that would work on a v8.4+ system with S-EL2 enabled.
Please let me know if I miss something :)
[AG] Same here __
Cheers, Achin
Thanks,
Heyi
On 2020/11/23 下午3:27, Achin Gupta wrote: > Hi Heyi, > > Happy to discuss the detail but the short answer is no. > > Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. > > From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. > > Cheers, > Achin > > On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces@lists.trustedfirmware.org on behalf of tf-a@lists.trustedfirmware.org> wrote: > > Hi All, > > On some platforms there may be requirements to run both TEE and SPM_MM > instances, such as providing TEE services on server platforms. > > Do TF-A support this scenario? If it doesn't, do it make sense to add > such support? > > Thanks, > > Heyi > > -- > TF-A mailing list > TF-A@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >