Introduction to SoC Security Fundamentals; SoC Security Tutorial
Access Protection
-Aviral Mittal avimit att yahu dat cam.
https://www.linkedin.com/in/avimit/
SITE HOME


Access Protection:
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 SoC bus.
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 memory regions.
Some examples of attributes:
When a transaction is issued by any master, it will carry some bits to identify
These can be called as the 'transaction attributes'

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
  1. For Master ID, say '01100' only memory region from 0x2000_0000 to 0x2001_FFFF is allowed.
  2. 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 it.

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 Unit.
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                                      Next SoC Security Flow Chart =>

SITE HOME