Hi all,
I have a similar but different question here :)
Why not the tf-a support both smpd and tspd.
Since the vendor's teeos that has not support ff-a interface currently.
With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services?
It seems to need some tlb maintenance, but it seems work.
On 2020/11/23 3:27 下午, Achin Gupta via TF-A 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
Hi Feng,
On Sat, Dec 19, 2020 at 12:51:03AM +0800, Chen Feng wrote:
Hi all,
I have a similar but different question here :)
Why not the tf-a support both smpd and tspd.
I am assuming you meant SPD and not TSPD.
Since the vendor's teeos that has not support ff-a interface currently.
If the teeos does not support FF-A then there is no need to include support for the SPMD. Things work as they do with the SPD.
So, I am not sure why you are looking for coexistence of both SPD and SPMD. Could you please clarify?
With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services?
Yes. SW does not have to use S-EL2 even if the HW supports it.
BTW, the FF-A specification is not tied to the availability of S-EL2.
It can be used by a teeos both with and without S-EL2. In either case,
- The Normal world uses a standard SMC interface to talk to the teeos.
- The Hypervisor in EL2 does not have to include a teeos specific driver. It uses a FF-A driver instead, which works with any teeos that uses FF-A.
- TF-A does not have to include teeos specific dispatcher (SPD) in EL3. It uses the SPMD instead which works with any teeos that uses FF-A.
It seems to need some tlb maintenance, but it seems work.
I do not understand the need for tlb maintenance if you want to use a teeos without FF-A. But, I might be not understanding you. Could you please clarify?
cheers, Achin
On 2020/11/23 3:27 下午, Achin Gupta via TF-A 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-- cheers, feng
Hi,
On 2020/12/19 6:20 上午, Achin Gupta wrote:
Hi Feng,
On Sat, Dec 19, 2020 at 12:51:03AM +0800, Chen Feng wrote:
Hi all,
I have a similar but different question here :)
Why not the tf-a support both smpd and tspd.
I am assuming you meant SPD and not TSPD.
Ah, yes.
Since the vendor's teeos that has not support ff-a interface currently.
If the teeos does not support FF-A then there is no need to include support for the SPMD. Things work as they do with the SPD.
So, I am not sure why you are looking for coexistence of both SPD and SPMD. Could you please clarify?
Currently, the secure services are all inside the el3-firmare and teeos without ff-a. Right?
If we just want to move some service from the el3-firmware to secure partition to decrease the TCB of el3 firmware. But without changing the services inside the teeos.
In this case, we want to the el3 have both SPD and TSPD. When the SPD working, it enables the sel2 with new ff-a software stack. But if requesting a old teeos service, it works with TSPD with sel2 disable.
More simply, teeos works still at el1&0 with sel2 disable. And some services moved from el3-firmware can work inside a secure partition with sel2 enabled.
I want to discuss here. Is it possible to dynamic disable and enable the sel2 feature for old and new service?
With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services?
Yes. SW does not have to use S-EL2 even if the HW supports it.
BTW, the FF-A specification is not tied to the availability of S-EL2.
It can be used by a teeos both with and without S-EL2. In either case,
The Normal world uses a standard SMC interface to talk to the teeos.
The Hypervisor in EL2 does not have to include a teeos specific driver. It uses a FF-A driver instead, which works with any teeos that uses FF-A.
TF-A does not have to include teeos specific dispatcher (SPD) in EL3. It uses the SPMD instead which works with any teeos that uses FF-A.
It seems to need some tlb maintenance, but it seems work.
I do not understand the need for tlb maintenance if you want to use a teeos without FF-A. But, I might be not understanding you. Could you please clarify?
cheers, Achin
On 2020/11/23 3:27 下午, Achin Gupta via TF-A 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-- cheers, feng
Hi Feng,
On Sat, Dec 19, 2020 at 08:02:18AM +0800, Chen Feng wrote:
Hi,
On 2020/12/19 6:20 上午, Achin Gupta wrote:
Hi Feng,
On Sat, Dec 19, 2020 at 12:51:03AM +0800, Chen Feng wrote:
Hi all,
I have a similar but different question here :)
Why not the tf-a support both smpd and tspd.
I am assuming you meant SPD and not TSPD.
Ah, yes.
Since the vendor's teeos that has not support ff-a interface currently.
If the teeos does not support FF-A then there is no need to include support for the SPMD. Things work as they do with the SPD.
So, I am not sure why you are looking for coexistence of both SPD and SPMD. Could you please clarify?
Currently, the secure services are all inside the el3-firmare and teeos without ff-a. Right?
If we just want to move some service from the el3-firmware to secure partition to decrease the TCB of el3 firmware. But without changing the services inside the teeos.
In this case, we want to the el3 have both SPD and TSPD. When the SPD working, it enables the sel2 with new ff-a software stack. But if requesting a old teeos service, it works with TSPD with sel2 disable.
More simply, teeos works still at el1&0 with sel2 disable. And some services moved from el3-firmware can work inside a secure partition with sel2 enabled.
I want to discuss here. Is it possible to dynamic disable and enable the sel2 feature for old and new service?
The hw architecture does not disallow such a configuration. From a sw architecture perspective, a dynamic disable and enable would only increase the complexity and most probably the size of the TCB. This would completely defeat the point of introducing S-EL2 in the hw.
Earlier in this thread, I had listed some reasons why running S-EL0 SPs managed by EL3 firmware along side a teeos is not a good idea. The same reasons plus the following apply to this approach.
1. It would add the SPMC in S-EL2 to the TCB on top of the teeos and EL3 firmware. I don't think there will be a net reduction in the size of the TCB even if secure services are moved out of EL3 in secure partitions/sandboxes.
2. It would require additional logic in at least EL3 firmware (SPMD) to correctly load images, manage the contexts of the SPMC and the teeos, ensure exceptions are correctly routed etc. This logic is unlikely to work for all teeos implementations. I don't see any benefit of introducing this complexity in the TCB.
FF-A interfaces can be used with a teeos without S-EL2. This has no impact on any services implemented inside the teeos. It would be better to migrate the teeos to FF-A without S-EL2 as the first step.
The second step would be to run the teeos under the SPMC in S-EL2. Other secure services migrated from EL3 can be managed by the SPMC at the same time in separate sandboxes.
cheers, Achin
With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services?
Yes. SW does not have to use S-EL2 even if the HW supports it.
BTW, the FF-A specification is not tied to the availability of S-EL2.
It can be used by a teeos both with and without S-EL2. In either case,
The Normal world uses a standard SMC interface to talk to the teeos.
The Hypervisor in EL2 does not have to include a teeos specific driver. It uses a FF-A driver instead, which works with any teeos that uses FF-A.
TF-A does not have to include teeos specific dispatcher (SPD) in EL3. It uses the SPMD instead which works with any teeos that uses FF-A.
It seems to need some tlb maintenance, but it seems work.
I do not understand the need for tlb maintenance if you want to use a teeos without FF-A. But, I might be not understanding you. Could you please clarify?
cheers, Achin
On 2020/11/23 3:27 下午, Achin Gupta via TF-A 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-- cheers, feng
-- cheers, feng
tf-a@lists.trustedfirmware.org
-
Achin Gupta -
Chen Feng