3

I am trying to run a Linux kernel as the secure OS on a TrustZone enabled development board(Samsung exynos 4412). Although somebody would say secure os should be small and simple. But I just want to try. And if it is possible, then write or port a trustlet application to this secure os will be easy, especially for applications with UI(trusted UI).

I bought the development board with a runnable secure OS based on Xv6 and the normal os is Android(android version 4.2.2, kernel version 3.0.15). I have tried to replace the simple secure os with the android Linux kernel, that is, with a little assembly code ahead, such as clearing the NS bit of SCR register, directly called the Linux kernel entry(with necessary kernel tagged list passed in).

The kernel uncompressed code is executed correctly and the first C function of the kernel, start_kernel(), is also executed. Almost all the initialization functions run well except running to calibrate_delay(). This function will wait for the jiffies changed:

/* wait for "start of" clock tick */
ticks = jiffies;
while (ticks == jiffies);

I guess the reason is no clock interrupt is generated(I print logs in clock interrupt callback functions, they are never gotten in). I have checked the CPSR state before and after the local_irq_enable() function. The IRQ and FIQ bit are set correctly. I also print some logs in the Linux kernel's IRQ handler defined in the interrupt vectors table. Nothing logged.

I know there may be some differences in interrupt system between secure world and non secure world. But I can't find the differences in any documentation. Can anybody point out them? And the most important question is, as Linux is a very complicated OS, can Linux kernel run as a TrustZone secure OS?

I am a newbie in Linux kernel and ARM TrustZone. Please help me.

Hendy So
  • 31
  • 1
  • 4
  • The kernel is compiled for the 'real' hardware and not the hardware TrustZone (for which drivers are unlikely to even exist). – CL. Sep 02 '14 at 10:23
  • Thanks for your reply. But I have seen several trustzone implementations that can do lots of things, like UI display and touch screen. You can see the Genode implementation. [Documentation](http://genode.org/documentation/articles/trustzone) [Video](https://www.youtube.com/watch?v=voFV1W4yyY8) – Hendy So Sep 02 '14 at 12:29
  • Your question seems a little unclear. Checkout all the questions in the tag [tag:trust-zone] and especially the question [How to develop programs for arm trust zone](http://stackoverflow.com/questions/15455011/how-to-develop-programs-for-arm-trust-zone). You **do not** need a secure OS to have a secure *trustlet*; just secure boot, a partition checker with boot lock and a monitor table with the Secure API. – artless noise Sep 02 '14 at 16:40
  • Also: http://community.arm.com/thread/6498 – artless noise Sep 04 '14 at 15:02
  • Yes, secure boot can solve some problems. But more things done in secure world, it is more secure. For example, UI input maybe intercepted by other applications. If the UI runs in secure world, may call trustui, then they cannot be intercepted. The whole screen physical peripheral cannot be accessed in a non-secure world at this point. – Hendy So Sep 11 '14 at 13:00
  • actually, community.arm.com/thread/6498 was also posted by me :) – Hendy So Sep 11 '14 at 13:03

3 Answers3

2

Running Linux as a secure world OS should be standard by default. Ie, the secure world supervisor is the most trusted and can easily transition to the other modes. The secure world is an operating concept of the ARM CPU.

Note: Just because Linux runs in the secure world, doesn't make your system secure! TrustZone and the secure world are features that you can use to make a secure system.

But I just want to try. And if it is possible, then write or port a trustlet application to this secure os will be easy, especially for applications with UI(trusted UI).

TrustZone allows partitioning of software. If you run both Linux and the trustlet application in the same layer, there is no use. The trustlet is just a normal application.

The normal mode for trustlets is to setup a monitor vector page on boot and lock down physical access. The Linux kernel can then use the smc instruction to call routines in the trustlet to access DRM type functionality to decrypt media, etc. In this mode, Linux runs as a normal world OS, but can call limited functionality with-in the secure world through the SMC API you define.

Almost all the initialization functions run well except running to calibrate_delay().

This is symptomatic of non-functioning interrupts. calibrate_delay() runs a tight loop while waiting for a tick count to increase via system timer interrupts. If you are running in the secure world, you may need to route interrupts. The register GICD_ISPENDR can be used to force an interrupt. You may use this to verify that the ARM GIC is functioning properly. Also, the kernel command line option lpj=XXXXX (where XXXX is some number) can skip this step.

Most likely some peripheral interrupt router, clock configuration or other interrupt/timer initialization is done by a boot loader in a normal system and you are missing this. Booting a new board is always difficult; even more so with TrustZone.

artless noise
  • 21,212
  • 6
  • 68
  • 105
1

There is nothing technically preventing Linux from running in the Secure state of an ARM processor. But it defeats the entire purpose of TrustZone. A large, complex kernel and OS such as Linux is infeasible to formally verify to the point that it can be considered "Secure".

For further reading on that aspect, see http://www.ok-labs.com/whitepapers/sample/sel4-formal-verification-of-an-os-kernel

As for the specific problem you are facing - there should be nothing special about interrupt handling in Secure vs. Non-secure state (unless you explicitly configure it to be different). But it could be that the secure OS you have removed was performing some initial timer initializations that are now not taking place.

Also 3.0.15 is an absolutely ancient kernel - it was released 2.5 years ago, based on something released over 3 years ago.

unixsmurf
  • 5,852
  • 1
  • 33
  • 40
  • 1
    This maybe splitting hairs... There is nothing wrong with Linux in the secure world; it is the default from ARM to support backwards compatibility. What maybe wrong is to run both Linux and the Trustlet in the secure world. It is technically possible to run a minimal secure Linux in the secure world with secure peripherals and another Linux in the non-secure world. Don't believe the micro-kernel hype. Most attacks with be on the API code and not the OS. Linux has far more reviewers than OKL4. It is just as easy (or easier) to write flawed application/cells in OKL4 than it is in Linux. – artless noise Sep 02 '14 at 16:10
  • Linux is also several orders of magnitude larger than OKL4 (which was linked to merely for the sake of that report - an OS cannot in itself be secure, only a system can be secure). A large code base is inherently less secure. While one could happily have Secure Linux and Non-secure linux coexisting from a plain technical standpoint, this would not help with facilitating system security. – unixsmurf Sep 02 '14 at 16:47
  • Since my clarification appears to have been unclear: I do not know much about OKL4 and I do not claim it is secure. I included a link to it only because of the report discussing the issues of formally verifying an operating system. As I said first in my answer, and then more strongly in a comment. I _am_ claiming it could be made secure before the heat/cold death of the universe. I am also claiming the same is not true for anything the size of Linux. Reducing the attack surface does not a secure system make - the most it can make it is less insecure. – unixsmurf Sep 03 '14 at 01:17
  • 1
    Maybe right [see below]. Your analysis is only of the OS. You need applications to use the OS. When the OS lacks features, they must be implemented in the applications. You have just moved the code; the OS may make implementation in application space kludgy because of limited functionality. [Below] Some sub-systems can increase security. For instance, an no-MMU OS versus a task-aware MMU OS, process rights, stack randomization, etc. These sub-systems reduce the attack surface and require privilege elevation. I only mention smaller OSs as I have used them and these are some issues I see. – artless noise Sep 03 '14 at 14:38
1

There are several issues with what you are saying that need to be cleared up. First, are you trying to get the Secure world kernel running or the Normal world kernel? You said you wanted to run Linux in the SW and Android in the NW, but your question stated, "I have tried to replace the simple secure os with the android Linux kernel". So which kernel are you having problems with?

Second, you mentioned clearing the NS-bit. This doesn't really make sense. If the NS-bit is set, clearing it requires means that you are running in the NW already (as the bit being set would indicate), you have executed a SMC instruction, switched to Monitor mode, set the NS-bit to 0, and then restored the SW registers. Is this the case?

As far as interrupts are concerned, have you properly initialized the VBAR for each execution mode, i.e. Secure world VBAR, Normal world VBAR, and MVBAR. All three will need to be setup, in addition to setting the proper values in the NSACR and others to ensure interrupts are channeled to the correct execution world and not all just handled by the SW. Also, you do need separate exception vector tables and handlers for all three modes. You might be able to get away with only one set initially, but once you partition your memory system using the TZASC, you will need separate everything.

TZ requires a lot of configuration and is not simply handled by setting/unsetting the NS-bit. For the Exynos 4412, numerous TZ control registers that must be properly set in order to execute in the NW. Unfortunately, none of the information on them is covered in the Public version of the User's Guide. You need the full version in order to get all the values and address necessary to actually run a SW and NW kernel on this processor.

engineereeyore
  • 108
  • 7