I have read in one ARM document
The TrustZone Address Space Controller (TZASC) is an AXI component which partitions its slave address range into a number of memory regions. The TZASC can be programmed by Secure software to configure these regions as Secure or Non-secure,and will reject Non-secure transactions to a region that is configured as Secure.
In the highlighted statement it is written that "secure software" will we configuring TZASC.
I want to know that if secure software also includes "Trusted OS" or only Code running in EL3/monitor mode can configure the TZASC.
Thanks
Sahil
Hi Sahil,
my long experience is with ARMv7-A Architecture.In ARMv7-A both monitor mode and supervisor mode runs in PL1, and both modes (in secure world) can be used for configuring the TZASC.
In ARMv8-A, ARM completely changed the Previlige Level classification, and the monitor mode runs in EL3, while the supervisor mode runs in EL1. Anyway, both modes have previliged access in the secure side, so I would say that might be possible to configure the TZASC also in both modes.Sandro
Secure software typically implies any software running in secure world. It could be EL3 monitor code, or Secure EL1(Trusted OS) or even Secure EL0(Trusted Apps) that configure the TZASC. The TZASC is unaware of exception levels(EL's) and only cares about the NS bit. So any transaction that is tagged with NS=0 should be able to configure the TZASC. Typically, all secure software accesses to controllers such as TZASC will be tagged as NS=0.
To answer your question directly, secure software also includes Trusted OS and not only code running in EL3/Monitor mode, and they can all configure the TZASC.
As the other replies say, any secure software /can/ program the TZASC because the only limit is the ability to generate secure bus transactions.
In practice many systems will have a static configuration of the TZASC which would usually be done by firmware at boot (typically from EL3)
Some advanced system will dynamically reconfigure the TZASC, effectively making the run time configuration of secure and non-secure regions possible. This would probably be done from EL1.
This programming of TZASC from secure world irrespective of Exception level raise following doubt.
Does giving access to the Secure OS to program the TZASC creates some vulnerability in the system ?
Like in the following link about Qualcomm Trusted Software flaw
https://www.onthewire.io/huge-number-of-android-phones-vulnerable-to-critical-trustzone-bug/
If such flaw is used to program the TZASC, the hacker can get access to whole system and in order to save from such flaws does this programming of TZASC should be confined only to monitor mode code running in EL3 ?
Sahil,
Having the Secure OS(Secure EL1 in the case of ARMv8-A) program the TZASC in itself doesn't cause any vulnerability. Vulnerabilities come from badly written code, badly tested code, from poor software practices or complexity in code.
If programming the TZASC in the secure OS can cause a vulnerability, the same code will have the same vulnerability in EL3 monitor code as well. One could argue that an exploit in EL3/Monitor code is maybe a little worse than a vulnerability in the secure OS.
Ultimately, if there is an exploit in code in almost any TrustZone code, the system is more or less toast. The key to not having vulnerabilities in TrustZone software is good secure software practices, isolating critical software using exception levels, virtual memory isolation, and correct use of hardware features like TrustZone, TZASC etc. Whether to program the TZASC in EL3 or Secure EL1 code will depend on a bunch of other factors and I don't think anyone can generalize the decision and say if it is better to program the TZASC in EL3 or Secure EL1 code.
Qualcomm's QSEE has probably turned into a beast(due to feature creep and complexity) over the years so it is not a big surprise that there are vulnerabilities. It also probably does not have much to do with where the TZASC(or equivalent) is programmed.