SW 개발

[OPTEE 문서번역] OPTEE Architecture - 11 Virtualization

. . . 2019. 10. 11. 17:00
반응형

개요

https://optee.readthedocs.io 문서를 구글 번역기 + 네이버번역기를 이용하여 번역하였습니다.

즉, 기계가 번역한 내용이므로 대략적인 내용은 확인가능합니다. 제대로 보시려면 원문을 보시길 권유드립니다.

글순서

11. Virtualization

OP-TEE는 실험 가상화를 지원합니다. 이것은 하나의 OP-TEE 인스턴스가 여러 가상 시스템에서 TA를 실행할 수있는 경우입니다. OP-TEE는 모든 VM 관련 상태를 격리하므로 어떤 VM도 어떤 방식 으로든 다른 VM에 영향을 줄 수 없습니다.

하이퍼 바이저 만이 OP-TEE를 호출하는 VM을 알고 있기 때문에 가상화 지원이 활성화 된 상태에서 OP-TEE는 하이퍼 바이저에 의존합니다. 또한 하이퍼 바이저는 당연히 OP-TEE에 VM 생성 및 파괴에 대해 알려야합니다. 게다가 거의 모든 경우 하이퍼 바이저는 2 단계 MMU 변환을 가능하게하므로 VM은 메모리의 실제 물리적 주소를 보지 않고 중간 물리적 주소 (IPA)로 작업합니다. 반면에 OP-TEE는 IPA를 PA로 변환 할 수 없으므로 이런 종류의 번역을 수행하는 것은 하이퍼 바이저의 책임입니다. 따라서 하이퍼 바이저에는 OP-TEE 프로토콜 내부에 대해 알고 있고이 변환을 수행 할 수있는 구성 요소가 포함되어야합니다. 우리는이 구성 요소를 "TEE 조정자"라고 부르며 현재 XEN 하이퍼 바이저 만 OP-TEE 조정자를 보유하고 있습니다.

11.1. Configuration

가상화 지원은CFG_VIRTUALIZATION 설정 옵션으로 가능합니다. 이 옵션을 사용하면 하이퍼 바이저와 호환되지 않으면 OP-TEE가 작동하지 않습니다. 이는 클라이언트로부터 표준 SMC를 받기 전에 하이퍼 바이저가 VM ID가있는OPTEE_SMC_VM_CREATED SMC를 보내야하기 때문입니다.

CFG_VIRT_GUEST_COUNT는 지원되는 최대 VM 수를 제어합니다. OP-TEE는 사용 가능한 메모리의 크기가 제한되어 있으므로이 수를 늘리면 한 VM에서 사용할 수있는 메모리 양이 줄어 듭니다. VM을 독립적으로 사용하기를 원하기 때문에 OP-TEE는 사용 가능한 메모리를 모든 VM에 균등하게 분배하므로 하나의 VM은 모든 메모리를 소비 할 수 없으며 다른 VM에 DoS를 발생시킬 수 없습니다.

11.2. Requirements for hypervisor

앞서 말했듯이 하이퍼 바이저는 가상 게스트에서 OP-TEE에 이르는 OP-TEE 및 SMC를 인식해야합니다. 다음은 호환 가능한 하이퍼 바이저가 수행해야하는 목록입니다.

  1. 새로운 OP-TEE 가능 VM이 생성되면, 하이퍼 바이저는 OPTEE에 SME의 OPTEE_SMC_VM_CREATED를 알려야합니다. a1 매개 변수는 VM id를 포함해야합니다. ID 0은 'HYP_CLNT_ID'로 정의되며 하이퍼 바이저 자체를 위해 예약되어 있습니다.
  2. OP-TEE 가능 VM이 파괴 될 때 하이퍼 바이저는 모든 VCPU를 중지해야합니다 (OPTEE에 해당 VM에 대한 활성 스레드가 없음을 보장합니다).
  3. OP-TEE에 대한 SMC는 a7 매개 변수에 VM ID가 있어야합니다. 하이퍼 바이저 나OPTEE_SMC_VM_CREATED 호출에서 전달 된 VM ID에서 호출 한 경우에는 HYP_CLNT_ID입니다.
  4. 하이퍼 바이저는 모든 SMC에 대해 IPA <-> PA 주소 변환을 수행해야합니다. 이것은a1-a6 레지스터와 인 메모리 명령 버퍼에있는 두 인수를 모두 포함합니다.
  5. 하이퍼 바이저는 VM이 ​​OP-TEE와 공유하는 메모리 페이지를 고정해야합니다. 즉, 하이퍼 바이저는 고정 된 페이지가 OP-TEE와 공유되므로 오랫동안 원래 PA에 위치해야 함을 의미합니다. 또한 공유 된 VM에 속해야합니다. 예를 들어 하이퍼 바이저는이 페이지를 스왑 아웃해서 소유권을 다른 VM으로 이전하거나 VM 주소 공간에서 맵핑을 해제하는 등의 작업을해서는 안됩니다.
  6. 당연히 하이퍼 바이저는 OP-TEE 프로토콜을 올바르게 처리해야하므로 모든 VM에서 OP-TEE와 직접 작동해야합니다.

11.3. Limitations

가상화 지원은 실험 상태이며 일부 제한 사항이 있으므로 사용자는 알아 두어야합니다.

11.3.1. Platforms support

Armv8 아키텍처 만 지원됩니다. 어려운 제한은 없지만 현재 MMU 또는 스레드 조작과 같은 Armv7 관련 코드는 가상화에 대해 전혀 모르고 있습니다. QEMU-V8 (Arm Vers 아키텍처와 함께 Arm Versatile Express를 에뮬레이트하는 qemu라고도 함)은 현재 하나의 플랫폼에서만 테스트되었습니다. 곧 Rcar Gen3에 대한 지원이 추가되어야합니다.

11.3.2. Static VMs guest count and memory allocation

현재 사용자는 최대 게스트 수를 구성해야합니다. OP-TEE는 메모리를 균등하게 분할하여 모든 VM이 같은 양의 메모리를 갖습니다. 예를 들어 TA에 6MB가 있으면CFG_VIRT_GUEST_COUNT를 3으로 설정할 수 있으며 실행중인 다른 VM이 없더라도 모든 VM이 최대 2MB를 사용할 수 있습니다. VM의 정확한 수와 역할을 알고 있지만 서버 응용 프로그램에 불편할 수있는 경우에는 포함 된 설정에 문제가 없습니다. 또한 특정 VM에 사용할 수있는 메모리 양을 구성 할 수 없습니다. 모든 VM 인스턴스는 정확히 동일한 양의 메모리를 갖습니다.

11.3.3. Sharing hardware resources and PTAs

현재 여러 VM에서 동시에 사용할 수있는 HW 만 직렬 콘솔 로깅에 사용됩니다. HW 암호화 가속기, 보안 저장 장치 (예 : 외부 플래시 저장 장치, OP-TEE에서 직접 액세스 한 장치) 및 기타 장치는 현재 지원되지 않습니다. 드라이버는 가상화 확장과 함께 사용하기 전에 가상화를 인식해야합니다.

모든 VM에는 대부분 PTA 상태가 있으므로 대부분 좋은 방법입니다. 그러나 PTA가 VM간에 공유되는 일부 글로벌 상태를 유지하려면 PTA를 적절히 작성해야합니다.

11.3.4. No compatibility with “normal” mode

CFG_VIRTUALIZATION = y으로 구축 된 OP-TEE는 하이퍼 바이저 없이는 작동하지 않습니다. 왜냐하면 표준 SMC를 실행하기 전에OPTEE_SMC_VM_CREATED를 호출해야하기 때문입니다. 가상화 된 환경과 가상화되지 않은 환경을 자주 전환하려는 경우 불편할 수 있습니다. 반면에 프로덕션 환경에서는 큰 문제가 아닙니다. 이에 대한 간단한 해결책이 만들어 질 수 있습니다. OP-TEE가 OPTEE_SMC_VM_CREATED 이전에 표준 SMC를 수신하면 암시 적으로 VM 컨텍스트를 만들고 모든 후속 호출에 사용합니다.

11.3.5. Implementation details

OP-TEE는 전체적으로 두 개의 엔티티로 나눌 수 있습니다.우리가 그들을 "nexus" 와 TEE라고 부르 자. Nexus는 SMC 처리, 메모리 관리, 스레드 생성 등과 같은 저수준 작업을 처리하는 OP-TEE의 핵심 부분입니다. TEE은 실제 작업을 수행하는 부분입니다. 요청을 처리하고, TA를로드하고, 실행합니다. 따라서 하나의 넥서스 인스턴스와 등록 된 VM 당 하나의 TEE 인스턴스 인 TEE 인스턴스가 여러 개있는 것은 당연합니다. 이것은 명시 적으로 또는 내재적으로 수행 될 수 있습니다.

명시적인 방법은 일종의 구조에서 TEE 상태를 이동하고 모든 코드를이 구조의 필드에 액세스하는 것입니다. 리눅스 커널에서struct task_struct와current와 같은 것입니다. 그런 다음 모든 VM 인스턴스에 대해 이러한 구조를 쉽게 할당 할 수 있습니다. 그러나이 방법은 기본적으로 모든 OP-TEE 코드를 다시 작성해야합니다.

함축적 인 방법은 TEE / VM 인스턴스에 대한 뱅크 된 메모리 섹션을 갖는 것입니다. 따라서 메모리 레이아웃은 다음과 같이 보일 수 있습니다.

+-------------------------------------------------+
|           Nexus: .nex_bss, .nex_data, ...       |
+-------------------------------------------------+
|                   TEE states                    |
|                                                 |
| VM1 TEE state | VM 2 TEE state | VM 3 TEE state |
| .bss, .data   | .bss, .data    | .bss, .data,   |
+-------------------------------------------------+

이 접근법은 TEE 코드를 변경할 필요가 없으며 넥서스 코드를 일부 변경해야합니다. 그래서 넥서스 주 (nex_data,.nex_bss,.nex_nozi,.nex_heap 등)가 별도의 섹션에 있고 항상 매핑된다는 생각입니다.

TEE 상태는 표준 섹션 (예 :.data,.bss,.heap 등)에 있습니다. 등록 된 모든 VM에 대해이 섹션의 개별 세트가 있으며 Nexus는 해당 VM에서 호출을 수신 한 경우에만 매핑합니다.

넥서스와 TEE는 서로 다른 힙을 가지고 있기 때문에,bget 할당자는 여러 개의 "컨텍스트"와 함께 작동하도록 확장되었습니다. malloc (),free ()와 친구들은 하나의 맥락으로 작업합니다. nex_malloc ()(그리고 다른nex_ 함수들)이 추가되었습니다. 그들은 다른 컨텍스트를 사용하므로 Nexus는 항상 OP-TEE 주소 공간에 매핑되는 별도의 힙을 사용할 수 있습니다. 가상화 지원이 비활성화되면, 모든nex_ 함수는 표준malloc ()대응을 정의하도록 정의됩니다.

런타임에 메모리 매핑을 변경하기 위해 MMU 코드에서 struct mmu_partition에 의해 정의 된 partition이라는 이름의 새로운 엔티티를 추가했습니다. 모든 페이지 테이블에 대한 정보를 보유하고 있으므로 전체 MMU 매핑을 TTBR레지스터에 한 번 쓰기 만하면됩니다.

기본 파티션이 있습니다. VM 컨텍스트가 활성화되어 있지 않을 때 MMU 상태를 유지하므로 TEE 상태가 매핑되지 않습니다. OP-TEE는OPTEE_SMC_VM_CREATED 호출을 받으면 디폴트 파티션을 새로운 파티션으로 복사 한 후 섹션을 TEE 데이터로 매핑합니다. 이것은virtualization.c의prepare_memory_map ()함수에 의해 수행됩니다.

OP-TEE가 STD 호출을 받으면 제공된 VM ID가 유효한지 확인한 다음 해당 MMU 파티션을 활성화하므로 TEE 코드가 자체 데이터에 액세스 할 수 있습니다. 이것은 기본적으로 가상화 지원이 작동하는 방식입니다.

반응형

'SW 개발'의 다른글

  • 현재글[OPTEE 문서번역] OPTEE Architecture - 11 Virtualization

관련글

댓글

티스토리툴바