eclipse version

ARM's specification of TrustZone is in the ARMv7-A/R Architecture Reference Manual, covered by any section which talks about "Security Extensions." The essential components have to be there for architecture licensees like Qualcomm to have ARM sign off on whether this is an Architecturally Compliant core or not (otherwise ARM bears the risk of there being this weird almost-ARM core in the world). In that sense, you can rely on the instruction set to be absolutely identical, although some co-processor accesses might be slightly different, if they say they support it.

The starting address of different system and subsystems would be different for every SoC - ARM don't define a memory map, really, beyond the standard vector base addresses (0x00000000 and 0xFFFF0000); although some architecturally defined components should have a similar - if not identical - register mapping starting from those SoC-dependent base addresses.

Essentially, the Security Extensions cover a few registers, the banking of those registers based on current value of the SCR.NS bit, the MON(itor) mode, and the behaviours associated with those registers and modes (including the SMC instruction). Outside the core, more needs to be implemented -- the "Secure" part of the Security Extensions is that the Non-Secure and Secure worlds can't interact through memory locations marked Secure. The Secure world -- with translation table descriptors marking memory locations as Secure -- has it's own entirely separate Virtual address space and also a theoretically separate Physical address space. The Architecture defines how those are managed, too, in terms of caches and so on, so you can get an assurance that it is secure per the architecture no matter who implements it.

Outside the core it is less clear cut from a design perspective -- if it's an ARM core with an AMBA bus (AXI for example) then whether a memory access is Secure or not is a protection bit on the bus (AxPROT[1], for example), and on a 32-bit addressed bus it could be thought of as a 33rd address bit to split up those two theoretically separate Physical address spaces. SoC-specific peripherals receiving those transactions should be able to arbitrate whether they can service an address with one or the other protection bit setting. On a non-AMBA bus -- Qualcomm, for example, are free to implement whatever bus architecture and protocol they like as long as it meets the demands of the ARM Architecture -- it could be a different methodology and protocol to determine security of transactions, a raft of bits or some other signalling or a whole other port from the core on a completely different bus, but it still has to be respected for it to work properly.

That protection bus mechanism may be further controlled outside the core by some kind of security controller IP which is configurable, but this is also outside the space ARM defines. Every SoC vendor has their own, and this is probably the bit you really need an NDA from the SoC vendor to get hold of the programming mechanism for that component. ARM has a couple, though, the TrustZone Address Space Controller, which are publicly documented, and several System MMU components which can modify security attributes, and if you're lucky the SoC vendor will have used one of them. Note that ARM also defines the Generic Interrupt Controller (GIC) Architecture, which is relevant -- most vendors use it, or have implemented something which complies with the architecture, and there are some security implications required to be tended to when using it.

Ta,

Matt

ARM's specification of TrustZone is in the ARMv7-A/R Architecture Reference Manual, covered by any section which talks about "Security Extensions." The essential components have to be there for architecture licensees like Qualcomm to have ARM sign off on whether this is an Architecturally Compliant core or not (otherwise ARM bears the risk of there being this weird almost-ARM core in the world). In that sense, you can rely on the instruction set to be absolutely identical, although some co-processor accesses might be slightly different, if they say they support it.

The starting address of different system and subsystems would be different for every SoC - ARM don't define a memory map, really, beyond the standard vector base addresses (0x00000000 and 0xFFFF0000); although some architecturally defined components should have a similar - if not identical - register mapping starting from those SoC-dependent base addresses.

Essentially, the Security Extensions cover a few registers, the banking of those registers based on current value of the SCR.NS bit, the MON(itor) mode, and the behaviours associated with those registers and modes (including the SMC instruction). Outside the core, more needs to be implemented -- the "Secure" part of the Security Extensions is that the Non-Secure and Secure worlds can't interact through memory locations marked Secure. The Secure world -- with translation table descriptors marking memory locations as Secure -- has it's own entirely separate Virtual address space and also a theoretically separate Physical address space. The Architecture defines how those are managed, too, in terms of caches and so on, so you can get an assurance that it is secure per the architecture no matter who implements it.

Outside the core it is less clear cut from a design perspective -- if it's an ARM core with an AMBA bus (AXI for example) then whether a memory access is Secure or not is a protection bit on the bus (AxPROT[1], for example), and on a 32-bit addressed bus it could be thought of as a 33rd address bit to split up those two theoretically separate Physical address spaces. SoC-specific peripherals receiving those transactions should be able to arbitrate whether they can service an address with one or the other protection bit setting. On a non-AMBA bus -- Qualcomm, for example, are free to implement whatever bus architecture and protocol they like as long as it meets the demands of the ARM Architecture -- it could be a different methodology and protocol to determine security of transactions, a raft of bits or some other signalling or a whole other port from the core on a completely different bus, but it still has to be respected for it to work properly.

That protection bus mechanism may be further controlled outside the core by some kind of security controller IP which is configurable, but this is also outside the space ARM defines. Every SoC vendor has their own, and this is probably the bit you really need an NDA from the SoC vendor to get hold of the programming mechanism for that component. ARM has a couple, though, the TrustZone Address Space Controller, which are publicly documented, and several System MMU components which can modify security attributes, and if you're lucky the SoC vendor will have used one of them. Note that ARM also defines the Generic Interrupt Controller (GIC) Architecture, which is relevant -- most vendors use it, or have implemented something which complies with the architecture, and there are some security implications required to be tended to when using it.

Ta,

Matt