TrustZone hardware features (TZASC, TZMA, TZPC) on HiKey

Products Support HiKey
#1

Hi,

I was looking for a development board were the ARM TrustZone features can be utilized by the developer and this is how I came across the HiKey Board which seems perfect for that use case.
So now I am wondering what memory types are actually protected by TrustZone hardware features on the board.
For the ARM Juno Board e.g. I read (Genode - An Exploration of ARM TrustZone Technology) that the SRAM and Flash can be configured fine-grained with a TZASC, a TZPC can be used to protect peripherals and the DRAM as a whole can be configured for secure or non-secure world.

How is the situation on the HiKey Board? I know that the DRAM is protected with a TZASC but are there other TrustZone hardware features available on the board and does some documentation on that exist?

Regards,
Manu

#2

Hi

A good starting point might be here - https://github.com/OP-TEE/optee_os.

HiKey is certainly a very good candidate.

Also another related topic - Hikey Lemaker OPTEE kernel working source code - #2 by jbech

HTHs
Yang

#3

Hi, please refer to https://github.com/OP-TEE/optee_os/issues/948 for more details.

#4

Hi VChong,

thank you very much for the link, so if I understand correctly:

  • there is a TZC-400 on the board which can be used to partition the DRAM
  • there is no on-SoC SRAM on the board
  • there is a TZPC on the board but there is no documentation on it

Is that correct?

And a short follow up question. When we cannot use the TZPC (or only for UART3), doesn’t that mean that peripherals connected on the AXI-to-APB Bridge can only be configured as secure or non-secure statically, which e.g. means I can never implement a secure input?

Because the ARM documentation of TrustZones says:

Each AXI-to-APB bridge provides an AXI slave interface and can mediate accesses for
up to 16 peripherals on its local APB bus. The bridge contains address decode logic that
generates the APB peripheral select based on the incoming AXI transaction. The bridge
includes a single TZPCDECPROT input signal for each peripheral that is located on
the bus. This signal is used to determine if the peripheral is configured as Secure or
Non-secure; the bridge will reject Non-secure transactions to Secure peripheral address
ranges.
These bridge input signals can be tied persistently at synthesis time or can be
dynamically controlled via a trusted peripheral, such as the TrustZone Protection
Controller (TZPC), to allow dynamic switching of security state at run-time.

http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf

Regards,
Manu

#5

there is a TZC-400 on the board which can be used to partition the DRAM

Yes, but there’s no doc on it too. Also, afaik it’s something similar to a TZASC but not exactly a TZC-400.

there is no on-SoC SRAM on the board

Sorry, not sure about this. I know there is SRAM, but not sure if it’s on-SoC or not.

there is a TZPC on the board but there is no documentation on it

Yes.

And a short follow up question. When we cannot use the TZPC (or only for UART3), doesn’t that mean that peripherals connected on the AXI-to-APB Bridge can only be configured as secure or non-secure statically, which e.g. means I can never implement a secure input?

Sorry, not sure I follow you. You can use the TZPC to secure UART3. Sample code is in https://github.com/OP-TEE/optee_os/issues/1065, but I think Normal World can revert the setting, because the code to ‘lock down’ this operation is not disclosed. Still, you can use the sample code for testing and development. Since this is a dev board only, the hope is that users can port the reference code to their own product/platform where they would have the ability to do the final ‘lock down’.

#6

Okay, thanks for the information regarding my bullet points.

Maybe I should spend a few more scentences on my follow up question to describe what I mean.
I haven’t worked with the ARM TrustZone so far, but what I understand from the TrustZone documentation I referenced, peripherals are connected to the SoC via a AXI-to-APB bridge. So at one point in time, probably the time when the secure world is set up the first time, some of the peripherals are statically set as secure such that only the secure world can access them when the system is running. For some peripherals like a fingerprint sensor this totally makes sense for me, because there is actually no need for a normal world app to access it. However, some peripherals like a keyboard would probably be used by apps in the normal AND secure world. This means I would have to switch the security state at run-time. However, according to the docs this is only possible when using a TZPC, ergo we cannot dynamically set the security state of all the peripherals on the HiKey board or at least we don’t know how because we have no documentation on that.
So my question simply was if this is a correct line of thought.

Apart from that, I understand that this is a development board and that some parts are available from the normal world which would not be the case in a deployed system. I e.g. also assume that there are no keys fused into an OTP, if such a memory exists on the board.

Best Regards,
Manu

#7

It’s probably doable, but maybe very limited (in terms of functionalities) and not easily done due to the lack of info/doc. E.g. you can probably create APIs from reference code to say lock or unlock the UART3 or etc. Then there’s also the missing piece of how do you design in the decision of when to lock or unlock, and who (which component(s)) is/are allowed to do it. This whole concept of securing peripherals/IOs and sharing access involves a relatively long chain of components and is basically still a work in progress. E.g. LKML: Peter Maydell: [PATCH] Documentation: dt: Add bindings for Secure-only devices, BUD17-313: BoF - Device Tree and Secure Firmware, https://github.com/OP-TEE/optee_os/pull/679 and https://github.com/OP-TEE/optee_os/pull/1433 are some examples. My 2 cents is that it might take a while to get ‘there’ eventually, but I might be wrong.

#8

Okay, thank you very much for your thoughts on that topic.

Regards,
Manu

#9

Hi,

I just went through all the discussion in this thread.
I was looking for a board which has fully TrustZone supported (TZPC, TZMA, TZASC). (almost the same problem as you had.)

  • Have you found such board?
  • If not, did you have the detail documents about TZPC on Hikey?

Thanks for your help in advance.

Best,
Diot