Introduction to SoC
Security Fundamentals; SoC Security Tutorial
A user may often come across this word called 'access protection'.
What is it and how does it work and why it is needed?
We learned in the previous chapter, that how the memory can be
partitioned into 'regions' with attributes such as privileged,
un-privileged, secure, non-secure or a combination of these, in ARM
Trust Zone World.
But what happens if the SoC has multiple processors?
Each processor may then set 'attributes' to the memory regions, as
seen from his eye. However there always has to be a 'main'
processor, the most trusted processor which will first set the
attributes, and then allow other processors to set 'attributes' may
be in some controlled way.
But in any way, the memory attributes as defined by one processor
must be distinguishable from the one defined by other processor.
More over the 'main' processor may limit the other processors'
rights or other processors' access permissions into various regions
of the memory.
This means that every access issued by any master on the SoC must be
identifiable, as to which 'master' it belongs to?
(BTW 'master' is taken from AHB master/slave representation.
This means 'master' is someone who can issue transactions.
A processor may have multiple 'masters' or a single 'master')
Usually this is done by the SoC Interconnect or SoC fabric or simply
In the simplest case, the SoC Interconnect will add a HW generated
field to the master, usually this is called master ID.
Now each master on the SoC has an ID, and therefore each access can
be identified which master is belongs to.
It now becomes simpler to manage the memory attributes or access
rights of different masters on the system.
The main processor or the most trusted processor will usually 'set'
the access rights for all the masters in the system. It will decide
which masters are allowed to access which regions of the memory. And in what potential
This mechanism of distribution of 'access rights' for masters on the
system using their ID is commonly called 'Access Protection'.
It simply defines which masters are allowed to access which memory
regions, in what potential.
For example a master with ID 00101 (5). may be allowed to access a
memory region from 0x4000_0000 to 0x4001_0000, on 'read-only' basis.
'read-only' is then the 'attribute' which has been attached to the
above said memory location for the Master '5' on the system.
Access protection can therefore be very complex as there are
multiple attributes and then multiple masters and then multiple
Some examples of attributes:
When a transaction is issued by any master, it will carry some bits
- Execute only
- No Access
These can be called as the 'transaction attributes'
- The Master ID
- If it is secure or a non-secure transaction
- If it is a privileged or non-privileged transaction
- If it is a code/data fetch fetch
- If it read or write transaction.
- It will of course has an address.
Somewhere in the path from the master to the final target, a Access
protection HW block will sit. Usually the most trusted master will
program this HW block. The HW block can be a hard-wired block as
well, but usually it is a programmable block. The most trusted
master will program this block so that the block will then allow
only accesses with certain 'transaction attributes' to certain
memory addresses, while block all the others. The Access protection
block checks the 'transaction attributes' with the 'programmed
attributes' and if there is a 'match' it allows the access, if there
isn't a 'match' it disallows the access, and generates a error
response to the requesting master.
For example, an access protection block sitting just before a 'SRAM'
block on the system might be programmed thus
- For Master ID, say '01100' only memory region from 0x2000_0000
to 0x2001_FFFF is allowed.
- For Master ID, say '00001' only memory region from 0x2000_0000
to 0x2000_1FFF is allowed with 'read-only' permission. i.e this
master may only read from this memory location but not write to
and son on and so fourth.
Now when an transaction is issued, it is sampled by this HW access
protection block. This block then checks the transaction's master
ID, and the address for say case (1) above. If the ID is '01100' and
the address of the transaction is between 0x2000_0000 to
0x2001_FFFF, the access is allowed to progress. If not, then an
error response is generated towards the master. The Access
Protection HW block may also be designed to keep some of the
attributes of the failed accesses to help debug.
The MPU and the SAU:
The arm processors offer something called 'MPU' : Memory Protection
This Unit when opted for, can be programmed at the source of the
transaction, so that the transaction even before being issued from
the source is checked if it has the right attributes. If it doesn't
then an error is generated inside the processor it self.
The arm processors with Trust Zone support offer Security Attributes
Unit (SAU) in addition to MPU, to further enhance the attribute
setting and attribute checking.
There is no right/wrong way. The user may used custom Access
protection blocks and place them anywhere in the path from the
Master to the target, or the user may use MPU/SAU, or a combination
of all of these to define the Access Protection Mechanism or
the Access Security Policies in the system.
Click Here to Make Comments or ask Questions
PREV : SoC Security Fundamentals
Security Flow Chart =>