- 이 글의 대부분의 내용은 `TrustZone for Armv8-A` 문서를 내가 이해한 방식으로 번역했다.
글의 내용
1. Overview
" 일반적으로, TrustZone 은 Arm A-profile architecture 에 도입된 security architecture 이며, 최초 도입 모델은 Armv6k 이다. 즉, TrustZone 은 Arm A-profile 만 지원한다는 것을 알 수 있다. 그러나, Armv8 M-archietecture 에서도 TrustZone 이 사용이 가능하다. 그러나, A 의 TrustZone 과 M 의 TrustZone 은 기능적으로 차이가 존재한다.
" Trustzone 을 설명하기전에 현재 리눅스 커널에서 사용되는 security mechanism 에 대해 알아볼 필요가 있을 것 같다. 현재 리눅스 커널에서 사용되는 security mechanism 은 크게 2 가지가 사용된다.
1. security mechanism via virtual memory - process 마다 별도의 page table 을 할당해서 자신만의 virtual address 를 갖게함으로써, processes 들을 서로 isolate 시킨다.
2. security mechanism via CPU feature - CPU 에서 지원하는 privilege level 을 이용해서 kernel spcae 와 user space 를 분리한다.
" 이미 위와 같은 security mechanism 이 존재하는데, 왜 Arm A-profile 에서 TrustZone 을 도입했을까? 이 글을 끝까지 아주 꼼꼼히 읽으면 알 수 있을것이다.
2. Trustzone
" ARM의 Trustzone 은 핵심 개념은 `partition` 이다. 아래 그림에서 볼 수 있다시피, secure mode / normal mode 에서의 접근할 수 있는 하드웨어의 영역이 서로 다르다. 아래 그림에서는 normal mode 에서는 GPIO, UART 에 아예 접근하지 못하게 나와있지만, 이건 상황에 따라 다르다. 예를 들어, normal mode 에서 특정 GPIO 들은 사용할 수 있지만, system 과 깊게 연관된 GPIO(secure world 에 속한 GPIO) 는 사용하지 못할 수 있다. RAM, Cache 모두 processor 의 현재 secure mode 에 따라 접근할 수 있는 영역이 다르다. 이렇게 ARM Trustzone 의 핵심은 `partitioning all of the System on Chip (SoC)’s hardware and software` 이라고 볼 수 있다. 아래 그림에서 왼쪽 빨간색 영역은 아무 놈이나 access 해도 된다는 것이다. 그러나, 오른쪽의 녹색 영역은 secure access 만 허용된다.
As mentioned previously, TrustZone [4] is an optional hardware security extension of the ARM processor architecture, which includes bus fabric and system peripherals. The security of TrustZone is based on the idea of partitioning all of the System on Chip (SoC)’s hardware and software into two worlds: secure world and normal world.
- 참고 : https://sefcom.asu.edu/publications/trustzone-explained-cic2016.pdf
" TrustZone 은 반드시 하드웨어적인 지원이 필요한 기술이다. 그리고, 보안성을 위해서 on-chip level 에서 동작하는 기술이다. arm on-chip 하드웨어라면, AMBA 가 생각나야 한다. 그렇다. AMBA 에 TrustZone 관련 line 을 추가하고, TrustZone 에서 제공하는 기능을 support & compatible 해줄 수 있는 여러 components(TZASC, TZMA, TZPC 등) 들을 추가했다.
" TrustZone 은 hardware 와 software 를 아우르는 system global 하게 적용되는 개념이다. 즉, hardware & software 할 것 없이 system 에 존재하는 모든 components 는 TrustZone 에 영향을 받게 된다. 이 글에서는 TrustZone 이 적용되는 대상을 크게 3 개로 나눴다.
1. Hardware - Processor & System 2. Software
" 이 섹션에서는 제일 먼저 processor 내에서 적용되는 TrsutZone 에 대해서 알아본다. processor 에 적용되는 TrustZone 은 주로 memory system 과 큰 연관을 가지고 있다.
3.1 Security states
" arm architecture 에서는 2 개의 security states 가 존재한다. 이 security states 들은 각각 trusted 와 normal world 에 mapping 된다.
1. secure : trusted world 2. non-secure : normal world
" EL0, EL1 or EL2 에서 processor 는 secure or non-secure state 에 있게 된다. 그리고, 이 security states 들은 `SCR_EL3.NS` 비트에 의해서 결정된다. arm 문서를 보면 다음과 같은 내용들을 자주 볼 수 있을 것이다.
1. NS.EL1 : non-secure state & exception level 1 2. S.EL1 : secure state & exception level 1
" 말 그대로 NS.EL1 은 `exception level 1` 이면서, non-secure state 를 의미한다. 그런데, EL3 는 `SCR_EL3.NS`비트값에 관계없이 항상 secure state 를 의미한다. 아래 그림은 secuiry states 와 exception levels 간에 관계를 보여준다.
TrustZone for Armv8-A
3.2 Switching between Security states
" 만약, processor 가 NS.EL1 상태인데, S.EL1 로 switching 되어야 한다면, 어떻게 해야 할까? security state 를 변경하기 위해서는, NS->S or S->NS 관계없이, 반드시 일단 EL3 로 진입해야 한다.
TrustZone for Armv8-A
" 위 그림은 security state 로 전환되는 과정을 보여준다. 이 과정을 세분화 해보면 다음과 같다.
1. 현재보다 더 높은 exception level 로 진입하기 위해서는 반드시 exception 을 발생시켜야 한다. 이 때, EL3 로 진입시키기 위한 exception 은 2 가지가 있다.
1. FIQ 2. SMC instruction
2. 각 exception level 마다 exception vector table 이 존재한다. exception 이 발생해서 EL3 로 진입을 하면, 발생한 exception(FIQ or SMC) 에 따라 적절한 exception vector 로 분기하게 된다. 그리고, EL3 에 진입했으므로, `SCR_EL3.NS` 비트가 toggle(1->0) 된다.
3. exception 이 return 되면, EL3 에서 S.EL1 으로 제어권이 넘어간다. 참고로, 위에 block diagram 에서는 EL2 가 생략되어 있다.
" 그런데, 하나의 프로세서에 security states 가 2 개 존재한다면, security states 가 전환될 때, 이전 security state 의 context 는 어떻게 될까? 일단, 결론부터 말해 processor 는 하나이기 때문에, non-secure state context 와 secure state context 가 동시에 실행될 수 없다. 그렇다면, 새로운 states 가 시작되기전에 이전 context 는 반드시 저장해야 한다. 이 역할을 하는 것은 hardware 가 아닌, `Secure Monitor` 가 해준다(software 에 의해서 context switching 을 수행한다). 즉, secure monitor software 는 non-secure state registers 들을 저장하고, 이전 secure state registers 들을 복원하는 작업을 수행한다(반대도 마찬가지다).
TrustZone for Armv8-A
" 그렇다면, 그 유명한 secure monitor 의 정체가 뭘까? secure monitor 는 TF-A 에 포함되어 있다. 즉, firmware 라고 보는 것이 맞다.
" secure states switching 시에 모든 레지스터를 저장하는 것은 아니다. 일부 레지스터들은 security states 별로 존재하는banked registers 인 것도 존재한다. 예를 들어, `ICC_BPR1_EL1(S)` 는 GIC register 로 interrupt preemption 을 control 하기 위해서 사용한다. arm 문서에서는 `ICC_BPR1_EL1` 레지스터를 각 secure states 에 따라 구분하기 위해 다음과 같이 명시한다.
1. secure state - ICC_BPR1_EL1(S) 2. non-secure state - ICC_BPR1_EL1(NS)
3.3 Virtual address spaces
" 아래 block diagram 은 multiple virtual address spaces 을 보여준다. 예를 들어, Guest OS 가 존재하는 EL1 에서 실제 physical address space 에 access 하기 위해서는 2 번의 translation regimes 을 거쳐야 한다. 먼저, EL0/1 용 translation regime 에 하나 거친 뒤, EL2 용 translation regime 을 거쳐야 실제 physical address space 에 access 할 수 있다.
TrustZone for Armv8-A
" 또한, secure state 와 non-secure state 는 별도의 translation regimes 을 갖고 있다. 아래 block diagram 을 보자. S.EL2 가 enabled 상태에서 non-secure state 와 secure state 의 translation regimes 의 차이는 stage 2 에서 나타낸다. 그리고, Stage 1 tables 들과는 다르게, Stage 2 table 에는 NS bit 가 없다. IPA(Inter-mediate Physical Address) 를 보면, NS=0:VA 는 결국 Non-secure physical address 로 translation 되고, NS=1:VA 는 Secure physical address 로 translation 되는 것을 보여준다. 그렇다면, IPA 에서 PA 로의 translation 은 어떻게 되는 것일까? 여기서 VTTBR_EL2 레지스터가 사용된다. non-secure 는 VTTBR_EL2 를 사용하고, secue 는 VSTTBR_EL2 를 사용한다.
TrustZone for Armv8-A
" 일반적으로 address 를 명시할 때, 어떤 translation regime 을 사용하는지를 구분하기 위해 다음과 같은 접두사를 사용한다. 주의할 점은 S.EL1:0x8000 과 NS.EL1:0x8000 은 전혀 다른 virtual addresses 라는 것을 알아야 한다. processor 가 secure state 에 있을 때, NS.EL1 translation 을 사용할 수 없다. 반대도 마찬가지다.
1. NS.EL1:0x8000 - Vritual address 0x8000 in the Non-secure EL0/1 traslation regime 2. S.EL1:0x8000 - Vritual address 0x8000 in the Secure EL0/1 traslation regime
3.4. Physical address spaces
" 위에서 TrustZone 은 2 가지 secure states 를 지원한다고 했다.
1. Non-secure state : Normal world 2. Secure state : Secure world
" TrustZone 에서 processor states 를 2 가지로 구분한 이유가 뭘까? 그리고, 각 상태의 특징이 뭘까? 바로, 각 상태에 따라 accessible 한 physical address 가 달라진다. 예를 들어, non-secure state 에서는 모든 virtual addresses 는 항상 non-secure physical addresses 로 translate 된다. 이 말은 non-secure software 는 non-secure resources 들에게만 accessible 할 수 있다는 뜻이다. 아래 그림에서 볼 수 있다시피, non-secure software 는 secure physical address 에 접근이 불가능하다.
" 반면에, secure state software 는 secure & non-secure physical addres space 모두에 accessible 할 수 있다. 여기서 translation table 의 NS 비트는 virtual memory 가 어떤 physical address space 로 translate 되야 하는지를 결정한다. 여기서 주의할 점은 secure state 에서는 NS 값의 영향을 받지 않는다는 것이다(non-secure state 에서나 `NS = 1` 만 accessible 할 수 있었다). 즉, 다시 한 번 말하지만, secure state software 는 secure & non-secure physical addres space 모두에 accessible 할 수 있다.
" 가상 주소와 물리 주소를 구분할 때, 접두사로 VA 와 PA 를 사용하는 것처럼 non-secure physical address 와 secure physical address 를 구분하는데도 접두사가 사용된다. 그리고, 제일 중요한 건 계속 언급하고 있지만, secure address space 와 non-secure address spaces 는 서로 다른 address spaces 다. 아래 2 개의 주소는 서로 같은 physical address 로 명시되더라도, 프로세서에 의해서 서로 다른 주소라고 취급된다.
" EL3 로 진입하기 위해서는 특별한 TrustZone architecture 를 위해서 만든 특별한 명령어인 SMC(`Secure Monitor Call`) 명령어를 실행해야 한다. 이 명령어를 실행하면, `Secure Monitor Call Exception` 이 발생해서 EL3 로 진입할 수 있게 된다. 일반적으로 SMC 명령어는 권한이 필요한 services 를 요청할 때 사용한다. 이 때, 이 services 를 제공하는 주체는 2개가 있다.
1. EL3 에 있는 Firmware services 2. TEE 에서 제공되는 services
" SMC 명령어는 EL3 의 SMC dispatcher 에 의해서 누가 SMC 명령어를 처리할지 결정된다. 만약, EL1 에서 firmware services 을 요청했다면, EL3 에 있는 Firmware 에서 처리한다. 그러나, SMC 명령어가 TEE service 를 요청한 것이라면, Trusted OS 로 전달한다.
TrustZone for Armv8-A
" SMC request 가 Firmware services 혹은 TEE services 인지는 어떻게 알 수 있을까? 이걸 구분하려면, 다음에 나오는 2개의 specifications 을 살펴봐야 한다. SMC Calling Convention (DEN0028) 에서는 SMC 명령어와 HVC 명령어를 호출할 때, 어떻게 파라미터를 구성해야 하는지를 설명한다. PSCI 는 기본 SMC 포맷에서 어떻게 해야 Firmware function 을 호출할 수 있는지를 설명한다.
1. SMC Calling Convention (DEN0028) 2. Power State Coordination Interface (DEN0022)
" 위에 block diagram 에서는 생략되어 있지만, EL1 에서 SMC 명령어를 실행하면, EL2 의 hypervisors 에서 trap 할 수 있다. hypervisor 는 Guest OS 에게 실제 하드웨어와 동일한 virtual machine 을 제공하기 때문에 EL1 의 SMC 명령어가 EL3 의 firmware 에게 직접 전달되는 것이 효율적이지 못하고, 보안상 문제를 일으킬 수 있다.
3.8 Secure virtualization
" ARMv7-A 에서 virtualization 이 처음 소개되었을 때, non-secure state 쪽에서만 사용되던 개념이었다. 이전 섹션들에서 설명했다시피, EL3 는 `host firmware` 와 `Secure Monitor` 가 사용하는 영역이다. 그리고, Seure EL0/1 은 TEE 를 host 한다. 즉, Secure EL0 은 Trusted services, Secure EL1 은 Trsuted kernel 과 mapping 된다.
TrustZone for Armv8-A
" TrustZone 이 더 많은 상용 제품들에 채택되면서, secure state 에서도 virtualization 도입의 필요성을 느끼게 된다.
1. 일부 trusted services 들이 특정 trusted kernel 에서만 실행된다. 그리고, 특정 디바이스가 여러 서비스를 지원하려면 Trusted kernels 을 여러 개 실행해야 할 수도 있다.
2. 최소한의 권한으로 실행한다는 원칙에 따라(즉, 낮은 권한에서 실행할 수 있는 기능들은 낮은 권한에서 실행되야 한다), EL3 firmware 기능의 일부를 EL3 에서 빼낼 필요성을 느낌.
" 위 문제들의 해결책으로 ARMv8.4 에서 Secure state 에 EL2 를 추가했다. S.EL2 는 NS.EL2 와 같은 full hypervisor 보다는 Secure Partition Manager(SPM) 를 host 한다. 시스템은 SPM 을 통해서 여러 개의 partitions 들을 가질 수 있다. 그리고, 각 parittion 마다 개별적인 Trusted kernels 과 Trusted services 들이 동작할 수 있다.
TrustZone for Armv8-A
" 또한, 각 parititons 들은 개별적인 Platform firmware 를 host 함으로써, firmware service 를 제공받기 위해 EL3 code 가 실행되는 것을 줄일 수 있다. 그러나, S.EL2 는 중간에 도입된 기술인 만큼 ELx 중에서 유일하게 enabled / disabled 이 가능하다. 만약, S.EL2 가 지원된다는 전제로 enabled / disabled 하는 방법은 다음과 같다.
- SCR_EL3.EEL2 비트가 0 : S.EL2 가 disabled. - SCR_EL3.EEL2 비트가 1 : S.EL2 가 enabled.
4. System architecture
" 지금까지는 processor 위주의 TrustZone 에 대해 알아보았다. 그러나, TrustZone 은 processor 뿐만 아니라, system 전체에 영향을 미치는 기술이다. 예를 들어, 아래 그림은 TrustZone 이 지원되는 시스템 구조를 나타낸다. TrustZone 이 지원되면, 각 devices 들은 non-secure 와 secure 로 나뉘게 된다. non-secure software 는 파란색 영역들에 accessible 할 수 없다. 오직, non-secure 한, 예를 들어, GPU, Non-trusted RAM 등에만 accessible 할 수 있다.
TrustZone for Armv8-A
4.1 Slave devices: peripherals, and memories
" 이 섹션에서는 bus secure 와 bus non-secure 에 대해 다루도록 한다.
1. bus secure 란, bus 가 secure physical address space 에 access 하는 것을 의미한다. 2. bus non-secure 란, bus 가 non-secure physical address space 에 access 하는 것을 의미한다.
" 여기서 다시 한 번 강조한다. secure state software 는 위에서 언급한 2 개의 physical address space 에 모두 접근이 가능하다. 이걸 잘 생각해보면, bus access 에 대한 security 가 processor 의 secure state 와 반드시 일치하는 것은 아님을 알 수 있다. 왜냐면, secure state software 는 processor 를 기준으로 secure state 에서 동작하는 software 다. 그런데, 이 software 는 실제 physical level 에서 bus secure & bus non-secure 모두에 접근이 가능하기 때문이다(AMBA AXI 와 ACE 에서 `AxPROT[1]` 비트는 해당 address space 에 access 가 가능한지를 판별한다).
4.3 Enforcing isolation
" 때때로 TrustZone 은 `slave-enforced protection system` 이라고도 불린다. 이게 무슨뜻일까? bus master(DMA controller with SMMU, ARMv8-A processor 등) 는 slave device 에 access 하기 위해서는 자신의 security information 을 bus 에 signal 한다. 그리고, memory system 은 bus master 의 security information 을 검사해서 access 가 합법한지를 판단한다. 즉, TrustZone-enabled system 에서 master 의 현재 security information 으로 slave 에 access 할 수 있는지가 자동으로 판단되기 때문에, TrustZone 이 `slave-enforced protection system` 으로 불린다는 것이다. 그런데, memory system-based checking 을 어떻게 수행되는 것일까?
" 대부분의 최신 system architecture`s 들에서는 memory system-based checking 은 `interconnect` 에 의해서 수행된다. 예를 들어, ARM NIC-400 interconnect 는 system designers 들에게 각 slave devices 들의 security status 를 명시하도록 한다. 이 때, slave devices 들에게 명시할 수 있는 secure status 는 총 4개가 있다.
1. Secure : slave device 에게는 secure access 만 허용한다. 참고로, interconnect 는 모든 non-secure accesses 들에 대해 fault 를 생성한다.
2. Non-secure : slave device 에게는 non-secure access 만 허용한다. 참고로, interconnect 는 모든 secure accesses 들에 대해 fault 를 생성한다.
3. Boot time configurable : boot time 시점에, system initialization software 가 device 의 secure status 를 설정할 수 있다. default 는 secure 다.
4. TrustZone aware : slave deivce 에 이 상태가 설정되면, interconnect 는 모든 access 를 허용한다. interconnect 에 연결된 slave device 는 각자 자신만의 isolation mechanism 을 구현해야 한다. 아래의 block diagram 을 보자.
TrustZone for Armv8-A
" 위와 같은 구조는 2 가지 케이스에서만 적합하다고 볼 수 있다.
1. TrustZone-aware devices - 위에서는 GIC 가 여기에 속한다. 대신에 GIC 는 자체적으로 access 를 secure 와 non-secure 를 구분할 수 있는 메커니즘이 있어야 한다.
2. secure only or non-secure only devices - 위에 구조에서는 TrustZone-aware devices 들을 제외하고는 secure access 혹은 non-secure access 만 허용해야 하는 구조다.
" 모든 devices 들에게 일관성 있게 secure region & non-secure region 을 모두 제공하기 위해서는 device 보다는 memory 에 초점을 맞춰야 한다. 예를 들어, off-chip DDR 같은 경우는 사이즈가 굉장히 크다. 이 메모리를 device 별로 split 하여 해당 영역을 다시 secure & non-secure 로 partitioning 하면, 디바이스 별로 secure 와 non-secure regions 을 가질 수 있게 된다. 그런데, off-chip DDR 을 어떻게 secure & non-secue regions 으로 나눌 수 있을까? 이 때, 사용하는 것이 바로 `TrustZone Address Space Controller(TZASC)` 다.
TrustZone for Armv8-A
" TZASC 는 Memory Protection Unit(MPU) 와 유사하며, devices 들에게 할당된 address space 를 여러 개의 영역으로 나눌 수 있도록 해준다. 이 때, 나눠진 각 영역들에게 secure or non-secure 가 명시된다(뒤에서 보겠지만, GIC 에 할당된 인터럽트들은 secure interrupt 와 non-secure interrupt 로 나뉜다. 즉, 중요한 인터럽트와 덜 중요한 인터럽트는 나눈다는 개념이다). 당연한 얘기겠지만, TZASC 를 컨트롤 할 수 있는 register 에 access 하려면, secure status 에서만 허용된다. 즉, secure software 만이 memory 를 partitioning 할 수 있다는 뜻이다. TZASC 는 단순 스펙이다. 이 스펙을 실제로 구현한 모델이 TZC-400 이다(다른 모델도 있음). TZC-400 은 9개의 memory regions 을 지원한다.
" 참고로, Off-chip memory 는 on-chip memory 에 비해 상대적으로 취약하다. 즉, 상대적으로 덜 안전하다. 왜냐면, on-chip memory 같은 경우는 공장에서 양산되는 시점에 memory regions 들이 구분되서 나오기 때문에, attacker 들이 공격할 틈이없다. 그러나, off-chip memory 는 TZASC 에 의해서 memory regions 나눠지기 전까지는 attacker 들이 공격할 틈이 있다(이 외에도 TZASC 를 조작하는 방법등도 있다. 추측이지만, TF-A 가 등장한 배경중 하나에도 TZASC 를 초기화하는게 있을 것이다. `5.3 Boot and the chain of trust` 섹션에서 MTK Secure boot flow 를 보면, TF-A 가 boot ROM code 와 secondary boot loader 사이에 존재한다. 즉, U-boot 와 같은 secondary boot loader 가 off-chip DDR 을 사용하기 전에 TF-A 가 먼저 시작해서 TZASC 를 초기화해서 security 를 보장하기 위한 것 아닐까 싶다. 그리고, 두 번째로 TEE 를 최대한 빠른 시점에 구축하기 위해서 도입한 개념이라 보인다`). 그렇다면, on-chip memory 를 사용하면 되는 것 아닌가? 문제는 on-chip 구조가 일반적으로 off-chip 보다 설계적인 면에서 우연하지 못할 뿐만 아니라, 가격도 비싸고, SoC 의 사이즈가 너무 커질 우려가 있기 때문에 적절한 타협이 필요하다는 것이다.
4.4 Bus masters
" ARMv8-A Processors(Secure aware) 들이 SCP(Secure) 와 데이터를 주고 받기 위해서 어떻게 해야 할까? 혹은 ARMv8-A Processors(Secure aware) 들이 Timer(Non-secure) 와 데이터를 주고 받기 위해서는 어떻게 해야 할까? 아래 그림은 기준으로 보면, CPU`s 들과 devices 들은 `Interconnect Systems` 이라는 것을 통해 연결되어 있다. interconnect systems 는 쉽게 bus 라고 보면 될 것 같다. 그리고, 이 bus 는 arm architecture 기반으로 동작하므로, AMBA 임을 알 수 있다. 결국, AMBA 프로토콜에 맞게 데이터를 전송하면 데이터 통신을 할 수 있다. 그런데, hardware level 에서 TrustZone 이 지원되면서 bus 에 단순히 데이터만 보내는 시대는 끝이났다. 즉, AMBA 에 TrustZone 관련 pin 들이 추가되었음을 의미한다. 가장 대표적으로 AMBA APB 에 `PPROT` 핀이 추가되었다.
AMBA APB Protocol Specification
" ARM A-profile processors 들은 이미 TrustZone 에 대해 인지하고 있기 때문에, 다른 devices 들과 communication 할 때, bus 에 현재 자신의 secuiry states 에 대한 정보까지 같이 전송해야 한다. 만약, Trusted RAM 에 access 하는데, 현재 CPU 의 security status 가 non-secure 라면, access 가 불가능하다.
TrustZone for Armv8-A
" 그런데, TrustZone 을 hardware level 에 지원하게 되면서 약간의 문제가 발생한다. ARM TrustZone 은 ARM 사에 의존적인 기술이기 때문에, bus master 가 가능한 디바이스들중에(위에서 DMA controller, GPU, Display Processr)서 TrustZone 을 hardware 적으로 인식할 수 없는 경우가 대부분이다. 그래서, TrustZone 에서는 master devices 들을 크게 2가지 분류로 구분한다.
1. TrsutZone aware : ARM processor or SMMU 같은 경우는 TrustZone 을 인지할 수 있도록 설계되어 있다. 즉, 이와 같은 TrustZone aware devices 들은 bus 에 데이터를 전송할 때, 적절한 security information 을 함께 전달한다.
2. Non-TrustZone aware : ARM SoC 에 attach 되는 모든 devices 들이 TrustZone 을 인식할 수 있는 것은 아니다(legacy IP 를 재사용 하는 경우가 특히 그렇하다). 그래서, non-TrustZone-aware devices 들은 bus 에 데이터를 전송할 때, security information 을 제공하지 않거나, 항상 동일한 security information 만 제공한다.
" 그렇다면, non-TrustZone-aware masters 들이 TrustZone-enable system 에 compatible 되기 위해서는 어떤 system resource 들이 필요할까?
1. Design time tie-off : systeme designer 가 non-TrustZone-aware master 가 access 가능한 physical address space 를 hardware 적으로 고정하는 방법. 회로적으로 고정하기 때문에, 영구적으로 하나의 physical address space 에 고정된다. 심플하지만, flexible 하지도 못하다는 단점이 있다.
2. Configurable logic : non-TrustZone-aware master 앞단에 attach 되어, bus 에 데이터를 전송할 때, security information 을 추가해준다. ARM NIC-400 과 같은 일부 interconnects 에서 boot time 에 secure software 가 attached non-TrustZone-aware master 의 security information 를 설정할 수 있는 registers 들을 제공한다. 그러나, 이 방식 또한 하나의 physical address space 만 사용할 수 있지만, tie-off 보다는 flexible 한 구조를 갖는다(boot time 때 마다 physical address space 를 바꿀 수 있는 것으로 보인다).
3. SMMU : 이 방법은 위에 2개 보다 훨씬 flexible 한 방법이다. 왜냐하면, 특정 물리 주소에 고정되지 않기 때문이다. ARM SMMU 는 I/O devices 들에게 마치 MMU 와 같은 존재다. 즉, non-TrustZone-aware master(I/O device) -> SMMU 로 virtual addess 에 대한 access 를 요청하면, SMMU 는 해당 virtual address 를 physical address 로 mapping 한다. SMMU 는 virtual address 를 physical address 로 mapping 할 때, 반드시 continuous physical address 할 필요가 없다. 심지어 physical addresses 들이 scatter 되어 있을 수 도 있다. 즉, memory management 측면에서 상당히 flexible 한 구조를 갖게 된다. 이 때, access 가능 여부는 SMMU 가 가진 traslation table entry 의 NS 비트를 기준으로 판단한다.
4.5 M and R profile Arm processors
" 현재 대부분의 mobile SoC 는 A-profile, R-profile, M-profile 들이 혼합되어 있는 구조다. 예를 들어, mobile 에서 A-profile 은 mobile OS(Android) 를 실행하고, R-profile 은 cellular modem, M-profile 은 low-level system control(SCP) 을 맡고있다. 아래 diagram 은 mobile device 에 들어있는 다양한 프로세서들을 보여준다.
TrustZone for Armv8-A
" R-profile 은 two security states 를 지원하지 않는다. 이 말은 R-profile 은 non-TrustZone aware bus master 처럼 동작한다고 보면 된다. 우리는 `4.4 Bus master` 에서 non-TrustZone master 에 대해서 알아봤다. 이 친구들은 TrustZone 을 모르기 때문에, AMBA 에서 TrustZone 관련 lines 에 security information 을 제공하지 않는다. 이건 Armv8-M 전용 TrustZone 을 구현하지 않는 M-profile processors 에게도 동일하게 적용된다.
4.6 Interrupts
" GIC 는 ARM SoC system 에서 어디쯤에 위치해 있을까? arm 에서 제공하는 문서마다 위치가 조금씩 다르지만, 대부분은 processors region 안에 들어가 있는 것으로 보인다.
TrustZone for Armv8-A
" GIC 또한 TrustZone 을 지원한다. GIC 에 연결된 모든 interrupt sources(interrupt source 를 INTID 라고 부른다) 들은 아래의 그룹중 하나에 속하게 된다.
1. Group 0 : secure interrupt, FIQ 를 통해서만 signaled 된다. 2. Secure Group 1 : secure interrupt, IRQ or FIQ 를 통해서 signaled 된다. 3. Non-secure Group 1 : non-secure interrupt, IRQ or FIQ 를 통해서 signaled 된다.
" 인터럽트들에 group 을 지정하는 것은 software 적으로 GIC[D|R]_IGROUPR<n> 과 GIC[D|R]_IGRPMODR<n> 레지스터들에 특정값을 writing 함으로써 컨트롤이 가능하다. 그리고, 이 과정은 static 이 아니다. 즉, software 가 run-time 시에 인터럽트들에 group 을 지정할 수 있다. 그리고, 이 과정들은 secure state 에서만 가능하다.
" bus secure access 를 통해서만 secure interrupt 의 state 와 configuration 을 변경할 수 있다. 즉, secure interrupt 의 state 와 configuration 을 변경하려면, 반드시 bus secure access 해야 한다는 것이다. non-secure interrupt 의 state 와 configuration 를 변경하려면, non-secure bus access 와 bus secure access 모두에서 가능하다.
" 왜 2 개의 Secure Groups(Group 0 & Secure group 1) 이 필요할까? Group 0 interrupts 들은 EL3 firmware 에서 처리된다. Group 0 interrupts 들은 대개 low-level system management functions 들과 관련이 있다. EL3 에서 secure functions 들만 지원해준다고 생각했다면, ATF 및 PCSA 를 공부하지 않았다는 뜻이다. EL3 에서는 `System Control Processor(SCP)` 펌웨어가 존재한다. SCP 기능을 통해 power resources(voltage or clock) 에 access 할 수 있다.
" Secure Group 1 interrupts 들은 주로 S.EL1 or S.EL2 software 에서 제공하는 services 가 필요할 때, 사용된다. 즉, interrupt 의 group 을 설정할 때, 해당 인터럽트가 S.EL1 과 S.EL2 software 와 관련이 있다면, Secure Group 1 에 mapping 해야 한다.
GICv3 and GICv4 Software Overview
4.7 Handling Interrupts
" arm 프로세서는 IRQ 와 FIQ 라는 2 개의 interrupt exceptions 을 지원한다. interrupts 가 발생시키면, GIC 는 2 가지 조건을 고려해서 어떤 interrupt exceptions(IRQ or FIQ) 를 arm processor 에게 forwarding 할지를 결정하게 된다. 이 때, 2 가지 조건은 다음과 같다.
1. 발생한 interrupt 의 group 2. 현재 processor 의 secure state
" `4.6 Interrupts` 에서 살펴 봤다시피, interrupt groups 들은 3 개로 나뉜다.
1. Group 0 interrupt
- 현재 processor 의 secure state 에 관계없이, group 0 interrupts 들은 FIQ exception 으로 forwarding 한다.
2. Secure Group 1
1. 현재 processor 의 secure state 가 secure state 라면, secure group 1 interrupts 들은 IRQ exception 으로 forwarding 한다. 2. 현재 processor 의 secure state 가 non-secure state 라면, secure group 1 interrupts 들은 FIQ exception 으로 forwarding 한다.
3. Non-secure Group 1
1.현재 processor 의 secure state 가 secure state 라면, non-secure group 1 interrupts 들은 FIQ exception 으로 forwarding 한다. 2.현재 processor 의 secure state 가 non-secure state 라면, non-secure group 1 interrupts 들은 IRQ exception 으로 forwarding 한다.
" 위에서 Group 0 interrupts 들은 주로 EL3 firmware 에서 사용한다.
1. IRQ 는 현재 secure state 에 대응하는 Group 1 interrupt 를 의미한다. 예를 들어, processor 가 non-secure state 에서 non-secure group 1 interrupt 가 발생하면, IRQ exception 이 발생한다. processor 가 secure state 에서 secure group 1 interrupt 가 발생하면, IRQ exception 이 발생한다.
2. FIQ exception 은 EL3 에 진입해야 한다는 것을 의미한다. 이 때는, 2 가지를 구별해야 한다.
1. Group 0 interrupt 는 무조건 FIQ exception 을 발생시킨다. 즉, EL3 로 진입하게 된다. 위에서 얘기했지만, FIQ 는 low-level system control service 가 필요한 경우다.
2. processor 가 non-secure state 인데, secure group 1 interrupt 가 발생하면, Trusted service 가 필요하다는 것을 의미한다. 즉, 일단 secure state 로 변경해야 한다. 그러므로, EL3 에 진입해서 Secure Monitor 를 통해 secure state 로 switching 해야 한다. 그리고, 만약 processor 가 secure state 인데, non-secure group 1 interrupt 가 발생하면, non-secure services 가 필요하다는 것을 의미한다. 즉, 일단 non-secure state 로 변경해야 한다. 그러므로, EL3 에 진입해서 Secure Monitor 를 통해 non-secure state 로 switching 해야 한다. 아래 그림을 참고하자.
4.9 Ohter devices
" 마지막은 아래 구조에서 주황색 박스로 표시된 devices 들에 대해 설명한다(주로, secure storage 와 관련이 있다).
GICv3 and GICv4 Software Overview
1. One-time programmable memory(OPT) or fuses " 한 번 written 되면 수정이 불가능한 memory 를 의미한다. boot ROM 에 저장된 boot ROM code 같은 경우는 모든 칩에서 동일한 바이너리가 사용된다. 그러나, OTP 같은 경우는 device unique values or OEM unique values 가 저장된다. 즉, 공장에서 양신 시, 칩마다 중복되지 않는 고유한 값을 저장한다는 뜻이다.
" OTP 에 저장되는 것중 하나가 바로 `device unique private key` 다. 각 칩들이 공장에서 생산될 때, randomly generated unique key 가 OTP 에 written 된다.
" OTP 는 주로 OEM 의 public key hashes 를 저장하는 용도로 사용된다. 참고로, OTP 는 다른 메모리들에 비해 상대적으로 가격이 비싼편이다. public keys 를 저장할 때, 전체 키를 저장하는 것은 비용적으로 비싸기 때문에, 주로 public key hashes 를 저장하고 있다.
2. Non-volatile counter " NV counter 는 절대 reset 할 수 없고 증가만 하는 counter 를 의미한다. NV counters 는 `rollback attacks` 를 방어하기 위해 사용된다. 예시를 하나 들어보자. 우리가 개발한 firmware 가 하나있다. 그런데, 이 firmware 의 version 3 에 굉장히 심각한 vulnerability 가 있다고 하자. 여기에 device 가 하나 등장시키자. 이 device 에는 version 3 의 vulnerability 가 수정된 version 4 가 flashed 되어있다. attacker 는 device 를 악용하기 위해 firmware version 을 3 로 downgrade 하려고 온갖 못된 짓을 할 것이다. 이러한 공격으로부터 device 를 보호하기 위해서는 매번 firmware 가 updated 될 때 마다, count 를 증가시킨다. 그렇면, booting 시점에 NV count 와 firmware vesion 을 비교한다. 만약, 2 개의 version 이 mismatch 하다면, 공격받았다고 판단한다.
3. Trusted RAM and Trusted ROM " Trusted RAM 과 Trusted ROM 에는 반드시 on-chip secure access 만 허용된다. Trusted ROM 에는 first boot code 가 있다. 여기서 `on-chip` 과 `ROM` 은 secure 관련해서 특별한 의미를 갖는다.
1. On-chip : 접근 및 대체를 어렵게 만든다. 즉, on-chip 은 물리적으로 제품을 교체할 수 없게 만든다. 2. ROM : 수정이 불가능하다.
" 위에 내용만으로도 on-chip ROM 은 굉장히 강력한 secure device 라는 것을 알 수 있다. Trusted RAM 은 흔히 `internal SRAM` 이라고 부른다. 이것도 `on-chip` 이기 때문에, 외부에서 access 하는 것 자체가 어렵다.
4.10 Trusted Base System Architecture(TBSA)
" TBSA 는 Trusted System 을 만들기 위한 ARM 에서 제시하는 hardware guideline 이라고 보면 된다. 예를 들어, TrustZone 을 위한 NS-bit 구성, Trusted BOOT ROM, Trusted RAM 설계 가이드, OPT Fuses 설계 등에 대한 내용이 있다.
TRUSTED BASE SYSTEM ARCHITECTURE FOR Arm®v8-A
5. Software architecture
" 우리는 `3. TrustZone in the processor` 와 `4. System architecture` 섹션에서 TrustZone 이 hardware level(processor, system(memory)) 에서 제공하는 기능들에 대해 알아봤다. 이번 섹션에서는 TrustZone 의 software architecture 에 대해 알아보도록 한다.
5.1 Top-level software architecture
" 아래의 그림은 TrustZone 이 활성화된 시스템에서의 software stack 을 보여준다(TrustZone 만을 설명하기 위해서 hypervisor 관련 내용은 생략했다).
TrustZone for Armv8-A
" TEE 의 components 중에 `Trusted Kernel` 은 key management or DRM 과 같은 services 들을 secure world 에서 hosting 한다.
" user application 들은 대개 TrustZone 에 대해 인식하지 못한다. 왜냐면, 직접적으로 TEE Client API 를 사용하지 않기 때문이다. 대신에, TEE Client API 를 사용하는 library APIs 들을 자신이 사용함으로써, Trusted services 를 사용할 수 있게 된다.
" service libary 와 Trusted service 는 message queue or mail box 를 통해서 communication 한다(참고로, message queue or mail box 는 2개의 worlds 를 연결한다는 이유로 `World Shared Memory(WSM)` 이라고도 불린다). message queue or mail box 가 할당된 메모리는 service libary 와 Trusted service 모두에서 accessible 해야 하므로, 반드시 non-secure memory 에 할당되어야 한다(service library 는 non-secure state 이기 때문에 non-secure memory 만 accessible 할 수 있다).
" service libary 는 requests 를 mailbox 에 queueing 한 뒤, kernel space 에 있는 TZ driver 를 호출한다. TZ driver 는 Trusted Execution Environmet(TEE) 의 components 중에 low-level interactions 부분을 전담하고 있다. TZ driver 는 message queue(mailbox) 를 위한 memory 를 할당하고, TEE 에 생성한 message queue 를 등록한다. 이 때, 주의할 점이 있다. non-secure world 와 secure world 는 서로 다른 virtual address spaces 를 사용하고 있기 때문에, virtual addresses 를 사용해서는 통신이 불가능하다.
" TZ driver 는 SMC 명령어를 통해서 secure state 를 switching 한다. 즉, SMC 명령어를 실행하면, EL3 Secure Monitor 를 통해서 processor 의 제어권이 TEE 의 components 중에 `Trusted Kernel` 로 넘어간다. Trusted kernel 은 mailbox 에서 요청한 받은 서비스를 읽어서 처리한다.
5.1.1 Trusting the message ?
" TrustZone-enabled system 에서 software stack 을 보면, non-secure application 이 service API library 를 통해서 non-secure memory 에 위치한 messae queue 에 request 를 queueing 한다. 그런데, non-secure application 을 믿을 수 있는 걸까? TEE 는 반드시 non-secure 에서 전달된 모든 데이터는 malicious 하거나 invalid 하다는 것을 전제해야 한다. 즉, secure world 에서 non-secure world 에서 전달된 모든 requests or requestors 들에 대해 반드시 authenticating 을 진행해야 한다.
5.1.2 Scheduling
" TrustZone 을 지원하는 system 에서는 위에서 볼 수 있다싶이, 2 개의 software stacks 이 존재한다. 중요한 건, processor 가 한 시점에 동시에 2 개의 state 가 될 수 없다는 것이다. 즉, 한 시점에 딱 한 개의 state 가 되어야 한다.
1. Non-secure state 2. Secure state
" 명시적으로 EL3 firmware 를 호출할 경우(PSCI 를 사용해서 power management resources 를 요청), 일반적으로 processor 는 blocking 된다. 이 말은 EL3 firmware 에서 requested operaton 을 모두 완료해야, non-secure state 에 processor 제어권이 넘어온다는 뜻이다(그러나, EL3 firmware 를 호출하는 경우는 그렇게 많지 않다. 즉, 빈번하지 않다).
" TEE 같은 경우는 non-secure state OS scheduler 에 의해서 스케줄링된다. TEE 가 non-secure state OS scheduler 에 의해서 스케줄링 되려면, non-secure world 에서 TEE 를 대신할 수 있는 프로세스가 필요하다. 그래서, non-secure world 에 TEE 를 대신할 수 있는 daemon 을 하나 생성한다. 이 daemon 이 OS 에 의해서 scheduling 되면, TEE 가 실행된다. 구체적으로, daemon 은 SMC 명령어를 통해서 processor 제어권을 TEE 로 넘긴다. TEE 는 next scheduler tick or next interrupt 가 발생하기 전까지 계속 해당 요청을 처리하게 된다.
" 이 방식은 조금 이상해 보일 수 있다. 왜냐면, trusted software 가 실행되는 과정이 untrusted software 에 의해서 컨트롤되기 때문이다. 그러나, `5.3 OP-TEE` 에서 보겠지만, TEE 는 non-secure state 에 여러 가지 secure services 들을 제공한다. 이러한
`5.1.1 Trusting the message` 에서 언급했다시피, untrusted software 가 전달하는 메시지를 신뢰해서는 안된다.
" OP-TEE 는TrustZone 기술을 지원되는 ARM Cortex-A 에서 동작하는 TEE 다. commercial, open source 관계없이 많은 TEE 구현체들이 존재한다. 이 중에서 OP-TEE 는 Trusted Execution Environment specification 에서 명시한 모든 feature 를 지원하는 open source project 다. 아래에서 그림에서 볼 수 있다시피, TEE 라는 개념은 secure world 의 Trusted kernel 만을 의미하는게 아니다. Trusted application 을 만들 수 있게 TEE Intenal API 를 제공하고, non-secue world 가 secure world 와 통신할 수 있도록 OP-TEE driver 도 제공한다. 거기다가, non-secure applications 들이 secure resources 들을 요청할 수 있도록, TEE Client API 까지 지원하고 있다. 말 그대로 `Execution Environment` 를 제공하고 있는 것이다. 현재는 Linaro 에서 관리하고 있다.
" OP-TEE 커널은 S.EL1 에서 실행된다. 그리고, Trusted applicaions 들을 S.EL0 에 hosting 한다. Trusted applications 들은 OP-TEE 커널과 TEE Internal API 를 통해서 통신한다. TEE Internal API 는GlobalPlatoform에서 개발한 표준 API 를 의미한다. GlobalPlatform 이 개발하고 있는 TEE`s API(TEE Client API & TEE Internal API) 는 말 그대로 표준이다. 즉, 대다수의 TEE 구현체(OP-TEE, QSEE 등)들은 GlobalPlatform API 인터페이스를 기준으로 TEE 를 개발하고 있다(아래 그림에서 `Trusted Application` 이 OP-TEE component 가 아닌 이유는 OP-TEE 는 core OP-TEE OS 의 component 가 아니기 때문이다. 즉, Trusted application 은 OEM 에서 구현하고 있는 것이고, OP-TEE 는 Trusted application 이 동작할 수 있는 환경인 platform 만을 지원해준다는 뜻이다).
TrustZone for Armv8-A
" non-secure kernel space 에는 low-level OP-TEE driver 가 존재한다. 이 드라이버를 통해서 non-secure software 가 OP-TEE kernel 과 communication 을 할 수 있다(OP-TEE kernel 과 직접 통신을 하는것은 아니다. OP-TEE driver 가 EL3 firmware 를 호출하는 명령어를 warpping 하고 있기 때문에 마치 OP-TEE driver 가 OP-TEE kernel 과 직접 통신하는 것처럼 보일 뿐이다).
" non-secure user space(EL0) 에는 GlobalPlatform API 를 구현한 user-space library 가 존재한다. TEE Client API 는 Trusted application or service 들과 통신하기 위해서 사용한다. `5.1 Top-level software architecture` 섹션에서 봐서 알겠지만, user application 에서 TEE Client API 를 직접 사용하는 경우는 드물다. 대개는 service libary(위 그림에서 Service API) 에서 TEE Client API 를 사용하고, 이걸 추상화한 인터페이스를 user application 에서 제공하는 구조다.
5.2 Interacting with Non-secure virtualization [참고1 참고2 참고3]
" 지금까지는 non-secure state 에서 hypervisor 를 생략하고 설명했었다. hypervisor 를 사용하게 되면, 대부분의 VM 과 Secure world 와 통신이 hypervisor 를 통해서 이루어진다. 예를 들어, virtualized environment 에서는 `SMC` 명령어를 사용하면 2가지 서비스를 요청할 수 가 있다. firmware functions 같은 경우에는 power management 같은 기능들이 포함된다(이 때, 일반적으로 hypervisor 는 VMs 들이 직접적으로 power management 를 하는 것을 허용하지 않는다. 즉, VMs 들은 hypervisor 를 통해서 firmware functions 들을 사용하는 것을 권고한다).
1. Firmware functions 2. Trusted services
" hypervisor 는 EL1 에서 전달된 SMC 명령어를 확인해서 EL1 에서 요청하는게 firmware service(예를 들어, power management) 인지 혹은 Trusted service 인지를 판단한다. 만약, 요청이 firmware service 라면, hypervisor 는 guest virtual machine 에 맞춰서 가상으로 구현된 firmware 를 호출한다. 만약, 요청이 trusted service request 라면, EL3 로 넘길 수 있다.
TrustZone for Armv8-A
" 사실, virtualization 과 TrustZone 의 조합은 상당히 복잡하다. 이 글에서는 여기서 끝내지만, 다른 글에서는 심도있게 다루도록 한다. 참고로, 아래 글은 PSCI 요청이 들어왔을 때, hypervisor 가 하는 일들에 대해 작성되어 있다. 기본적으로, hypervisor 는 EL1 guests 들에 맞처진 PSCI 인터페이스를 구현해야 한다. 왜냐면, hypervisor 가 virtual PSCI 를 구현하지 않을 경우, EL1 guests 들이 물리적으로 실존하는 firmware(SCP) 에 CPU_ON 및 CPU_OFF 와 같은 PSCI 명령어를 실행할 수 있기 때문이다. 그리고, 만약, guest 가 EL3 에서 부팅할 경우, QEMU 는 EL3 guest code 가 PSCI 를 구현했을 것이라고 가정하는 이유는 아마, `TF-A` specification 때문일 것으로 보인다. 왜냐면, TF-A 에서 BL31 에 PSCI implementation 을 요구하고 있기 때문이다. 만약, guest 가 EL3 에서 부팅하지 않는다면, TF-A 가 필요없으므로, PSCI 도 필요없을 것으로 보인다(이건 확인이 필요하다. 왜냐면, TF-A 가 secure boot 에서만 사용될 것이라고 보이지는 않는다).
When the guest is not booting at EL3, the QEMU virt machine implements its own internal PSCI emulation. This is described in the DTB file passed to the guest, and will say that PSCI calls should be done via the SMC instruction (if the guest is starting at EL2) or the HVC instruction (if the guest is starting at EL1). Effectively, QEMU is emulating an EL3 firmware for you.
(If the guest does boot at EL3, then QEMU assumes that the EL3 guest code will be implementing PSCI; in that case it provides some simple emulated hardware that does the power on/off operation and which the EL3 guest's PSCI implementation will manipulate as part of its implementation of the CPU_ON and CPU_OFF calls. But that's not the case you're in.)
If you are running a hypervisor in your guest at EL2, then it is your hypervisor's job to implement PSCI for your EL1 guests (it's unlikely that you want to allow an EL1 guest to be able to directly shut down a CPU under your hypervisor's feet, for instance). So you want to pass your EL1 guest a different DTB that describes the view an EL1 guest has of its emulated hardware, and which says "PSCI via HVC". Then your hypervisor's HVC handling should emulate PSCI. Separately, your hypervisor's bootup code should be using the real PSCI-via-SMC to power up the secondary CPUs as part of its bootup sequence.
- 참고 : https://stackoverflow.com/questions/75210724/cpu-on-on-qemu-armv8a-using-psci-from-el2-el3
5.3 Boot and the chain of trust
" boot 는 TrustZone-enabled system 에서는 굉장히 중요한 파트다. 쉽게, verified 된 software 를 통해서만 new software 가 loading 될 수 있다는 것이다. 아래 그림을 예시로 들자면, Second stage boot code 가 verified 되었다면, TEE 와 UEFI 를 loading 할 수 있다는 것이다. 대개, 신뢰성을 검증할 때는 image 를 hashing 해서 signature 를 image header 에 저장한다. 그리고, current verified loader 가 next load image 이 signature 를 검사해서 load 할지를 결정한다. 이러한 과정을 `Chain Of Trust` 라고도 부른다. 이 섹션은 secure boot 가 아닌 TBBR 을 기준으로 boot flow 를 설명한다(Secure boot 도 specification 이 있긴하지만, 제조사마다 방식이 서로 다른 것 같아 좀 더 확인이 필요하다. 일단, secure boot 의 원조는 UEFI 이기 때문에 secure boot flow 를 정확히 알고 싶다면, UEFI specification 을 참고하도록 하자).
TrustZone for Armv8-A
" 위 그림에서 제일 먼저 실행되는 코드는 boot ROM 이다. boot ROM 같은 경우는 공장에서 양산되는 시점에 하드웨어적으로 코드가 저장되기 때문에 신뢰할 수 있다고 가정한다. 그리고, ROM 에 저장함으로써 rewritten 이 불가능하다. 거기다가, boot ROM code 를 verify 해줄 earlier stage 가 없다. 그래서, 일반적으로 boot ROM 을 Root Of Trust(RoT) 로 설정한다. boot ROM code 는 이 글에서도 알 수 있다시피, 사이즈도 작고 기능도 별로 없다. 주요 기능은 second stage boot loader 를 verify 하고 flash 에서 internal RAM 으로 load 하는 역할을 한다.
" second stage boot code 는 system initialization 을 수행한다. 이 때, off-chip DRAM 을 사용하기 위해서는 memory controller 등을 초기화한다. 또한, secure 와 non-secure 모두에서 동작할 수 있는 images 를 loading 및 verifying 해야 한다. 예를 들어, TEE 는 secure state 로 loading 하고 UEFI 와 같은 higher-level firmware 는 non-secure state 에 loading 한다. 일반적으로, ARMv-A 에서 second state boot loader 는 TF-A 가 맡고 있다.
" 아래 그림은 미디어텍의 secure boot flow 를 보여준다. TF-A(BL31) 가 TEE(OP-TEE, secure) 와 U-boot(위에서 UEFI, non-secure) 를 loading 하는 것을 볼 수 있다. 여기서 TEE 가 갖춰지면서 secure world 가 생성된다고 보면 된다(이 secure world 란 결국 secure-resources or secure-services 들에 access 하기 위해서는 secure firmware 를 통해서만 가능하다는 것을 의미한다).
" 이 섹션은 `5.3 Boot and the chain of trust` 에서 보여주는 그림과 함께 읽어야 한다. Trusted boot system 에서는 현재 실행중 인 component 가 next component 를 memory 에 load 하기 전에 반드시 authencate 를 진행하고, verified 되었다면 load 하게 된다. 이 process 는 마지막 component 까지 진행된다. 이러한 과정을 `Chain Of Trust` 라고 한다. 이 섹션에서는 verification 이 실패했을 때, 무슨 일이 일어나는지를 살펴본다(참고로, 밑에서 보여주는 세 단계는 단지 예시다. 실전에서 더 세세하게 verication 이 실패할 수 있다. 그러므로, 참고만 하도록 하자).
1. Second stage boot image - second state boot image 는 SoC 및 processor 를 초기화하는데 필요하다. 그런데, 만약 이 단계에서 verification 이 실패하면, 우리의 보드가 안전정적으로 booting 할 수 있는지 보장하지 못한다. 그리고, booting 을 성공하더라도 정상적으로 동작한다는 것을 보장할 수 가 없다. 그러므로, 이 단계에서 verification 이 실패하면, boot 를 하지 않는 것이 좋다.
2. TEE - TEE 는 key management 와 같은 services 를 제공한다. loading verification 에 실패해서 TEE 를 사용할 수 없더라도, 제한된 수준에서는 보드가 계속 동작할 수는 있다. 그러므로, TEE 가 없더라도, non-secure state software(UEFI or U-boot) 가 load 될 수 있도록 허용하는 메커니즘을 구현하고 있어야 한다.
3. Non-secure state firmware(UEFI or U-boot 등) or Rich OS image - `5.3 Boot and the chain of trust` 섹션에서 그림에서 해당 components 들은 `남색` 으로 표시되어 있다. 즉, secure-aware 로 표시된 영역이다. 반드시 secure 할 필요는 없다는 것이다. 그리고, 이름에서 알 수 있다시피, non-secure state software 는 낮은 보안 레벨에 있는 software 를 의미한다. 즉, booting 을 허용할 수는 있지만, TEE 에서 제공하는 advanced functions 들을 사용할 수는 없다. 예를 들어, TrustZone-enabled DRM 은 untrusted OS image 에서는 사용할 수 없다.
" 위에서 뭔가 좀 이상하지 않나? 아직 `UEFI - Secure Boot` 스펙을 자세히 살펴보지는 못했지만, 내가 아는 secure boot 는 verification 이 실패하면, booting 이 실패하는 것으로 끝났다. 그런데, 위에서 설명하는 내용들은 좀 신기하다. loading verification 이 실패해도 계속 booting 을 진행한다고 한다. 위에 내용은 `UEFI - Secure Boot` 을 얘기하는 것이 아니다. arm 의 `Trusted Board Boot Requirements` 스펙에서 나와있는 내용이다.
" 다시 한 번 말하지만, 위에 내용들은 단순히 예시일 뿐이다. 이걸 착각해서 실무에서 secure boot issue 가 발생했을 때, 위 예시를 기준으로 판단하면 절대 안된다.
5.5 Trusted Board Boot Requirements
" 위에서 언급했다시피, `Trusted Base System Architecture (TBSA)` 는 TrustZone 을 지원하기 위해 system designers 들에게 제공되는 guideline 이라 할 수 있다. ` Trusted Board Boot Requirements (TBBR)` 또한 TBSA 와 유사하다. 그러나, 이 guideline 은 software developers 들에게 제공되는 자료다. 즉, TBSA 를 기반으로 구축된 TrustZone-enabled system 에서 어떻게 Trusted boot flow 를 개발해야 하는지를 알려주는 자료다.
" 참고로, TBBR 은 secure on-chip firmware 의 boot process 과정만을 제시하는 스펙이다. 즉, `operating system` or `boot loader to load operating system` 가 실행되기 전까지만 설명한다. 아래 그림을 보면, `Trusted World` 의 boot process 만 설명하는 것을 볼 수 있다. `Non-Trusted World` 의 boot process 는 책임지지 않는다. 이 부분은 Non-Trusted World 영역은 `UEFI - Secure Boot` 스펙과 함께 봐야한다.
It should be noted that the implementation of the specification can also enable secure boot of the operating system, only when combined with a secure bootloader for the operating system, such as that defined by Unified Extensible Firmware Interface (UEFI) 0.
To provide a trustworthy boot process all mandatory requirements described in this document must be implemented fully.
" Trusted Firmware(TF-A) 는 `Trusted Board Boot Requirements(TBBR) Platform Design Document(PDD)` 스펙을 구현한 여러 펌웨어 집합이라고 보면된다. TF-A 는 기본적으로 ARMv8-A 를 위한 open-source 를 기반으로한 secure world 구현체다. 여기에는 Secure Monitor 도 포함된다. 거기다가, runtime service 로 PSCI 까지 구현한 펌웨어도 포함되어 있다.
TrustZone for Armv8-A
" 위에서 `ARM Trusted Firmware & SoC Specific Firmware` 가 모두 TF-A 에 포함된다. TF-A 의 components 중에 하나인 SMC dispatcher 는 non-secure world 에서 호출한 `SMC` 명령어들을 2 가지로 분류한다(secure world software 는 SMC 명령어를 호출할 필요가 없음).
1. EL3 에서 처리해야 하는 SMC 명령어 2. TEE 로 토스해야 하는 SMC 명령어
" Trusted Firmware 는 interconnect 와 같은 ARM systme IP`s 들을 컨트롤할 수 있는 인터페이스를 제공한다. SoC 제조사에서는 SoC Specific Firmware 를 컨트롤할 수 있도록 ARM 에서 제공하는 PSCI, SMCCC 등의 인터페이스를 구현해야 한다.
