Security
The term security is used in the context of computer systems to cover a wide variety of features.
A secure system is one that protects assets(resources that require protecting, for example passwords, or credit card details) from a range of plausile attacks to prevent them from begin copied or damaged or made unavailable(denial of servie).
Confidentiality is a key security concern for assets such as passwords and cryptograhoc keys.
Defense against modification and proof of authenticity is vital for security software and on-chip secrets used for security. Examples of secure systems might include entry of Personl Identification Numbers(PINs) for such things as mobile payments, digital rights management, and e-Ticketing.
Security is harder to achieve in the world of open systems where a wide range of software can be downloaded onto a platform. This gives the potential for malevolent or untrusted code to tamper with the system.
ARM processors include specific hardware extensions to enable construction of secure systems.
TrustZone hardware arhitecture
The TrustZone hardware architecture aims to provide resources that enable a system designer to build secure systems. It does this through a range of components and infrastructure addtions. Low level programmers must have some awareness of the restrictions placed on the system by the TrustZone architecture, even if they are not intending to make use of the security features
In essenct, system security is achieved by dividing all of the device's hardware and software resource, so that they exust in either the Secure world for the Security subsystem, or the Normal world for everything else. System hardware ensures that no Secure world resources can be accessed from the Normal world.
시스템 하드웨어는 Secure world 리소스에 Normal world에서 액세스할 수 없도록 보장합니다. 보안적인 설계는 모든 민감한 리소스를 Secure world에 배치하고, 다양한 가능한 공격으로부터 자산을 보호할 수 있는 견고한 소프트웨어를 실행하는 것을 의미합니다.
A secure desgin places all sensitive resources in the Secure world, and has robust software running that can protect assets against a wid range of possible attacks.
The use of the term Non-Secure is used in the ARM architecture Reference Manual as a contrast to Secure state, but this does not imply that there is a security vulnerability associated with this state. We will refer to this as Normal operation here. The use of the word world is to emphasize the relationship between the Secure world and other states the device is capable of.
The additions to the architecture enable a single physical core to execute code from both the Normal world and the Secure world in a time-sliced fashion. The memory system is similarly devided. An additional bit, indicating wheteher the access is Secure or Non-secure(the NS bit) is added to all memory system transactions, including cache tags and access to system memory and peripherals. This can be considered as an addtional address bit, giving a 32-bit physical address space for the Secure world and a completly separate 32-bit physical address space for the Normal world.
모든 메모리 시스템 트랜잭션, 캐시 태그 및 시스템 메모리 및 주변장치 접근을 포함하여 액세스가 Secure인지 Non-Secure인지 나타내는 추가 비트(NS 비트)가 추가됩니다. 
As the cores execute code from the two worlds in a time-sliced fashion, context switching between them is done using an additional core mode(like the existing modes for IRQ, FIQ etc.) called Monitor mode. A limited set of mechanisms by which the core can enter Monitor mode from the Norma world is provided. Entry to monitor can be through a dedicated instruction, the Secure Monitor Call(SMC) instruction, or by hardware exception mechanisms. IRQ, FIQ and external aborts can all be configured to cause the core to switch into Monitor mode. In each case, this will appear as an exception to be dealt-with by the Monitor mode exception handler.
shows how, in many systems, FIQ is reserved for use by the secure world(it becomes, in effect, a non-maskable secure interrupt). An IRQ that occurs when in the Normal world is handled in ther Normal way, descrived in the chapters on exception handling. An FIQ that occurs while executing in the Normal world is vectored directly to Monitor mode. Monitor mode handles the transition to Secure world and transfers directly to the Secure world FIQ handler. If the FIQ occurs when in the Secure world, it is handled throught the Secure vector table and routed directly to the secure world handler. IRQs are typically disabled during execution in the Secure world.
두 개의 월드에서 코드를 번갈아가며 실행하며, 이들 간의 컨텍스트 스위칭은 모니터 모드라는 추가 코어 모드를 사용하여 수행됩니다. 모니터 모드는 IRQ, FIQ 등의 기존 모드와 마찬가지로 존재하는 모드로, 일반 월드에서 모니터 모드로 진입하는 제한된 메커니즘이 제공됩니다. 모니터 모드로 진입하는 방법으로는 특별한 명령인 Secure Monitor Call (SMC) 명령을 통해 또는 하드웨어 예외 메커니즘을 통해 진입할 수 있습니다. IRQ, FIQ, SMC, 외부 어보트는 모두 코어를 모니터 모드로 전환하도록 구성할 수 있습니다.
일반 월드에서 실행 중인 상태에서 발생하는 FIQ는 직접적으로 모니터 모드로 벡터링됩니다. 모니터 모드는 보안 월드로의 전환을 처리하고 직접적으로 보안 월드의 FIQ 핸들러로 전달합니다. 만약 FIQ가 보안 월드에서 발생하는 경우, 보안 벡터 테이블을 통해 처리되고 직접적으로 보안 월드 핸들러로 전달됩니다. 보안 월드에서 실행 중인 동안에는 일반적으로 IRQ가 비활성화됩니다.
The software handler for Monitor mode is implementation specific, but will typically save the state of the currnet world and restore the state of the world being switched to, much like a normal context switch.
일반적으로 현재 월드의 상태를 저장하고 전환될 월드의 상태를 복원하는 것과 유사한 방식으로 동작합니다. 일반적인 컨텍스트 스위치와 마찬가지로 작동합니다.The NS bit in the Secure Configuration Regsiter (SCR) in CP 15 indicates which world the core is currently in. In monitor mode, the core is always executing in the Secure world, regardless of the Value of the SCR NS-bit that is used to signal which world you were previously in . The NS-bit also enables code running in Monitor mode to snoop security banked registers, to see what is in either world.
CP15의 보안 구성 레지스터(SCR)에서 NS 비트는 코어가 현재 어느 월드에 있는지를 나타냅니다. 모니터 모드에서는 SCR의 NS 비트 값과는 상관없이 항상 보안 월드에서 실행됩니다TrustZone hardware also effectively provide two virtual MMUs, one for each virtual core. This enables each world to have a loca set of translation tables, with the Secure world mappings hidden and protected from the Norma world. The translation table descriptions niclude a NS bit that is used to determin whetehr accesses are made to the secyre or non-secure phsysical address space. ALthough the translation table enty bit is still presetm the Normal virtual core hardware does no use this field, and memory accesses are always made with NS = 1.
사실상 두 개의 가상 MMU(메모리 관리 장치)를 제공합니다. 각 월드는 로컬한 변환 테이블 집합을 가지며, 보안 월드 매핑은 일반 월드로부터 숨겨지고 보호됩니다. 변환 테이블에는 보안 또는 비보안 물리 주소 공간에 액세스하는지 여부를 결정하는 NS 비트가 포함되어 있습니It is good practice for code that modifies translation table entries and that does not care about TrustZone based security, to always set the translation table NS-bit to zero. This means that it will be equally applicable when the code is executing in the Secure or Normal worlds.
The ability to direct aborts, IRQ and FIQ directly to the monitor, enables trusted software to route the interrupt requeset accordingly, enabling a design to provide secure interrupt sources immune from manipulation by the Normal world software. Similarly, the Monitor mode routing means that from the point of view of Normal world code, an interrupt that occurs dutring Secure world execution appears to occur the last Normal world instruction that occurred before the Secure world was entered.
A typical implementation is to use FIQ for the Secure world and IRQ for the Normal world. Exceptions are configured to be taken by the currnet world ( whether Secure or Normal), or to cause an enty to the monitor. The monitor has its own vector table. Becuase of this, the core has three sets of exception vector tables. It has a table for the Normal world, one for the Secure world, and one for Monitor mode.
일반적인 구현 방식은 보안 월드에 FIQ를 사용하고 일반 월드에 IRQ를 사용하는 것입니다. Exceptions은 현재 월드(보안 또는 일반)에서 수행하거나 모니터로 진입하도록 구성됩니다. 모니터는 자체 벡터 테이블을 가지고 있습니다. 이로 인해 코어에는 세 개의 예외 벡터 테이블이 있습니다. 일반 월드용, 보안 월드용 및 모니터 모드용 테이블이 있습니다.The hardware must also provicde the illustion of two separate cores within CP15. Sensitive configuration CP15 registers can only be wriiteen by Secure world software. Other settings ar enormally banked in the hardware, or byt the Monitor mode software, so that each world sees it onw version.
중요한 설정 CP15 레지스터는 보안 월드 소프트웨어만 쓸 수 있습니다. Impelmetaions that use trustzone will typically have a light weight kernel(Trusted Execution Environment) that hosts service(for example, encryption) in the Secure world. A full OS runs in the Normal world and is able to access the secure services using the SMc instruction. In this way, the Normal world gets access to functions of the service. Without any ability to see keys or ohter protected data.
일반적으로 보안 월드에서 서비스(예: 암호화)를 호스팅하는 경량 커널(신뢰 실행 환경)을 가지고 있습니다. 완전한 운영 체제는 일반 월드에서 실행되며 SMC(instruction)를 사용하여 안전한 서비스에 액세스할 수 있습니다. 이렇게 함으로써 일반 월드는 서비스의 기능에 액세스할 수 있지만 키나 기타 보호된 데이터를 볼 수 없습니다.21.1.1 Multi core systems with security extensions
Each core in a multi core system has the programmers model features described for single cores earlier in this book. Any number of the cores in the clster can be in the Secure world at any point in time, and cores are able to transition between the worlds independently of each other. The Snoop Control Unit is aware of security settings. Addtinal registers are provide to control whether Normal world code can modify SCU settings. Similarly, the generic interrupt controller that distributes prioritized interrupts across the Multi core cluster must also be modified to be aware of security concerns.
Theoretically, the Secure world OS on an SMP system could be as complicated as te Normal world OS. However, this is undersirable when aimming forsecurity. In general, It is expected that a Secure world OS will actually only execute on one core of an SMP system (with security requesets from the other cores being routed to this chosen core). This does provide some bottleneck issues. To some extent these will be balanced by the Noraml world OS performing load balacing against the core that is will see as busy for unknown reasons. Betond that his limitation has to be seen as one of the compromises that can be reached ti hit particular target level of security.
->
일반적으로, 보안 월드 운영 체제는 실제로 SMP 시스템의 하나의 코어에서만 실행될 것으로 예상됩니다(다른 코어에서의 보안 요청이 이 선택된 코어로 라우팅됩니다).
21.1.2 Interaction of Normal and Secure worlds
If you are writing code in a system that contains some secure services, it can be useful to understand how these are used. As we have seen, a typical system will have a light-weight kernel, Trusted Execution Environment(TEE) hosting services ( for example, encryption) in the Secure world. This interacts with a full OS in ther Normal world that can access the secure services using the SMC call. In this way, the Normal world is able to have access to functions of the service, without getting to see keys(for example).
Generally applications developers won't directly interact with TrustZone(or TEEs or Trusted service). Instead, one makes use of a high level API(for example, it might be called reqPayment()) provided by a Normal world library. The libarary would be provided by the same vendor as the Trusetd Service (for example, a creid card company), and would handle the low level interactions.
Figure 21-3 shows this interaction and illustrates the flow from user application calling the API that makes an appropriate OS call, which then passes to the TrustZone driver code, and then passes execution into the TEE through the Secure monitor.
It is common to share data between the Secure and Normal worlds. For example, in the Secure world you might have a signature checker. The Normal world can request that the Secure world verifies the signature of a downloaded update. using the SMC call. The Secure world requires access to the memory used by the Normal world to store the package. The Secure world can use the NS-bit in its translation table descriptors to ensure that it used non-secure accesses to read the data. This is important because data relating to the package might already be in the caches, because of the accesses done by the Normal world. These accesses with addresses marked as non-secure. As mentioned previously the security attribute can be thought of as an additional address bit. If the core used secure access to try to read the package, it would not hit on data already in the cache.
Secure world는 Normal world가 패키지를 저장하는 데 사용하는 메모리에 액세스해야 합니다. Secure world는 번역 테이블 디스크립터의 NS 비트를 사용하여 비-보안 액세스를 사용하여 데이터를 읽는 것을 보장합니다.If you are a Normal world programmer, in general, you can ignore something happening in the Secure world, as its operation is hidden from you. One side effect is that interrupt latency can increas slightly, if an interrupt goes off in the Secure world, but this increase is small compared to the overall latncy on a typical OS.
If you do have to access a secure application, you will require a driver-like function to talk to the Secure world OS and Secure applications, but the details of creating that Secure world OS and applications are beyond the scope of this book. Those writing code for the Normal world only require the particular protoco for secure application being called.
Finally, the TrustZone System also controls availability of debug provision. Separate hardware over full JTAG devug and trace control is separately configurable for Normal and Secure software worlds, so that no information about the Secure system leaks.
