在 2020/12/2 上午3:17, Achin Gupta 写道:
Hi Heyi,
CIL...
On Mon, Nov 30, 2020 at 07:54:52PM +0800, Heyi Guo wrote:
在 2020/11/26 下午7:35, Achin Gupta 写道:
Hi Heyi,
On Wed, Nov 25, 2020 at 05:40:04PM +0800, Heyi Guo wrote:
Hi Achin,
Thanks for your reply. I still have some questions as below:
Ditto and please find some comments inline.
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 think you would need to write a platform specific handler in EL3.
This handler would clear the bits in ERR<n>STATUS and read the syndrome information from the system registers into memory.
It would then pass this syndrome information to the MM partition which would convert it into a CPER.
[HG] Agree; we are also thinking of similar method :)
We would need to work out how the information gets passed in memory.
Just thinking aloud!
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?
Yeah. That is the other option to above. I don't particularly like it since it would add a very bespoke interface into EL3.
[HG] Agree, and this will involve numbers of SVCs in a single RAS handling...
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.
Yes. The work being done on OP-TEE could be used to get an idea of how difficult it would be.
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?
The problem is that we could have two equally privileged entities (TF-A in EL3 and TEE in S-EL1) that both want to run their apps (SPs and TAs) without getting in each other's way. The semantics are similar to those of running two OSes simultaneously.
It is not desirable to expose TF-A to this scheduling complexity i.e. a situation where it must decide whether to run the TEE, SP or return control to the Normal world.
This complexity could be reduced if we assume that:
- There is a single SP that co-exists with a TEE
- There is a strict separation of resources between the SP and the TEE e.g. interrupts, memory and devices.
- It is not possible to switch execution from the SP to the TEE without first exiting to the Normal world.
I can imagine challenges with exception routing as well. It could be solved for interrupts e.g. they could be configured such that:
- TEE uses G1S interrupts
- TF-A/SP uses G0 interrupts
- Interrupts are disabled when the SP runs
- TEE relinquishes control to Normal world in response to a FIQ
I am not so sure about external aborts if in-band reporting of RAS errors is used. Say, an EA occurs when the TEE is running and must be handled by the SP. How would the switch take place and the error syndrome information passed correctly? Needs further thought!
In any case, we are now deep in the territory of assumptions about how the TEE and SP should interact and how they are implemented to keep things simple for TF-A.
On top of it, we want to support multiple S-EL0 SPs in the near future. Running them alongside a TEE is likely to invalidate some of the assumptions above.
[HG] Agree...
Hence, the preferred approach is to delegate this complexity to the TEE which already does this for its own applications.
[HG] Is there any timeline for TEE to support MM? I'm also curious about the new workflow of RAS processing when MM is running on TEE.
There is work being done with OP-TEE. Support for running a MM partition in OP-TEE was upstreamed a few months back. Corresponding changes in the MM partition are under review in edk2.
Thanks. I'll take some time to investigate the completed work.
The use case targeted by the MM partition is Secure storage as the backend for EFI secure variable storage.
There is no active development in the open on the RAS use case that I am aware of. Something worth bringing up on the OP-TEE ML?
That will be great :) Would you bring up the topic? I may need to subscribe to the ML at the first step...
Appreciate it.
Heyi
cheers, Achin
Thanks,
Heyi
If we can make assumptions as stated above, I see this as a point solution. It might be acceptable if all TF-A has to do is allow the SPM_MM and SPD to be compiled together, let them intialise themselves and things work as before during runtime. Maybe the maintainers can chime in. I might have missed something.
cheers, Achin
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 >