Hi Achin,
Thanks for your reply. I still have some questions as below:
On 2020/11/24 下午3:02, Achin Gupta wrote:
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?
[HG] We are trying to use firmware first RAS model, and it seems Linux will not read these system registers to get RAS information right now, only relying on ACPI HEST and CPER error records. So for some kinds of error, MM needs to read these system registers to build generic CPER records.
I guess a para-virt interface would be required to let the MM partition access system registers?
[HG] Do you mean using SVC calls to read/write these 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.
[HG] I was afraid that other TEEs also need to do lots of similar work to support MM partition, and it may save the work if we can find some way independent of TEE. But it is OK if the work is minor and easy to be ported to other TEEs.
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.
- 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.
[HG] Agree
- 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.
[HG] I supposed it wouldn't add much complexity to TF-A with the existing good framework. Opteed and spm_mm seems to be 2 individual modules which have their own OEN ranges; I think only below tasks need to be done:
- Load and initialize both MM and TEE;
- Make sure CPU contexts are separated for MM and TEE;
- Update fip tool accordingly.
Is there anything more to do?
Thanks,
Heyi
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 >