5

I read document like this TrustZone Security Whitepaper.

It describles that all resources like CPU, memory and others are divided by Secure World and Normal World. Programs in Normal World can not access resources in Secure World. You must call a special instrustion SMC to switch from Normal to Secure world (go through Monitor Mode).

As I know, modern OS like Linux provides Kernel Mode and User Mode. User processes can not access resources located in kernel space, but invoke system calls.

I also know x86's Ring0/1/2/3 can protect resources from invalid access from lower privilege level processes.

My question is what is the difference between ARM TrustZone's Secure/Normal World and kernel/user mode. Or what is the difference between TrustZone and x86's ring0/1/2/3?

Thanks

Edit Question: Replace Protected Mode with Ring0/1/2/3 in my question.

Thanks for your help. I spent some time to understand and read more documents. Summary, TZ provides insulation of resources by NS bit flags on bus, peripheral, and CPU.

KyL
  • 987
  • 12
  • 24
  • Sounds like they decided to make up some terms for stuff we already named decades ago – Jonathon Reinhart Dec 08 '14 at 14:24
  • Could be another word for a hypervisor mode but I can't confirm this. From a brief look, it looks like it's designed to prevent a total compromise of the system at the hardware level even if a kernel level vulnerability is exploited. – tangrs Dec 08 '14 at 14:49
  • I would say this is a duplicate, but I have answered anyways. Please take a look through the tag [tag:trust-zone] as I think there is lots of good information there. – artless noise Dec 08 '14 at 18:07
  • TrustZone is not about the CPU! So Ring 0/1/2/3 nor protected/real modes compare. It is about protecting the BUS. The CPU has a controlled mechanism to appear as either a *secure* or *normal* master; the monitor mode you cite is that controlled mechanism. A bus maybe composed of many different CPUs. In heterogeneous situations, the TrustZone mechanism can protect things, even when some devices (other CPUs) are not TrustZone aware. – artless noise Dec 09 '14 at 19:59
  • @artlessnoise I get your point. Though bus access has been controlled, how to ensure that the "Secure OS" is secure rather than malicious kernel? It is achieved by secure boot or any other techniques? Thanks. – KyL Dec 11 '14 at 02:20
  • Yes; my statements are a little strong. Of course a Cortex-A is involved in 'TrustZone', but ultimately it is whether the 'NS' bit is asserted on the bus. All TrustZone CPUs boot in the secure world. The boot code must configure and 'lock down' things and then start the normal world. The 'secure boot' portion is outside of 'TrustZone' and it can be different for each SOC vendor. This is also a difference between ARM/Intel; The actual implementer has some flexibility in how the **complete** secure solution is implemented. Dwelch made a kind of comment about this. – artless noise Dec 11 '14 at 16:16

2 Answers2

10

You've conflated 3 totally different things here.

Kernel mode/user mode is about execution privilege: x86 uses the terminology of "rings", whereas ARM has privilege levels baked into its processor modes - you can draw a rough parallel between ring 3 and USR mode, and ring 0 and SVC mode (obviously architectural differences mean it's nowhere near that straightforward really).

Memory protection is a different concept, involving having hardware bolted to the CPU to restrict its memory and MMIO accesses to within defined mappings, or raise faults otherwise (which then enables further developments like demand-paged virtual memory). In this regard, "Protected mode" vs. "Real mode" on x86 is pretty much just the equivalent of having the MMU/MPU turned on or off. Obviously it makes plenty of sense to couple this idea with the first, to allow the notion of privileged/unprivileged memory, but the x86 architecture and its evolutionary heritage makes that coupling artificially strong - on ARM you still have all your processor modes when the MMU is off.

TrustZone, on the other hand, is about security and authentication at a whole different level - between the system vendor/operator and the user. On x86 systems you typically might have a hardware TPM for things like secure key storage or boot verification - anything the main processor can access cannot be considered secure since the user could replace any software running there (the normal execution privilege mechanism doesn't help since the user can simply switch the whole kernel for a malicious one). The point of TrustZone is hardware support throughout the whole system which enables virtualising that secure processor/memory/peripherals on top of the "normal" system, instead of needing to cram in a whole load of extra hardware for it. For example, you can simply partition off a chunk of RAM to be physically* inaccessible from the normal world, and implement a "TPM" purely as verified secure-world software which even the most privileged normal-world code cannot interfere with.

In x86-world, you should look at Intel's Trusted Execution Technology as the closest relevant thing, which addresses (given external TPM support) some of the use-cases for which TrustZone is employed in ARM SoCs. Note that it's not a direct comparison - the CPU-centric nature of TXT means it's really just a secure boot solution. TrustZone is system-wide and more of a fundamental building block - you can build a secure boot solution and/or a TPM on it, but you can also build things like end-to-end secure content paths which a CPU-centric approach simply cannot.

* note that I mean "physical" from the software point of view - i.e. it is in hardware and there is nothing software can do to get around it if it is properly implemented. TrustZone is explicitly not an actual physical security solution - it does not, and is not intended to, offer any protection against determined people taking the packaging off the chip and probing the silicon directly.

Notlikethat
  • 20,095
  • 3
  • 40
  • 77
  • To add to or to simplify. Not all arm processors that are capable of running linux have TrustZone nor have it enabled, so TrustZone cant be the kernel protection magic that ARM uses. The interesting thing is ARM's marketing department is doing a good job as we keep seeing interest in this TrustZone thing... – old_timer Dec 09 '14 at 15:06
  • "The normal execution privilege mechanism doesn't help since the user can simply switch the whole kernel for a malicious one". If all software is replaceable, how to securely access "a chuck physically inaccessible RAM"? Why secure OS in TrustZone's concept is irreplaceable? – KyL Dec 11 '14 at 02:17
  • @KyL The secure and normal worlds can have totally different address maps - most systems have some ROM/SRAM for booting that only exists in the secure world, and some DRAM switchable at runtime. Typically you boot from some initial firmware in secure-only mask ROM manufactured as part of the chip - this doesn't need to be the full firmware stack, just enough to act as a root of trust which can load and verify signed/encrypted secure software images from external storage. Once the secure world is safely up and running, it drops down to the normal world and runs the untrusted bootloader/kernel. – Notlikethat Dec 11 '14 at 11:59
1

This question may already be answered in handling ARM Trust-zone.

My question is what is the difference between ARM TrustZone's Secure/Normal World and kernel/user mode. Or what is the difference between TrustZone and x86's protected mode?

The x86 feature you need to parallel is probably IOMMU. There is a DMA Attack that can side-step a hyper-visor. You may strictly control the peripherals that can be accessed via a hyper-visor. A hyper-visor can be viewed as code that lets an OS run in a lower level mode. Ie, you could run Linux in user mode and many things would function properly. The mmu sub-system needs to be re-written if there is no hardware support.

The out of the DMA attack is to use a peripheral DMA which does not have access checked by an MMU. So, the hyper-visor may allow you to change a frame buffer location. You could then point the frame-buffer to some physical memory containing a DRM key.

The difference between the IOMMU and TrustZone is the position of the protection. The wikipedia drawing does not show the bus controller. With IOMMU, the protection lays in the DMA device. With TrustZone, each DMA master and slave has access rights (like an MMU in a hypervisor). TrustZone is limited to either secure or normal. A secure peripheral can only be accessed by a secure master; a master is either a CPU or a device which does DMA.

Some boot code must configure (and possibly lock) the slave and master permissions. The protection exists in the bus controller. The ARM CPU portion of TrustZone is only whether the CPU will indicate that it is running in secure or the normal world; people read the CPU documentation and assume it is the full story when it is not.

Typically the DMA master (think Ethernet controller, USB controller, LCD controller) have a set of slave registers that the CPU configures. Then these slave registers instruct a DMA machine to do some memory activity on behalf of the CPU. If we have a normal DMA master (say Ethernet), then the peripheral register for that device should also be normal (we cannot setup a TCP/IP transfer of some DRM key). So TrustZone is a mechanism to partition the bus into a secure and normal world. The protection is really done outside the CPU. The ARM CPU support is only to allow code to dynamically switch worlds through the monitior mode.

Aside: Apparently the AMD CPU I just bought contains a Cortex-A5 with TrustZone. I think it is part of the UEFI infrastructure. I like to think of my new CPU as a Quad-Core x86 assisting the ARM ;)

Regarding x86 concepts, the Intel TXT and SGX are said to be comparable by this ASU paper, entitled TrustZone explained.

artless noise
  • 21,212
  • 6
  • 68
  • 105
  • 1
    [The ARM SMMU](http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.memory/index.html) is the parallel to the x86 IOMMU, for the same reasons: DMA remapping and virtualisation (although of course it supports TrustZone on top of that). An IOMMU itself offers no _security_ since a malicious kernel can just change its page tables - as you say it's only the notion of having a security state embedded in the bus that makes the secure memory physically inaccessible to normal world accesses from any endpoint. – Notlikethat Dec 08 '14 at 19:13
  • @Notlikethat Yes, the ARM SMMU maybe closer to the IOMMU. As per the Wikipedia page, some people contend that the IOMMU is for security (see *Memory is protected from malicious devices that are attempting DMA attacks and faulty devices* ...). Whatever; there is no analog of TrustZone for the x86. The closest thing I can think of is the IOMMU. It is only meant as a hint to the OP and not a **definition**. Sorry if I seemed to imply they are equal; I did say there are differences. – artless noise Dec 08 '14 at 19:52
  • 1
    @Notlikethat Both IOMMU and TXT/TPM are different than TrustZone. I find that the IOMMU might be the closest parallel. It is about protecting peripherals. As they are both different, the closet parallel can be the IOMMU, even though there is another ARM feature (SMMU) that is even closer to an IOMMU. – artless noise Dec 09 '14 at 19:51
  • Hmm, you're conflating TrustZone (which is strictly a CPU feature) with [TZASC](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/Cacddhga.html), which is the bit that manages secure/normal access to peripherals in a manner similar to an IOMPU. – Gilles 'SO- stop being evil' Jun 07 '15 at 18:36
  • @Gilles I am not sure where your comment was directed. TrustZone has definite ARM CPU features. However, the whitepaper from ARM describes that TrustZone includes things like the TZASC. TrustZone CPU features are useless without it. The 'NS' bit on the bus is intrinsic to TrustZone; this is the glue between the CPU and the bus to control access by the SOC designer. A TZASC is ARMs offering on how to control the BUS. The worlds in the CPU automatically set the 'NS' bit for this interfacing. – artless noise Oct 20 '17 at 16:59
  • Here is [a question on the BUS topic](https://stackoverflow.com/questions/41723268/arm-trustzone-connecting-peripherals). – artless noise Oct 20 '17 at 17:06