Hi Peng,

There is my point of view: OP-TEE is an environment for trusted applications and other security features, but power management is not strictly a security feature. OP-TEE provides Secure Monitor on ARMv7 architectures, but only because there was no other secure monitor available. On ARMv8 it relies to ARM Trusted FW, which is preffered, because secure monitor provides other services, like PSCI. As far as I know, there are set of patches for u-boot that adds security monitor support and PSCI to it. This one, I believe: http://lists.denx.de/pipermail/u-boot/2013-December/168655.html Also, U-Boot is responsible for platform initialization. It will be better to have most of platform-specific code in one place. So personally I stick to option 2. So you can write to u-boot mailing list and ask them if they plan to further develop PSCI support.

But lets also hear opinion of Linaro guys.

On 11 November 2016 at 10:21, Peng Fan peng.fan@nxp.com wrote:

Hi,

I am trying to implement TEE and support Linux power features.

There are several options to include power features and TEE

1. ATFW for ARM32.

2. Develop runtime service code in U-Boot like ATFW.

3. Integrate PSCI ARM32 in OP-TEE.

Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32 support, I think(not sure), is not for legacy ARM32 cores.

Option2, requires some efforts. And needs some wrap code between uboot monitor code and TEE and Linux.

Actually I prefer option3, and secondary cores can be booted up with psci in OP-TEE. Before I

put more efforts, I would like to ask whether this is acceptable from OP-TEE community.

Thanks,

Peng.

---

Tee-dev mailing list Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev

Add Jens and Etienne.

I am trying to find a common solution to support ARMV7-A. If choosing U-Boot, need to develop runtime service code as ATFW. Do you have any suggestions about what needs to be taken into consideration?

Regards, Peng.

-----Original Message----- From: Volodymyr Babchuk [mailto:vlad.babchuk@gmail.com] Sent: Saturday, November 12, 2016 3:06 AM To: Peng Fan peng.fan@nxp.com Cc: tee-dev@lists.linaro.org Subject: Re: [Tee-dev] Introduce PSCI for OP-TEE ARM32

Hi Peng,

There is my point of view: OP-TEE is an environment for trusted applications and other security features, but power management is not strictly a security feature. OP-TEE provides Secure Monitor on ARMv7 architectures, but only because there was no other secure monitor available. On ARMv8 it relies to ARM Trusted FW, which is preffered, because secure monitor provides other services, like PSCI. As far as I know, there are set of patches for u-boot that adds security monitor support and PSCI to it. This one, I believe: http://lists.denx.de/pipermail/u-boot/2013-December/168655.html Also, U-Boot is responsible for platform initialization. It will be better to have most of platform-specific code in one place. So personally I stick to option 2. So you can write to u-boot mailing list and ask them if they plan to further develop PSCI support.

But lets also hear opinion of Linaro guys.

On 11 November 2016 at 10:21, Peng Fan peng.fan@nxp.com wrote:

...

Hi,

I am trying to implement TEE and support Linux power features.

There are several options to include power features and TEE

1. ATFW for ARM32.

2. Develop runtime service code in U-Boot like ATFW.

3. Integrate PSCI ARM32 in OP-TEE.

Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32 support, I think(not sure), is not for legacy ARM32 cores.

Option2, requires some efforts. And needs some wrap code between uboot monitor code and TEE and Linux.

Actually I prefer option3, and secondary cores can be booted up with psci in OP-TEE. Before I

put more efforts, I would like to ask whether this is acceptable from OP-TEE community.

Thanks,

Peng.

---

Tee-dev mailing list Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev

-- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk@gmail.com

Hi Joakim,

-----Original Message----- From: Joakim Bech [mailto:joakim.bech@linaro.org] Sent: Monday, November 14, 2016 3:43 PM To: Jerome Forissier jerome.forissier@linaro.org Cc: Peng Fan peng.fan@nxp.com; tee-dev@lists.linaro.org Subject: Re: [Tee-dev] Introduce PSCI for OP-TEE ARM32

Peng, Jerome,

On Fri, Nov 11, 2016 at 09:29:44PM +0100, Jerome Forissier wrote:

...

Le 11 nov. 2016 10:30 AM, "Peng Fan" peng.fan@nxp.com a écrit :

...

Hi,

I am trying to implement TEE and support Linux power features.

There are several options to include power features and TEE

1. ATFW for ARM32.

2. Develop runtime service code in U-Boot like ATFW.

3. Integrate PSCI ARM32 in OP-TEE.

Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32

support, I think(not sure), is not for legacy ARM32 cores.

Indeed it seems that the main focus is ARMv8-A. FYI, the presentation made by ARM at Linaro Connect is at http://connect.linaro.org/resource/las16/las16-402/.

Yes, we had a chat with ARM at Connect and currently it seems like their plans only cover ARMv8-A (I cannot tell whether that will change later on). Having that said we also discussed whether we (Linaro security team) could bring in the related functionality as a PSCI library into ARMv7-A. Due to the architectural differences between ARMv8-A and ARMv7-A, that would mean that we would need to bring the PSCI related code for ARMv7-A directly into the OP-TEE code base. I.e, we're talking about option three in Peng's proposal above. This is something we've put on our to-do list and would like to start looking into this cycle (which lasts until next Linaro Connect in Feb/March -17).

I don't think we will start the working until the beginning of next year. If you'd need it sooner than what I've described above, then I wouldn't mind of you start working and with this and champion this work (of course we would like to be in the loop, both assisting and for discussion).

Having that said, what benefits would there be going with proposal one or two instead of option three? If we could gather a list of pro's and cons, I think we can make a better decision about how to actually do this.

I have did some basic verification about psci in op-tee. And I am happy to do some contribution. But rethinking about this, if we bind psci in op-tee, OP-TEE becomes mandatory for our software. if we want to make OP-TEE as an optional component, we may need to choose option 1 or 2.

Regards, Peng.

-- Regards, Joakim B

On Mon, Nov 14, 2016 at 10:04 AM, Jens Wiklander jens.wiklander@linaro.org wrote:

Hi,

On Mon, Nov 14, 2016 at 9:01 AM, Peng Fan peng.fan@nxp.com wrote:

...

Hi Joakim,

...

-----Original Message----- From: Joakim Bech [mailto:joakim.bech@linaro.org] Sent: Monday, November 14, 2016 3:43 PM To: Jerome Forissier jerome.forissier@linaro.org Cc: Peng Fan peng.fan@nxp.com; tee-dev@lists.linaro.org Subject: Re: [Tee-dev] Introduce PSCI for OP-TEE ARM32

Peng, Jerome,

On Fri, Nov 11, 2016 at 09:29:44PM +0100, Jerome Forissier wrote:

...

Le 11 nov. 2016 10:30 AM, "Peng Fan" peng.fan@nxp.com a écrit :

...

Hi,

I am trying to implement TEE and support Linux power features.

There are several options to include power features and TEE

1. ATFW for ARM32.

2. Develop runtime service code in U-Boot like ATFW.

3. Integrate PSCI ARM32 in OP-TEE.

Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32

support, I think(not sure), is not for legacy ARM32 cores.

Indeed it seems that the main focus is ARMv8-A. FYI, the presentation made by ARM at Linaro Connect is at http://connect.linaro.org/resource/las16/las16-402/.

Yes, we had a chat with ARM at Connect and currently it seems like their plans only cover ARMv8-A (I cannot tell whether that will change later on). Having that said we also discussed whether we (Linaro security team) could bring in the related functionality as a PSCI library into ARMv7-A. Due to the architectural differences between ARMv8-A and ARMv7-A, that would mean that we would need to bring the PSCI related code for ARMv7-A directly into the OP-TEE code base. I.e, we're talking about option three in Peng's proposal above. This is something we've put on our to-do list and would like to start looking into this cycle (which lasts until next Linaro Connect in Feb/March -17).

I don't think we will start the working until the beginning of next year. If you'd need it sooner than what I've described above, then I wouldn't mind of you start working and with this and champion this work (of course we would like to be in the loop, both assisting and for discussion).

Having that said, what benefits would there be going with proposal one or two instead of option three? If we could gather a list of pro's and cons, I think we can make a better decision about how to actually do this.

I have did some basic verification about psci in op-tee. And I am happy to do some contribution. But rethinking about this, if we bind psci in op-tee, OP-TEE becomes mandatory for our software. if we want to make OP-TEE as an optional component, we may need to choose option 1 or 2.

As long as we're talking about PSCI and you have a secure world, you'll need to deal with the PSCI calls in monitor mode. That basically means in the secure monitor or integrated with the secure monitor. As far as I understand ARM-TF on Aarch32 will not provide a secure monitor as that is expected to be provided by the secure OS. The reason for that is that in contrast to Aarch64, monitor mode (which is the EL3 counterpart in Aarch32) shares MMU settings etc with secure EL1 so the trusted OS and the secure monitor can never be completely separated.

So with PSCI, one way or the other on Aarch32/ARMv7-A the trusted OS will need to be involved when starting/stopping cores. An advantage with option 3 is that the interface used by Linux/normal world is standardized and no special driver is needed.

By the way, since handling PSCI in OP-TEE requires (or at least makes it a lot easier) dealing with it in monitor mode I have a redesigned secure monitor here https://github.com/jenswi-linaro/optee_os/tree/sm_redesign I'll probably rebase it at some point, and if it's ever merged I'll remove it of course.

Thanks, Jens