Hi, With the RME feature BL2 has to run at EL3 instead of EL1_S. EL3 has a separate PAS not accessible to EL1_S.
Is there any harm in choosing to run BL2 at EL3 instead of BL2 at S_EL1 even for non-RME(v8a) systems? Given that EL3 and EL1_S have access to the same PAS. I am trying to revisit the motivation to run BL2 at EL1_S.
I see there was an old discussion at https://github.com/ARM-software/tf-issues/issues/445 The reasoning was not pointing to any issue in specific but a generic principle of less permissiveness.
Thanks Sandeep
Hi Sandeep,
For two world systems, applying the principle of least privilege, BL2 can complete its task running at S-EL1 so need to run it at EL3. This is explained by Dan in [1] "The main reason for running BL2 at S-EL1 is to minimise the amount of code running at EL3, which is slightly more secure. Any other benefits are a side effect"
Few more reasons not to run BL2 at EL3 - BL2 is about loading components from flash to DRAM and using dangerous memcpys which can be harmful when image base and limits can be tricked by some means. - BL2 can also have drivers which are a good source of implementation bugs and have no real reason to exist in EL3/secure monitor. - S-EL1 cannot access EL3 registers
For four world systems, Since we can't complete all loader capability at S-EL1, we had to run it at EL3(as GPT HW is only accessible at EL3). Having said that, it's possible to re-factor BL2 in two parts, one running at EL3 and the other running S-EL1. Considering the effort required to achieve this, the current design has been chosen (running whole of BL2 at EL3) but it still can be a possibility in future to re-factor BL2.
Finally, to answer your question "Should BL2 execution state be different for 2 and 4 world system at the cost of diverging from basic security principle(in 2 world)?" - IMHO it's better not to diverge from security principle.
We can wait for others opinion!
Thanks Manish Pandey ________________________________ From: sandeep tripathy via TF-A tf-a@lists.trustedfirmware.org Sent: 14 September 2022 20:16 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] security: BL2 at EL3 on v8a based system
Hi, With the RME feature BL2 has to run at EL3 instead of EL1_S. EL3 has a separate PAS not accessible to EL1_S.
Is there any harm in choosing to run BL2 at EL3 instead of BL2 at S_EL1 even for non-RME(v8a) systems? Given that EL3 and EL1_S have access to the same PAS. I am trying to revisit the motivation to run BL2 at EL1_S.
I see there was an old discussion at https://github.com/ARM-software/tf-issues/issues/445 The reasoning was not pointing to any issue in specific but a generic principle of less permissiveness.
Thanks Sandeep
Hi Manish, BL2 at EL3 vs BL2 at S_EL1 for a V8 system does not make any difference security point of view with the current TBBR / tf-a reference implementation. There has to be a significantly different design and refactor to TBBR implementation and additional responsibility to EL3 firmware to take advantage of the EL3 root world in v9 (miniscule or maybe none? on v8 if at all). With the current tf-a design can we say that BL2_AT_EL3 is equally secure (or vulnerable !) as BL2 at S_EL1 system.
Since with v9 consciously tf-a could move to run BL2 at EL3 (root world really high privilege and RPAS unlike v8 El3 runtime with no PAS isolation from S_ELx) I think its contradicting to think running BL2 at S_EL3 is less secure in a v8 system. Because all that (BL2 large attack surface ..more drivers) apply to current tf-a on v9.
Anyway I am more concerned about only v8 right now.
S-EL1 cannot access EL3 registers
Agree, but what would be the motivation to access those when you have S-EL1 in control. All secure services are compromised. eg: the secure os S_EL2 S_EL1 What is the benefit to guard EL3 on v8.
Thanks Sandeep
Hi Sandeep,
First of all, i would like to clarify about "BL2_AT_EL3" macro, the name is bit misleading. The purpose of this macro is for platforms which does not have TF-A BL1, and the execution starts from EL3. The RME enablement has piggy backed on it. Ideally BL2_AT_EL3 should be decoupled from RME, and it should be re-named something more meaningful e.g., BL2_WITHOUT_BL1 or something similar. The existing name is more suitable for configuration where the platform has BL1 in it and BL2 can run at EL3 instead of S-EL1. This configuration is currently not available in TF-A but having this flexibility is not a bad idea and it can be platform's choice. But the default configuration still would be BL2 running at S-EL1.
To answer your queries, 1. Is BL2 running at_EL3 is equally secure (or vulnerable !) as BL2 at S-EL1 system? - There are implications if EL3 registers to be accessed from BL2, this will cause a gap in BL31, and we need to re-initialize EL3 registers to their correct values as BL2 can execute various programs(drivers, DDR Phy) before jumping back to EL3(BL31). 2. One of the reasons to not run BL2 at EL3 is, it cannot access EL3 registers, if secure services are compromised what's the benefit of guarding EL3? - There is a theoretical scenario where EL3 can disable secure world (disable secure interrupts/SMCs) and just run NS side.
Thanks Manish
________________________________ From: sandeep tripathy via TF-A tf-a@lists.trustedfirmware.org Sent: 21 September 2022 13:03 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: security: BL2 at EL3 on v8a based system
Hi Manish, BL2 at EL3 vs BL2 at S_EL1 for a V8 system does not make any difference security point of view with the current TBBR / tf-a reference implementation. There has to be a significantly different design and refactor to TBBR implementation and additional responsibility to EL3 firmware to take advantage of the EL3 root world in v9 (miniscule or maybe none? on v8 if at all). With the current tf-a design can we say that BL2_AT_EL3 is equally secure (or vulnerable !) as BL2 at S_EL1 system.
Since with v9 consciously tf-a could move to run BL2 at EL3 (root world really high privilege and RPAS unlike v8 El3 runtime with no PAS isolation from S_ELx) I think its contradicting to think running BL2 at S_EL3 is less secure in a v8 system. Because all that (BL2 large attack surface ..more drivers) apply to current tf-a on v9.
Anyway I am more concerned about only v8 right now.
S-EL1 cannot access EL3 registers
Agree, but what would be the motivation to access those when you have S-EL1 in control. All secure services are compromised. eg: the secure os S_EL2 S_EL1 What is the benefit to guard EL3 on v8.
Thanks Sandeep -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Manish Pandey2 wrote:
Hi Sandeep, First of all, i would like to clarify about "BL2_AT_EL3" macro, the name is bit misleading. The purpose of this macro is for platforms which does not have TF-A BL1, and the execution starts from EL3. The RME enablement has piggy backed on it. Ideally BL2_AT_EL3 should be decoupled from RME, and it should be re-named something more meaningful e.g., BL2_WITHOUT_BL1 or something similar. The existing name is more suitable for configuration where the platform has BL1 in it and BL2 can run at EL3 instead of S-EL1. This configuration is currently not available in TF-A but having this flexibility is not a bad idea and it can be platform's choice. But the default configuration still would be BL2 running at S-EL1. To answer your queries,
- Is BL2 running at_EL3 is equally secure (or vulnerable !) as BL2 at S-EL1 system?
- There are implications if EL3 registers to be accessed from BL2, this will cause a gap in BL31, and we need to re-initialize EL3 registers to their correct values as BL2 can execute various programs(drivers, DDR Phy) before jumping back to EL3(BL31).
- One of the reasons to not run BL2 at EL3 is, it cannot access EL3 registers, if secure services are compromised what's the benefit of guarding EL3?
- There is a theoretical scenario where EL3 can disable secure world (disable secure interrupts/SMCs) and just run NS side.
Thanks Manish ________________________________ From: sandeep tripathy via TF-A tf-a@lists.trustedfirmware.org Sent: 21 September 2022 13:03 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: security: BL2 at EL3 on v8a based system Hi Manish, BL2 at EL3 vs BL2 at S_EL1 for a V8 system does not make any difference security point of view with the current TBBR / tf-a reference implementation. There has to be a significantly different design and refactor to TBBR implementation and additional responsibility to EL3 firmware to take advantage of the EL3 root world in v9 (miniscule or maybe none? on v8 if at all). With the current tf-a design can we say that BL2_AT_EL3 is equally secure (or vulnerable !) as BL2 at S_EL1 system. Since with v9 consciously tf-a could move to run BL2 at EL3 (root world really high privilege and RPAS unlike v8 El3 runtime with no PAS isolation from S_ELx) I think its contradicting to think running BL2 at S_EL3 is less secure in a v8 system. Because all that (BL2 large attack surface ..more drivers) apply to current tf-a on v9. Anyway I am more concerned about only v8 right now.
S-EL1 cannot access EL3 registers Agree, but what would be the motivation to access those when you have S-EL1 in control. All secure services are compromised. eg: the secure os S_EL2 S_EL1 What is the benefit to guard EL3 on v8.
Thanks Sandeep -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Manish Pandey2 wrote:
Hi Sandeep, First of all, i would like to clarify about "BL2_AT_EL3" macro, the name is bit misleading. The purpose of this macro is for platforms which does not have TF-A BL1, and the execution starts from EL3. The RME enablement has piggy backed on it. Ideally BL2_AT_EL3 should be decoupled from RME, and it should be re-named something more meaningful e.g., BL2_WITHOUT_BL1 or something similar. The existing name is more suitable for configuration where the platform has BL1 in it and BL2 can run at EL3 instead of S-EL1. This configuration is currently not available in TF-A but having this flexibility is not a bad idea and it can be platform's choice. But the default configuration still would be BL2 running at S-EL1. To answer your queries,
- Is BL2 running at_EL3 is equally secure (or vulnerable !) as BL2 at S-EL1 system?
- There are implications if EL3 registers to be accessed from BL2, this will cause a gap in BL31, and we need to re-initialize EL3 registers to their correct values as BL2 can execute various programs(drivers, DDR Phy) before jumping back to EL3(BL31).
- One of the reasons to not run BL2 at EL3 is, it cannot access EL3 registers, if secure services are compromised what's the benefit of guarding EL3?
- There is a theoretical scenario where EL3 can disable secure world (disable secure interrupts/SMCs) and just run NS side.
Thanks Manish ________________________________ From: sandeep tripathy via TF-A tf-a@lists.trustedfirmware.org Sent: 21 September 2022 13:03 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: security: BL2 at EL3 on v8a based system Hi Manish, BL2 at EL3 vs BL2 at S_EL1 for a V8 system does not make any difference security point of view with the current TBBR / tf-a reference implementation. There has to be a significantly different design and refactor to TBBR implementation and additional responsibility to EL3 firmware to take advantage of the EL3 root world in v9 (miniscule or maybe none? on v8 if at all). With the current tf-a design can we say that BL2_AT_EL3 is equally secure (or vulnerable !) as BL2 at S_EL1 system. Since with v9 consciously tf-a could move to run BL2 at EL3 (root world really high privilege and RPAS unlike v8 El3 runtime with no PAS isolation from S_ELx) I think its contradicting to think running BL2 at S_EL3 is less secure in a v8 system. Because all that (BL2 large attack surface ..more drivers) apply to current tf-a on v9. Anyway I am more concerned about only v8 right now.
S-EL1 cannot access EL3 registers Agree, but what would be the motivation to access those when you have S-EL1 in control. All secure services are compromised. eg: the secure os S_EL2 S_EL1 What is the benefit to guard EL3 on v8.
Thanks Sandeep -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Manish Pandey2 wrote:
Hi Sandeep, First of all, i would like to clarify about "BL2_AT_EL3" macro, the name is bit misleading. The purpose of this macro is for platforms which does not have TF-A BL1, and the execution starts from EL3. The RME enablement has piggy backed on it. Ideally BL2_AT_EL3 should be decoupled from RME, and it should be re-named something more meaningful e.g., BL2_WITHOUT_BL1 or something similar. The existing name is more suitable for configuration where the platform has BL1 in it and BL2 can run at EL3 instead of S-EL1. This configuration is currently not available in TF-A but having this flexibility is not a bad idea and it can be platform's choice. But the default configuration still would be BL2 running at S-EL1. To answer your queries,
- Is BL2 running at_EL3 is equally secure (or vulnerable !) as BL2 at S-EL1 system?
- There are implications if EL3 registers to be accessed from BL2, this will cause a gap in BL31, and we need to re-initialize EL3 registers to their correct values as BL2 can execute various programs(drivers, DDR Phy) before jumping back to EL3(BL31).
- One of the reasons to not run BL2 at EL3 is, it cannot access EL3 registers, if secure services are compromised what's the benefit of guarding EL3?
- There is a theoretical scenario where EL3 can disable secure world (disable secure interrupts/SMCs) and just run NS side.
Thanks Manish ________________________________ From: sandeep tripathy via TF-A tf-a@lists.trustedfirmware.org Sent: 21 September 2022 13:03 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: security: BL2 at EL3 on v8a based system Hi Manish, BL2 at EL3 vs BL2 at S_EL1 for a V8 system does not make any difference security point of view with the current TBBR / tf-a reference implementation. There has to be a significantly different design and refactor to TBBR implementation and additional responsibility to EL3 firmware to take advantage of the EL3 root world in v9 (miniscule or maybe none? on v8 if at all). With the current tf-a design can we say that BL2_AT_EL3 is equally secure (or vulnerable !) as BL2 at S_EL1 system. Since with v9 consciously tf-a could move to run BL2 at EL3 (root world really high privilege and RPAS unlike v8 El3 runtime with no PAS isolation from S_ELx) I think its contradicting to think running BL2 at S_EL3 is less secure in a v8 system. Because all that (BL2 large attack surface ..more drivers) apply to current tf-a on v9. Anyway I am more concerned about only v8 right now.
S-EL1 cannot access EL3 registers Agree, but what would be the motivation to access those when you have S-EL1 in control. All secure services are compromised. eg: the secure os S_EL2 S_EL1 What is the benefit to guard EL3 on v8.
Thanks Sandeep -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Hi Manish,
There is a theoretical scenario where EL3 can disable secure world
TF-A TBBR implementation where BL2 is not just a loader but it also owns TBBR flow I don't think there is a feasibility to achieve this. How will EL3 runtime remain protected from secure world? Any core in secure state can overwrite EL3 runtime. I understand with significant redesign to TBBR (out-of-scope) there may be some advantages.
having this flexibility is not a bad idea and it can be platform's choice
I think I have my answer here.
Thanks Sandeep
tf-a@lists.trustedfirmware.org
-
Manish Pandey2 -
sandeep tripathy