I’m investigating on a solution to isolate a memory-mapped peripheral (e.g., I2C) in order to allow only secure accesses to its registers. Do you know if a hardware IP allows such a configuration on the NVIDIA Jetson TX1?
Reading the reference manual, I saw that there is the SMMU which form my understanding is like the MMU but for peripheral. Do you know if it can be used to solve my issue?
We’re not sure your use case, are you porting KVM(Kernel-based Virtual Machine) or others?
Please help to provide more details, then could help to provide the suggesiton.
21.1.7 AP Control Registers
Secure Registers
21.1.7.1 APB_MISC_SECURE_REGS_APB_SLAVE_SECURITY_ENABLE_REG0_0
APB Slave Security Enable Register 0
These registers are used to enable and disable secure access of corresponding APB slaves. If set, the corresponding APB
slave is accessed only via secure transactions.
Offset: 0xc00 | Read/Write: R/W | Reset: 0x00000000 (0bxx0xxxx00000x0x0000x0000x0x0000x)
Theoretical you can put the entire peripheral block into TZ only by programming that register.
The function is ready from hardware’s perspective but the software architecture never really use this function.
"Do you mean Linux is not using this functionality? "
What I think kaycc is saying is that the software architecture is not currently implementing the Trustzone architecture as defined by ARM. To do so is a rather an undertaking (e.g pre-uboot bootloader or replace u-boot, secure loading of FIP images, secure monitor, etc).
Security aspects (programming of the APB,etc) are generally set-up outside of/before the kernel including setting up the MMU for each exception level. Setting up this stuff in Linux, while possible, does not create a truly secure system. It may work for what you need but it may not be resistant to a variety of attack vectors.
Security stuff needs to be set-up early. That is, before the point where the first context switch out of EL3 occurs.
But like most things in life when it comes to the trade-offs, it “depends”… :)
Well, it appears that the Arm Trusted Firmware does have Tegra in the platforms area…
So, if one were so inclined to implement this on the TX1 (which I do not think they have), you’d be able to set-up early security settings including setting up the MMU for the various exception levels:
This is used to program the MMU to secure certain MMIO address spaces. Much more complicated scenarios for each of the EL levels are possible. There are a variety of other platforms that do this.
But, while being a great security architecture, implementing all of this would take a bit of effort to get right.
I suppose I should have mentioned in my previous post, but we already have a modified version of the Arm Trusted Firmware running on the TX1.
We were wondering whether doing the security setup in the Secure OS or in the BL31 as both are running before u-boot, you just answered my question, thank you.
We also thought about using the MMU, it is always interesting to have another solution.