Isolate peripheral to prevent non-secure accesses

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

Hello everyone,

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?

Thanks in advance.

2

Hello,

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?

Thanks

3

Hi Pierre_Lucas

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.

Thanks

4

The use case is having two OSes running in co-execution based on the ARM-Trusted-Firmware model [url]http://www.slideshare.net/linaroorg/arm-trusted-firmareforarmv8alcu13[/url].

We currently have the Linux ported by NVIDIA running on the Non-Secure side and a Real-Time OS on the Secure.

We would like to know if it is possible to isolate the peripherals so that only the Real-time OS can access them.

Thanks

Edit: I guess we could modify the .dtb but we want to leave the Linux side as untouched as possible.

5

Hi Pierre_Lucas,

By discussing with the team, for your case, please refer to the information in “21.1.7 AP Control Registers” of TRM document
[url]http://developer.nvidia.com/embedded/dlc/tegra-x1-technical-reference-manual[/url], as below:

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.

Thanks

6

Thank you very much, it seems this function will indeed meet my needs.

I have yet to receive the list of the peripherals we need to isolate, so I might come back to you later on.

Do you mean Linux is not using this functionality?

Thanks again.

7

"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”… :)

8

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:

For instance, they have in plat_setup.c

static const mmap_region_t tegra_mmap = {
MAP_REGION_FLAT(MMIO_RANGE_0_ADDR, MMIO_RANGE_SIZE,
MT_DEVICE | MT_RW | MT_SECURE),
MAP_REGION_FLAT(MMIO_RANGE_1_ADDR, MMIO_RANGE_SIZE,
MT_DEVICE | MT_RW | MT_SECURE),
MAP_REGION_FLAT(MMIO_RANGE_2_ADDR, MMIO_RANGE_SIZE,
MT_DEVICE | MT_RW | MT_SECURE),
{0}
};

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.

9

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.

Thank you,
Pierre