ARM Security Technology Building a Secure System using ...

More documents

Recommendations

Info

TrustZone Hardware Architecture IRQ Normal world User Supervisor FIQ IRQ Undef Abort System Figure 3-3 : One possible IRQ routing in a design with IRQ configured as a non-secure interrupt To prevent malicious Normal world software masking sensitive Secure world interrupts the processor hardware includes a configuration register in CP15 which can be used to prevent any Normal world software modifying the F (FIQ mask) and A (external abort mask) bits in the CPSR. This control register can only be accessed by Secure world software. Note that there is no option to prevent the Normal world masking IRQ interrupts. Processor exception vector tables Monitor Secure world To provide the exception behavior described above, a TrustZone-enabled processor implements three sets of exception vector tables. One of these tables is for the Normal world, one is for the Secure world, and the other is for Monitor mode. The base address of the Secure world table at reset is in accordance with the setting of the VINITHI processor input signal; 0x00000000 if it is not asserted, 0xFFFF0000 if it is. The base address of the other tables is undefined, and should be set by software before use. Unlike previous generations of ARM processors, the location of each of the tables can be moved at run-time. This is achieved by programming the appropriate Vector Base Address Register (VBAR) in CP15. 3-12 Copyright © 2005-2009 ARM Limited. All rights reserved. PRD29-GENC-009492C Non-Confidential Unrestricted Access IRQ IRQ User Supervisor FIQ IRQ Undef Abort System
3.3.4 Secure processor configuration TrustZone Hardware Architecture Note The use of High vectors can be enabled or disabled at run-time by setting the V bit in the CP15 Control Register. If the V bit is set processor exceptions are always taken from a table starting at 0xFFFF0000, regardless of the value stored in the VBAR. The value of the V bit is banked, enabling independent configuration of the Secure world and the Normal world vector tables. The V-bit only applies to the respective Secure world and the Normal world exception tables; the Monitor exception table is always located at the memory address specified in Monitor Vector Base Address Register. To enable independent execution of code on the virtual CPUs, the hardware strictly manages the configuration options present in CP15. The configuration options that are considered sensitive, or that apply globally to the core, can only be written by Secure world software, although most can be read by Normal world software. Settings that are not globally sensitive, and as such can be applied locally in each world, are normally banked in the hardware. This gives each world independent control over the settings that would impact their implementation. Some of the global configuration options which only the Secure world can modify have some impact on the Normal world implementation, in particular in relation to access to some of the low-level hardware features such as cache lockdown or system coprocessors. However, legacy software typically requires minimal or no changes to execute in the Normal world. 3.3.5 Multiprocessor systems with the Security Extensions The ARM architecture includes support for multiprocessor designs with between one and four processors in a cluster. The processors in the cluster can be configured to execute either in Symmetric Multi-Processing (SMP) mode, or in Asymmetric Multi-Processing (AMP) mode. When a processor is executing in SMP mode the cluster’s Snoop Control Unit (SCU) will transparently keep data which is shared across the SMP processors coherent 1 in the L1 data cache. When a processor is executing in AMP mode the executing software must manually maintain memory coherency if it is needed. 1. Only a subset of the memory types supported by the MMU are kept coherent by the SCU. Refer to the appropriate processor Technical Reference Manual for details. PRD29-GENC-009492C Copyright © 2005-2009 ARM Limited. All rights reserved. 3-13 Unrestricted Access Non-Confidential
Page 1 and 2: ARM Security Technology Building a
Page 3 and 4: Product Status This document is an
Page 5 and 6: Contents ARM Security Technology Pr
Page 7 and 8: Preface This preface introduces the
Page 9 and 10: Using this document This document i
Page 11 and 12: Feedback Feedback on this document
Page 13 and 14: Chapter 1 Introduction The chapter
Page 15 and 16: 1.1.2 Limitations of security solut
Page 17 and 18: Introduction ARM TrustZone technolo
Page 19 and 20: Introduction Security requirements
Page 21 and 22: 1.3.3 How are devices attacked? Int
Page 23 and 24: Remote attacker Introduction The cl
Page 25 and 26: Chapter 2 System Security The chapt
Page 27 and 28: 2.1.1 External hardware security mo
Page 29 and 30: 2.1.3 Software virtualization Syste
Page 31 and 32: 2.2 TrustZone hardware security 2.2
Page 33 and 34: Chapter 3 TrustZone Hardware Archit
Page 35 and 36: TrustZone Hardware Architecture Whe
Page 37 and 38: 3.2.3 Memory aliasing TrustZone Har
Page 39 and 40: TrustZone Hardware Architecture The
Page 41 and 42: Example TrustZone Hardware Architec
Page 43: 3.3.3 Secure interrupts TrustZone H
Page 47 and 48: TrustZone Hardware Architecture Any
Page 49 and 50: 3.4 Debug architecture 3.4.1 Proces
Page 51 and 52: TrustZone Hardware Architecture If
Page 53 and 54: Chapter 4 TrustZone Hardware Librar
Page 55 and 56: TrustZone Hardware Library These br
Page 57 and 58: 4.1.3 PrimeCell DMA Controller - PL
Page 59 and 60: TrustZone Hardware Library general
Page 61 and 62: Interesting features related to Tru
Page 63 and 64: 4.3 Reuse of AMBA2 AHB IP 4.3.1 Reu
Page 65 and 66: Chapter 5 TrustZone Software Archit
Page 67 and 68: Secure operating system TrustZone S
Page 69 and 70: 5.2 Booting a secure system 5.2.1 B
Page 71 and 72: Chain of trust TrustZone Software A
Page 73 and 74: 5.3 Monitor mode software 5.3.1 Con
Page 75 and 76: 5.3.3 Interrupt latency impact Trus
Page 77 and 78: 5.4 Secure software and multiproces
Page 79 and 80: TrustZone Software Architecture Not
Page 81 and 82: 5.5.1 API availability TrustZone So
Page 83 and 84: Chapter 6 TrustZone System Design T
Page 85 and 86: 6.2 Example use cases 6.2.1 Content
Page 87 and 88: 6.2.2 Mobile Payment TrustZone Syst
Page 89 and 90: Assets TrustZone System Design The
Page 91 and 92: 6.3 Gadget2008 specification 6.3.1
Page 93 and 94: TrustZone System Design is a return
Page 95 and 96:
Memory requirements 6.3.3 Mobile pa
Page 97 and 98:
Modem Cortex-R4 DMA (PL330) TZASC (
Page 99 and 100:
Chapter 7 Design Checklists The cha
Page 101 and 102:
7.2 Hardware design checklist Desig
Page 103 and 104:
7.3 Software design checklist 7.3.1
Page 105 and 106:
Glossary The items in this glossary
Page 107 and 108:
(2) The trusted virtual processor i
show all

ARM Security Technology Building a Secure System using ...

Create successful ePaper yourself

Delete template?

Save as template?