내장 하이퍼바이저

Embedded hypervisor

임베디드 하이퍼바이저는 임베디드 시스템의 요건을 지원하는 하이퍼바이저입니다.

임베디드 하이퍼바이저의 요건은 서버 및 데스크톱 애플리케이션을 대상으로 하는 하이퍼바이저와는 다릅니다.임베디드 하이퍼바이저는 디바이스 도입 후에 로드되는 것이 아니라 처음부터 임베디드 디바이스에 설계되어 있습니다.데스크톱 환경과 엔터프라이즈 환경은 하이퍼바이저를 사용하여 하드웨어를 통합하고 컴퓨팅 환경을 서로 분리하는 반면 임베디드 시스템에서는 일반적으로 다양한 컴포넌트가 함께 기능하여 디바이스의 기능을 제공합니다.모바일 가상화는 임베디드 시스템 가상화와 중복되어 몇 가지 사용 사례를 공유합니다.

임베디드 가상화의 일반적인 속성에는 효율성, 보안, 통신, 격리 및 실시간 [1]기능이 포함됩니다.

배경

소프트웨어 가상화는 1960년대 후반부터 엔터프라이즈 분야에서 주요 토픽이 되어 왔지만 2000년대 초반부터 임베디드 시스템에 사용되고 있습니다.임베디드 시스템에서 가상화를 사용하고 하이퍼바이저 형태로 구현하는 방법은 엔터프라이즈 애플리케이션과 크게 다릅니다.임베디드 하이퍼바이저를 효과적으로 구현하려면 이러한 애플리케이션에 고유한 수많은 문제를 해결해야 합니다.이러한 문제에는 임베디드 시스템의 고도로 통합된 특성, 신속한 통신을 위한 시스템 내 격리된 기능 블록의 요건, 실시간/결정론적 성능, 리소스가 제한된 타깃 환경 및 광범위한 보안 및 신뢰성 요구사항이 포함됩니다.

하이퍼바이저

하이퍼바이저는 운영체제를 포함한 다른 소프트웨어가 기반이 되는 시스템 하드웨어에 대한 풀액세스로 동작할 수 있는1개 이상의 소프트웨어 가상화 환경을 제공합니다.이 환경에서는 이러한 액세스가 하이퍼바이저의 완전한 제어 하에 있습니다.이러한 가상 환경을 VM(가상 머신)이라고 합니다.일반적으로 하이퍼바이저는 여러 VM을 동시에 관리할 수 있습니다.

분류

하이퍼바이저는 보통 타입1 또는 타입2 중 하나로 분류됩니다.하이퍼바이저는 슈퍼바이저 모드 또는 특권 모드(타입 1)에서만 실행되는지, 또는 운영체제에 의해 일반 애플리케이션(타입 2)으로 호스트되는지에 따라 달라집니다.

타입 1 하이퍼바이저는 가상 머신의 제어를 유지하는 데 필요한 주요 시스템 리소스를 관리하고 TCB(신뢰할 수 있는 컴퓨팅 기반)를 최소화합니다.타입 2 하이퍼바이저는 일반적으로 보다 범용적인 운영체제 내에서 애플리케이션으로 동작하며 OS의 서비스에 의존하여 시스템 자원을 관리합니다.오늘날 커널 확장 기능은 가상화를 지원하는 하드웨어를 활용하기 위해 로드되는 경우가 많습니다.

내장 하이퍼바이저

임베디드 하이퍼바이저는 대부분의 경우 임베디드 시스템 개발 요건을 지원하는 타입 1 하이퍼바이저입니다.자세한 내용은 참조[2][3] 및 을 참조하십시오.

이러한 요건은 아래에 요약되어 있습니다.

  • 여러 개의 분리된 VM을 지원하는 작고 빠른 하이퍼바이저
  • 강하게 상호작용하는 중입자 서브시스템 컴포넌트의 가볍지만 안전한 캡슐화 지원
  • 시스템 컴포넌트 간의 고대역폭, 저레이텐시 통신(설정 가능한 시스템 전체의 보안 정책에 따름)
  • 시스템 리소스에 대한 영향을 최소화하고 실시간 지연 보장을 지원합니다.
  • VM 간에 스케줄링 정책을 구현하고 실시간 시스템 컴포넌트를 지원하는 기능

실행

임베디드 하이퍼바이저는 일반적으로 가상 소프트웨어가 실행되는 하드웨어 플랫폼을 에뮬레이트하는 여러 VM을 제공합니다.VM은 기본 네이티브 하드웨어를 에뮬레이트할 수 있습니다.이 경우 실제 시스템에서 실행되는 내장 코드가 가상 시스템에서 실행되며 그 반대도 마찬가지입니다.네이티브 하드웨어의 에뮬레이션이 항상 가능하거나 바람직한 것은 아니며 대신 가상 플랫폼을 정의할 수 있습니다.

VM이 가상 플랫폼을 제공하는 경우 이 환경에서 실행되도록 게스트 소프트웨어를 이식해야 하지만 가상 플랫폼을 네이티브 하드웨어에 의존하지 않고 정의할 수 있으므로 가상 플랫폼을 지원하는 게스트 소프트웨어는 하이퍼바이저에서 지원되는 다양한 개별 하드웨어 플랫폼에서 변경되지 않고 실행될 수 있습니다.

임베디드 하이퍼바이저는 반가상화를 채택하거나 기본 CPU의 가상화 기능을 사용합니다. 반가상화는 하드웨어가 지원하지 않는 경우에 필요하며 게스트 커널의 핵심 아키텍처 지원 코어를 광범위하게 수정해야 하는 경우가 많습니다.내장 하이퍼바이저에서는 매우 복잡하고 속도가 느리기 때문에 레지스터 레벨에서의 하드웨어 에뮬레이션은 거의 볼 수 없습니다.임베디드 시스템의 커스텀 특성으로 인해 이러한 기술을 필요로 하는 수정되지 않은 바이너리 전용 게스트 소프트웨어를 지원할 필요가 거의 없습니다.

임베디드 시스템의 자원 제약이 데스크톱 및 서버 플랫폼보다 훨씬 크기 때문에 구현의 규모와 효율도 임베디드 하이퍼바이저의 과제입니다.또한 하이퍼바이저는 기본 하드웨어 플랫폼의 기본 속도, 실시간 응답 및 결정론과 전력 효율을 가능한 한 가깝게 유지하는 것이 바람직합니다.

하이퍼바이저 설계

임베디드 시스템 애플리케이션의 실장은 일반적으로 소규모 마이크로커널 및 분리 커널 설계에 기반하고 있으며 가상화는 필수 기능으로 내장되어 있습니다.이것은 Pike에서 도입되었습니다.2005년의 [4]OS.이러한 접근법의 예는 Open Kernel Labs(마이크로커널 뒤에 분리 커널) 및 LynuxWorks(분리 커널)와 같은 기업에 의해 작성되었습니다.Virtual Logix는 전용 VMM(Virtual Machine Monitor)을 기반으로 하는 접근방식이 더 작고 효율적이라는 입장을 취하고 있는 것으로 보입니다.이 문제는 진행 [5][6][7]중인 논쟁의 주제이다.다만, 문제의 요점은 논의의 모든 면에서 같습니다.실장 속도와 규모(특정 수준의 기능)가 매우 중요합니다.예: "...임베디드 기기용 하이퍼바이저는 실시간 대응과 자원 절약성이 있어야 합니다.

자원 요건

임베디드 시스템은 일반적으로 하드웨어의 비용 및 기술적 제약으로 인해 리소스가 크게 제한됩니다.따라서 임베디드 하이퍼바이저는 가능한 한 효율이 높은 것이 중요합니다.마이크로커널과 분리 커널 기반의 설계에 의해 작고 효율적인 하이퍼바이저가 실현됩니다.따라서 임베디드 하이퍼바이저는 구현의 효율과 제공되는 기능의 수준에 따라 보통 수십 킬로바이트에서 수백 킬로바이트의 메모리를 사용합니다.일반적으로 수메가바이트 이상의 메모리가 필요한 구현은 허용되지 않습니다.

타입 1 내장 하이퍼바이저의 소형 TCB를 통해 시스템의 안전성과 신뢰성을 [8]높일 수 있습니다.코드 검사나 시스템 테스트 등의 표준 소프트웨어 엔지니어링 기술을 사용하면 이러한 작은 코드 기반 내의 버그 수를 하이퍼바이저와 게스트 OS의 조합에 필요한 결함의 극히 일부(총 [9]100,000 ~30,000 회선)로 줄일 수 있습니다.

VM 통신

임베디드 하이퍼바이저에 필요한 가장 중요한 기능 중 하나는 프로세스 간의 실시간 통신을 지원하기 위해 필요한 안전한 메시지 전달 메커니즘입니다.임베디드 환경에서는 일반적으로 시스템에 밀접하게 연결된 태스크가 다수 존재하며, 그 중 일부는 서로 안전한 분리가 필요할 수 있습니다.가상화 환경에서는 임베디드 하이퍼바이저가 여러 VM 간에 이러한 분리를 지원하고 적용합니다.따라서 이러한 VM에서는 작업 간에 짧은 지연 시간 통신을 제공하는 메커니즘에 액세스해야 합니다.

프로세스 간 통신(IPC) 메커니즘을 사용하여 이러한 기능을 제공하고 모든 시스템 서비스를 호출할 수 있으며 원하는 수준의 VM 분리가 유지되도록 구현할 수 있습니다.또, 이러한 IPC 메카니즘은 시스템퍼포먼스에 큰 영향을 미치기 때문에,[10] 레이텐시를 최소한으로 억제하기 위해서 고도로 최적화 할 필요가 있습니다.

하드웨어 요건

임베디드 하이퍼바이저는 VM에서 소프트웨어가 분리되지 않도록 메모리 액세스를 포함한 시스템 리소스를 완전히 제어해야 합니다.따라서 하이퍼바이저는 메모리 관리 지원(일반적으로 MMU 사용)을 제공하기 위해 타깃 CPU가 필요합니다.ARM, MIPS, Power 등 많은 내장 프로세서PC는 가상화를 위한 하드웨어 지원을 추가하는 데 있어서 데스크톱 및 서버 칩 벤더를 따라왔습니다.임베디드 프로세서의 상당수는 아직 지원되고 있지 않기 때문에 반가상화를 지원하는 하이퍼바이저가 필요합니다.

ARM 프로세서는 대부분의 애플리케이션 클래스 프로세서 설계에서 ARM Trust Zone이라는 기술을 지원한다는 점에서 주목할 만합니다.이 테크놀로지는 기본적으로 하나의 특권 VM과 하나의 특권 VM에 대한 하드웨어 지원을 제공합니다.보통 최소한의 TE(Trusted Execution Environment) OS는 Secure World에서 실행되고 네이티브 커널은 Non-Secure World에서 실행됩니다.

사용 사례

임베디드 하이퍼바이저의 가장 일반적인 사용 사례는 다음과 같습니다.[11][12]

1. OS의 독립성


임베디드 시스템의 설계자는 대상 플랫폼에 고유한 하드웨어 드라이버와 시스템 서비스를 다수 보유할 수 있습니다.플랫폼에서 여러 OS가 동시에 또는 연속적으로 공통 하드웨어 설계를 사용하여 지원되어야 하는 경우 임베디드 하이퍼바이저를 통해 작업을 대폭 간소화할 수 있습니다.이러한 드라이버와 시스템 서비스는 가상화 환경에 한 번만 구현할 수 있습니다.이러한 서비스는 모든 호스트 OS에서 이용할 수 있습니다.또, 이 추상화 레벨에 의해, 임베디드 개발자는 호스트 OS에 명확하게 표시되지 않고, 하드웨어 또는 소프트웨어에서 드라이버 또는 서비스를 언제라도 실장 또는 변경할 수 있습니다.

2. 1개의 프로세서로 여러 운영체제 지원

통상, 이것은, 저레벨의 리얼 타임 기능(통신 스택등)을 실현하기 위해서 리얼 타임 operating system(RTOS)을 실행하는 것과 동시에, Linux나 Windows등의 범용 OS(GPOS)를 실행하고, Web 브라우저나 캘린더등의 유저 애플리케이션을 서포트하기 위해서 사용됩니다.목적은 세컨드 프로세서의 복잡성을 늘리지 않고 기존 설계를 업그레이드하거나 단순히 BOM(Bill of Materials)을 최소화하는 것입니다.

3. 시스템 보안

임베디드 하이퍼바이저는 개발자가 정의한 서브시스템에 안전한 캡슐화를 제공할 수 있기 때문에 서브시스템이 다른 서브시스템에 간섭하지 않습니다.예를 들어 암호화 서브시스템은 암호화로 보호되어야 할 정보가 유출되지 않도록 공격으로부터 강력하게 보호되어야 합니다.임베디드 하이퍼바이저는 VM 내의 서브시스템을 캡슐화할 수 있기 때문에 그 서브시스템과의 통신에 필요한 보안 정책을 적용할 수 있습니다.

4. 시스템의 신뢰성

서브시스템 컴포넌트를 VM에 캡슐화함으로써 서브시스템 장애가 다른 서브시스템에 영향을 주지 않도록 합니다.이 캡슐화는 장애가 VM의 서브시스템에서 다른 VM의 서브시스템으로 전파되는 것을 방지하여 신뢰성을 향상시킵니다.이것에 의해, 장애 검출시에 서브 시스템이 자동적으로 셧다운 해 재기동할 수도 있습니다.이것은 특히 임베디드 디바이스 드라이버에 있어서 중요합니다.이곳은 가장 높은 밀도의 장애 상태가 발생하는 장소이기 때문에 OS 장애나 시스템 불안정성의 가장 일반적인 원인이 됩니다.또한 새로운 시스템 설계에 필요한 신뢰성 표준에 따라 구축되지 않은 운영 체제를 캡슐화할 수도 있습니다.

5. 시스템 소프트웨어의 동적 업데이트

실행 중인 시스템에서 "실행"하기 전에 안전한 VM에 다운로드하여 서브시스템 소프트웨어 또는 애플리케이션을 안전하게 업데이트하고 무결성을 테스트할 수 있습니다.이 프로세스가 실패해도 시스템은 시스템 동작을 중단하지 않고 원래 소프트웨어 서브시스템/애플리케이션을 재시작하여 이전 상태로 되돌릴 수 있습니다.

6. 레거시 코드 재사용

가상화를 통해 기존 임베디드 코드를 개발 및 검증한 OS 환경에서 사용할 수 있습니다.또한 개발자는 새로운 서비스와 애플리케이션을 위해 별도의 VM에서 다른 OS 환경을 사용할 수 있습니다.특정 시스템 구성용으로 작성된 레거시 임베디드 코드는 메모리, I/O 및 프로세서의 모든 시스템 리소스를 독점적으로 제어합니다.이 코드 베이스는 VM을 사용하여 I/O 및 메모리의 대체 시스템 구성에서 변경되지 않고 재사용할 수 있습니다.이것에 의해, 원래의 시스템 구성과 일치하는 자원 맵과 기능을 표시할 수 있기 때문에, 레거시 코드를 새로운 하드웨어 설계 또는 변경된 하드웨어 설계와 효과적으로 결합할 수 있습니다.

운영체제 소스 코드에 액세스할 수 있는 경우 반가상화는 일반적으로 하드웨어 가상화를 지원하지 않고 프로세서에서 OS를 가상화하기 위해 사용됩니다.따라서 OS에서 지원되는 애플리케이션도 수정되지 않고 새로운 하드웨어 플랫폼 설계로 재컴파일되지 않고 실행될 수 있습니다.

소스 액세스가 없어도 AMD-V, 인텔 VT 테크놀로지, 최신 ARM 프로세서 [13]등 하드웨어 가상화를 지원하는 프로세서에서 실행되는 시스템에서 레거시 바이너리 코드를 실행할 수 있습니다.레거시 바이너리 코드는 시스템 하드웨어가 동등한 기능을 제공하는 경우 내장 하이퍼바이저에 의해 처리되는 모든 리소스 매핑을 통해 VM에서 완전히 변경되지 않고 실행될 수 있습니다.

7. IP 보호

OEM 고객 등에 의한 추가 개발 작업을 위해 임베디드 플랫폼을 출하할 때 귀중한 독자 IP를 도난이나 오용으로부터 보호해야 할 수 있습니다.임베디드 하이퍼바이저를 사용하면 다른 시스템 소프트웨어 컴포넌트의 접근을 보호해야 하는 IP를 포함하는 시스템의 특정 부분으로 제한할 수 있습니다.

8. 소프트웨어 라이선스의 분리

하나의 라이선스 방식으로 동작하는 소프트웨어 IP와 다른 방식으로 동작하는 다른 소프트웨어 IP를 분리할 수 있습니다.예를 들어 임베디드 하이퍼바이저는 [14]GPL의 대상이 되는 오픈소스 소프트웨어와 프로세서를 공유하는 전용 소프트웨어를 위한 격리된 실행 환경을 제공할 수 있습니다.

9. 유니코어 시스템에서 멀티코어 시스템으로 애플리케이션 이행

새로운 프로세서가 멀티코어 아키텍처를 사용하여 성능을 향상시키므로 임베디드 하이퍼바이저는 새로운 멀티프로세서 시스템 설계를 효율적으로 사용하면서 기본 아키텍처를 관리하고 기존 애플리케이션과 운영 체제에 단일 프로세서 환경을 제공할 수 있습니다.이와 같이 하드웨어 환경을 변경해도 기존 소프트웨어를 변경할 필요가 없습니다.

시판 제품

  • 스타랩사의 크루시블[15]
  • 크로스 OS 하이퍼바이저 - MapuSoft Technologies, Inc.의 단일 OS 플랫폼에서 애플리케이션을 네이티브로 실행할 수 있습니다.
  • OKL4 하이퍼바이저 - ARM 기반의 스마트 커넥티드 디바이스(임베디드, 모바일)를 지원합니다.방어 및 보안에 민감한 애플리케이션에 사용됩니다.톱니바퀴 시스템에 의해 상업적으로 지원되고 있습니다.

레퍼런스

  1. ^ [1] 임베디드 시스템용 가상화
  2. ^ [2] 임베디드 시스템에서의 가상화 역할
  3. ^ [3] Wayback Machine Virtualization에서 2008-10년 아카이브 완료 및 하이퍼바이저로 임베디드 설계 지원
  4. ^ [4] 임베디드 시스템 설계 재창조 5년
  5. ^ [5] 소규모 커널과 가상 머신 모니터 비교
  6. ^ [6] 가상 머신 모니터는 올바르게 완료되었습니까?
  7. ^ [7] Wayback Machine에서 아카이브된 2008-05-11 (응답 대상)가상 머신 모니터의 Microkernel은 올바르게 이루어지고 있습니까?
  8. ^ [8] 시스템은 안전합니까?
  9. ^ [9] 신뢰성 높은 컴퓨팅 시스템
  10. ^ [10] 커널 설계에 의한 IPC 개선
  11. ^ Heiser, Gernot (27 November 2007). Virtualization for Embedded Systems (PDF) (Technical report). pp. 10–16.
  12. ^ Strobl, Marius (2013). Virtualization for Reliable Embedded Systems. Munich: GRIN Publishing GmbH. pp. 11–17. ISBN 978-3-656-49071-5.
  13. ^ [11] 2013-05-03년 Wayback Machine ARM 가상화 확장에서 아카이브
  14. ^ [12] GPL FAQ
  15. ^ Crucible - 안전한 임베디드 가상화