I'm using a Juno r1 board which is deployed with a Yukon Ultra-2 Ethernet Controller. Now I'm working on a project which is trying to protect some registers of this NIC based on the TrustZone technology so the best solution for me is configuring these registers as secure-world access-only. My thought is setting the physical address of these registers as secure world address while I'm not sure if it's possible or not.
If this is not feasible, then I want to know can I configure the entire NIC with S/NS attributes dynamically during the runtime? For example, when the normal world switch to the secure world, EL3 configure the NIC as secure-world device and recover it as the NS device after the secure world execution.
Any suggestion or related document is appreciated! Thank you in advance.
I don't think you can do this. Secure accesses ultimately rely on a hardware side-band signal (AXPROT) that is propagated on the bus. A Secure peripheral is one that will only respond to a bus access marked as Secure. You can see in the Juno SoC TRM there are a limited number of secure peripherals
In Secure world software you can control whether a memory access is Secure or Non-Secure
But, how a peripheral responds to such accesses (i.e. will it only respond to Secure accesses) is down to the peripheral itself & decided at hardware design time.
Thank you for your reply.
I did check the Juno SoC TRM and I found that in the section Trusted HDLCD Controller, the manual mentions:
The ARM HDLCD controller does not support security. In the ADP, the SSD table present in the MMU-401 determines the security state of the HDLCD controller.
Is this Trusted HDLCD Controller of Juno fits the secure peripheral you mentioned above? If it is, then I don't understand that how does the HDLCD controller blocks the non-secure access when it's set as secure peripheral?
Also, I found there is a Secure Register on page 3-90 and the manual says the first bit of this register can control whether non-secure transactions can access the PCIe registers or not. In this case, I'm wondering which registers are protected by this Secure Register?
Thank you in advance.
There are lots of ways to implement the necessary security in hardware, the approach depends on how sophisticated the peripheral is and whether its status needs to be configurable at boot time by secure software.
I think you've picked a complicated example:-)
In my first post I was thinking about a very simple example of a CPU reading a simple secure peripheral/register. (e.g. some of the MHU registers are secure access only). This peripheral is "security aware" and some registers are only accessible using secure accesses (with AxPROT asserted).
The HDLCD example is Figure 2-7 in the Juno SoC TRM "Trustzone Display controller". The peripheral is assumed to read from a frame buffer in secure memory.
The HDLCD controller is not aware of security signals on the bus. i.e. it can't generate a secure or non secure bus transaction itself. However the SMMU (MMU-401) in front of the HDLCD can be configured so that the reads are propagated to the NIC as either Secure or Non Secure.
The System Override register is a simple custom peripheral that ensures that all accesses are propagated as Secure, regardless of the SMMU programming.
Either the port on the NIC associated with the Trusted Memory or the some logic before (or inside) the memory will generate a bus error if the access is not Secure. (i.e. If AXPROT is not asserted appropriately)
I hope that helps
Thank you for your kindly detailed explanation on the HDLCD controller.
I think I understand how does the transaction generated from HDLCD controller is configured as S/NS transaction. However, I'm still confused about the following case:
Assume I set the HDLCD controller as trusted on both SMMU and SEC_HDLCD register, and the controller can read the data from the secure memory. Now if a core with NS privilege generates a read transaction on the address area belong to this HDLCD controller via memory-mapped I/O, is this transaction blocked by some component?
Thank you again for your help.
View all questions in Arm Development Platforms forum