AWS Firecracker VMM의 마이크로아키텍처 보안: 배경

링크 표

• 초록 및 소개
• 배경
• 위협 모델
• 폭죽의 격납 시스템 분석
• Firecracker Microvms의 마이크로아키텍처 공격 및 방어 분석
• 결론, 감사의 말, 참고자료

2. 배경

2.1 KVM

Linux 커널 기반 가상 머신(KVM)[29]은 최신 CPU에서 사용할 수 있는 Intel VT-x 또는 AMD-V와 같은 하드웨어 지원 가상화 기능의 추상화를 제공합니다. Near-Native 실행을 지원하기 위해 기존 커널 모드와 사용자 모드 외에 게스트 모드가 Linux 커널에 추가되었습니다. Linux 게스트 모드에 있는 경우 KVM은 하드웨어가 링 0 및 링 3 권한을 복제하는 하드웨어 가상화 모드로 들어가도록 합니다.[1]

KVM을 사용하면 I/O 가상화는 일반적으로 별도의 하이퍼바이저 프로세스가 필요한 이전 하이퍼바이저와 달리 VMM 또는 하이퍼바이저라고 하는 VM을 생성한 프로세스에 의해 사용자 공간에서 주로 수행됩니다[41]. KVM 하이퍼바이저는 각 VM 게스트에 게스트를 생성한 프로세스의 메모리 영역과 별개인 자체 메모리 영역을 제공합니다. 이는 커널 공간과 사용자 공간에서 생성된 게스트의 경우에도 마찬가지입니다. 각 VM은 Linux 호스트의 프로세스에 매핑되고 게스트에 할당된 각 가상 CPU는 해당 호스트 프로세스의 스레드입니다. VM의 사용자 공간 하이퍼바이저 프로세스는 권한 있는 실행이 필요할 때만 KVM에 대한 시스템 호출을 수행하여 컨텍스트 전환을 최소화하고 VM을 커널 공격 표면으로 줄입니다. 모든 종류의 애플리케이션에서 성능을 향상시키는 것 외에도 이 설계를 통해 개별 프로그램을 샌드박싱하고 동시에 많은 VM이 실행되는 클라우드 환경을 지원하는 데 특히 유용한 경량 하이퍼바이저를 개발할 수 있습니다.

2.2 서버리스 클라우드 컴퓨팅

점점 인기가 높아지고 있는 클라우드 컴퓨팅 모델은 서버리스 컴퓨팅입니다. 여기서 CSP는 사용자 코드를 실행하는 서버의 확장성과 가용성을 관리합니다. 서버리스 컴퓨팅의 구현 중 하나를 FaaS(Function-as-a-Service)라고 합니다. 이 모델에서 클라우드 사용자는 서비스 공급자의 API(애플리케이션 프로그래밍 인터페이스)를 통해 필요에 따라 호출되는 기능(따라서 "서비스로서의 기능"이라고 함)을 정의하고 CSP는 해당 서비스를 실행하는 서버에서 리소스 할당을 관리합니다. 사용자 기능(따라서 "서버리스 컴퓨팅"이라는 이름이 붙었습니다. 사용자는 서버 관리를 수행하지 않습니다.) 마찬가지로 CaaS(Container-as-a-Service) 컴퓨팅은 필요에 따라 휴대용 런타임 패키지인 컨테이너를 실행합니다. FaaS 및 CaaS의 중앙 집중식 서버 관리는 CSP와 사용자 모두에게 경제적으로 매력적입니다. CSP는 사용자의 워크로드를 원하는 대로 관리하고, 최소한의 운영 비용으로 최적화하며, 사용자가 사용한 실행 시간에 대해 비용을 지불하는 유연한 가격 책정을 구현할 수 있습니다. 사용자는 서버 인프라 설계나 관리에 대해 걱정할 필요가 없으므로 상대적으로 적고 예측 가능한 비용으로 개발 비용을 줄이고 유지 관리 비용을 CSP에 아웃소싱합니다.

2.3 MicroVM과 AWS Firecracker

FaaS 및 CaaS 제공업체는 다양한 시스템을 사용하여 실행 중인 기능과 컨테이너를 관리합니다. Docker, Podman, LXD와 같은 컨테이너 시스템은 모든 환경에서 샌드박스 애플리케이션을 패키징하고 실행할 수 있는 편리하고 가벼운 방법을 제공합니다. 그러나 보다 전통적인 형태의 클라우드 컴퓨팅에 사용되는 가상 머신에 비해 컨테이너는 격리 수준이 낮기 때문에 보안 수준도 낮습니다. 최근 몇 년 동안 주요 CSP는 추가 보안을 위해 경량 가상화로 기존 컨테이너를 지원하는 microVM을 도입했습니다. [1, 55] KVM을 통한 하드웨어 가상화의 효율성과 microVM의 경량 설계는 가상화, 컨테이너화 또는 컨테이너형 시스템의 코드가 가상화되지 않은 코드만큼 빠르게 실행될 수 있으며 기존 컨테이너와 비슷한 오버헤드로 실행될 수 있음을 의미합니다.

Firecracker[1]는 AWS에서 AWS Lambda FaaS 및 AWS Fargate CaaS 워크로드를 각각 별도의 VM에 격리하기 위해 개발한 microVM입니다. x86 또는 ARM Linux-KVM 호스트의 Linux 게스트만 지원하며 게스트 시스템에서 사용할 수 있는 제한된 수의 장치를 제공합니다. 이러한 제한으로 인해 Firecracker는 코드 베이스 크기와 실행 중인 VM에 대한 메모리 오버헤드 측면에서 매우 가벼울 뿐만 아니라 부팅이나 종료도 매우 빠릅니다. 또한 KVM을 사용하면 일부 가상화 기능이 커널 시스템 호출에 의해 처리되고 호스트 OS가 VM을 표준 프로세스로 관리하므로 Firecracker의 요구 사항이 쉬워집니다. Rust로 작성된 작은 코드 기반으로 인해 Firecracker는 이전 버전에서 보안 결함이 확인되었음에도 불구하고 매우 안전한 것으로 간주됩니다(CVE-2019-18960 참조). 흥미롭게도 Firecracker 백서에서는 마이크로아키텍처 공격이 공격자 모델의 범위에 속한다고 선언하지만[1] 게스트 및 호스트 커널에 대한 일반적인 보안 시스템 구성 권장 사항을 넘어서는 마이크로아키텍처 공격에 대한 자세한 보안 분석이나 특별 대책이 부족합니다. Firecracker 문서는 섹션 2.6.1에서 다루는 특정 대책 목록을 포함하는 시스템 보안 권장 사항[8]을 제공합니다.

2.4 멜트다운과 MDS

2018년 Meltdown[32] 공격에서는 추론적으로 액세스한 데이터를 캐시 사이드 채널로 인코딩하여 보안 경계를 넘어 유출할 수 있음을 보여주었습니다. 이로 인해 곧 Fallout[14], Rogue In-flight Data Load(RIDL)[50], TSX Asynchronous Abort(TAA)[50] 및 MDS(마이크로 아키텍처 데이터 샘플링)로 알려진 유사한 공격이 발생했습니다. 좀비로드 [46]. 이러한 공격은 모두 추측 실행을 악용하는 동일한 일반적인 패턴을 따릅니다.

(1) 피해자는 비밀 데이터를 처리하는 프로그램을 실행하고, 비밀 데이터는 캐시나 CPU 버퍼를 통과합니다.

(2) 공격자는 CPU가 비밀 데이터가 필요할 것이라고 잘못 예측하게 만드는 특별히 선택된 명령을 실행합니다. CPU는 비밀 데이터를 공격자의 지시에 전달합니다.

(3) 전달된 비밀 데이터는 공격자가 액세스 권한을 부여받은 어레이에 대한 메모리 읽기의 인덱스로 사용되어 해당 어레이의 특정 라인이 캐시되도록 합니다.

(4) CPU는 데이터 확인을 마치고 비밀 데이터가 잘못 전달되었다고 판단하여 전달하기 전의 실행 상태로 되돌리지만, 캐시의 상태는 되돌리지 않는다. (5) 공격자는 어떤 라인이 캐시되었는지 확인하기 위해 모든 어레이를 조사합니다. 해당 줄의 인덱스는 비밀 데이터의 값입니다.

원래 Meltdown 취약점은 캐시 전달을 표적으로 삼았으며 캐시에 존재하는 모든 메모리 주소에서 이러한 방식으로 데이터 추출을 허용했습니다. MDS 공격은 온코어 마이크로아키텍처의 더 작고 더 구체적인 버퍼를 대상으로 하므로 상당히 다른 방식으로 완화되는 관련이 있지만 별개의 공격 클래스를 구성합니다. Meltdown은 상대적으로 자주 업데이트되지 않고 모든 코어, 스레드 및 프로세스에서 공유되는 기본 메모리를 표적으로 삼는 반면, MDS 공격은 코어에 로컬이고(경우에 따라 스레드 간에 공유됨) 실행 중에 더 자주 업데이트되는 버퍼를 표적으로 삼는 경향이 있습니다.

2.4.1 기본 MDS 변형 . 그림 1은 Intel CPU에 대해 알려진 주요 MDS 공격 경로와 Intel 및 이를 보고한 연구원이 다양한 변종에 부여한 이름을 보여줍니다. 가장 광범위하게 Intel은 데이터가 추측적으로 전달되는 특정 버퍼를 기준으로 CPU의 MDS 취약점을 분류합니다. 이러한 버퍼는 다양한 작업에 사용되는 경향이 있기 때문입니다. RIDL MDS 취약점은 CPU의 로드 포트에서 누출되는 변종인 MLPDS(마이크로아키텍처 로드 포트 데이터 샘플링)와 CPU의 LFB에서 누출되는 변종인 MFBDS(마이크로아키텍처 채우기 버퍼 데이터 샘플링)로 분류될 수 있습니다. 같은 맥락에서 Intel은 폴아웃 취약점을 MSBDS(Microarchitectural Store Buffer Data Sampling)라고 부르는데, 이는 스토어 버퍼의 누출과 관련되기 때문입니다. VRS(벡터 레지스터 샘플링)는 저장 버퍼를 통과할 때 벡터 연산에 의해 처리되는 데이터를 대상으로 하는 MSBDS의 변형입니다. VERW 우회는 다음의 버그를 악용합니다.

오래되고 잠재적으로 비밀인 데이터를 LFB에 로드하는 MFBDS용 마이크로코드 수정 사항입니다. 누설의 기본 메커니즘은 동일하며 VERW 바이패스는 MFBDS의 특수한 경우라고 볼 수 있습니다. L1DES(L1 데이터 제거 샘플링)는 MFBDS의 또 다른 특수 사례로, L1 데이터 캐시에서 제거된 데이터가 LFB를 통과하여 MDS 공격에 취약해집니다. 특히, L1DES는 공격자가 CPU에서 비밀 데이터의 존재를 실제로 트리거할 수 있는 경우(제거하여)인 반면, 다른 MDS 공격은 비밀 데이터에 액세스하여 올바른 CPU 버퍼로 가져오는 피해자 프로세스에 직접 의존합니다.

2.4.2 메두사. Medusa [37]는 Intel이 MLPDS 변종[25]으로 분류한 MDS 공격 범주입니다. Medusa 취약점은 Intel 프로세서의 WC(쓰기-결합) 버퍼에 있는 저장소를 추론적으로 결합하는 데 사용되는 불완전한 패턴 일치 알고리즘을 악용합니다. Intel은 WC 버퍼를 로드 포트의 일부로 간주하므로 Intel은 이 취약점을 MLPDS의 사례로 분류합니다. 추측성 누출을 유발하기 위해 각각 쓰기 결합 버퍼의 서로 다른 기능을 이용하는 세 가지 알려진 Medusa 변종이 있습니다.

캐시 인덱싱: 오류가 있는 로드는 일치하는 캐시 라인 오프셋을 사용하여 이전 로드와 추론적으로 결합됩니다.

정렬되지 않은 저장-로드 전달: 잘못 정렬된 메모리 오류를 트리거하는 종속 로드가 뒤따르는 유효한 저장으로 인해 WC의 임의 데이터가 전달됩니다.

Shadow REP MOV : 오류가 있는 REP MOV 명령어와 종속 로드로 인해 다른 REP MOV의 데이터가 누출됩니다.

2.4.3 TSX 비동기 중단. 하드웨어 취약점 TSX Asynchronous Abort(TAA)[24]는 MDS 공격을 수행하기 위한 다른 추측 메커니즘을 제공합니다. 표준 MDS 공격은 표준 추측 실행을 통해 제한된 데이터에 액세스하는 반면, TAA는 TSX에서 구현한 원자 메모리 트랜잭션을 사용합니다. 예를 들어 다른 프로세스가 트랜잭션에서 사용하도록 표시된 캐시 라인을 읽거나 트랜잭션에 오류가 발생하여 원자 메모리 트랜잭션이 비동기식 중단에 직면하면 트랜잭션의 모든 작업이 트랜잭션이 시작되기 전의 아키텍처 상태로 롤백됩니다. 그러나 이 롤백 중에 이미 실행을 시작한 트랜잭션 내부 명령은 다른 MDS 공격의 (2) 및 (3) 단계와 같이 추측 실행을 계속할 수 있습니다. TAA는 TSX를 지원하는 모든 Intel 프로세서에 영향을 미치며, 다른 MDS 공격, MDS 완화 또는 TAA 관련 완화(예: TSX 비활성화)의 영향을 받지 않는 특정 최신 프로세서의 경우 TAA로부터 보호하기 위해 소프트웨어에서 구현되어야 합니다[24].

2.4.4 완화. Meltdown 및 MDS 등급 취약점은 낮은 수준의 마이크로아키텍처 작업을 이용하지만 가장 취약한 CPU의 마이크로코드 펌웨어 패치를 통해 완화할 수 있습니다.

페이지 테이블 격리. 역사적으로 커널 페이지 테이블은 사용자 수준 프로세스 페이지 테이블에 포함되어 있어 사용자 수준 프로세스가 최소한의 오버헤드로 커널에 시스템 호출을 할 수 있습니다. 페이지 테이블 격리(Gruss 등이 처음 제안한 KAISER [19])는 필요한 최소한의 커널 메모리만 사용자 페이지 테이블에 매핑하고 커널에서만 액세스할 수 있는 두 번째 페이지 테이블을 도입합니다. 사용자 프로세스가 커널 페이지 테이블에 액세스할 수 없으면 커널 메모리의 작고 특별히 선택된 부분을 제외한 모든 부분에 대한 액세스가 Meltdown 공격이 시작되는 하위 수준 캐시에 도달하기 전에 중지됩니다.

버퍼 덮어쓰기. 온코어 CPU 버퍼를 표적으로 삼는 MDS 공격에는 더 낮은 수준의 더 표적화된 방어가 필요합니다. Intel은 첫 번째 수준 데이터(L1d) 캐시(캐시 타이밍 부채널 공격의 일반적인 대상)가 플러시되거나 VERW 명령이 실행될 때 취약한 버퍼를 덮어쓰는 마이크로코드 업데이트를 도입했습니다[25]. 그런 다음 커널은 신뢰할 수 없는 프로세스로 전환할 때 버퍼 덮어쓰기를 트리거하여 MDS 공격으로부터 보호할 수 있습니다.

버퍼 덮어쓰기 완화는 소스에서 MDS 공격을 목표로 하지만 아무리 말해도 불완전합니다. 프로세스는 SMT가 활성화된 경우 동일한 코어에서 동시에 실행 중인 스레드의 공격에 취약한 상태로 유지됩니다(두 스레드 모두 활성 프로세스가 실제로 두 스레드에서 변경되지 않고 취약한 버퍼를 공유하기 때문). 또한 원래 버퍼가 마이크로코드 업데이트를 덮어쓴 직후 RIDL 팀은 이를 발견했습니다. 일부 Skylake CPU에서는 버퍼가 오래되고 잠재적으로 민감한 데이터로 덮어쓰여[50] 완화가 활성화되고 SMT가 비활성화된 경우에도 취약한 상태로 남아 있었습니다. 또 다른 프로세서는 TAA에 취약하지만 비TAA MDS 공격에는 취약하지 않으며 버퍼 덮어쓰기 마이크로코드 업데이트를 받지 않았으므로 MDS 공격을 방지하려면 TSX를 완전히 비활성화해야 합니다[20, 24].

2.5 스펙터

2018년 Jan Horn과 Paul Kocher[30]는 첫 번째 Spectre 변종을 독립적으로 보고했습니다. 그 이후로 다양한 Spectre 변종[22, 30, 31, 33]과 하위 변종[10, 13, 16, 28, 52]이 발견되었습니다. 스펙터 공격은 CPU가 구조적으로 액세스할 수 없는 메모리에 추측적으로 액세스하고 데이터를 구조 상태로 유출하도록 만듭니다. 따라서 모든 Spectre 변종은 세 가지 구성 요소로 구성됩니다[27].

첫 번째 구성 요소는 추론적으로 실행되는 Spectre 가젯입니다. 스펙터 변종은 일반적으로 그들이 이용하는 잘못된 예측의 원인에 따라 구분됩니다. 예를 들어, 조건부 직접 분기의 결과는 패턴 기록 테이블(PHT)에 의해 예측됩니다. PHT의 잘못된 예측은 로드 및 저장 명령에 대한 추측성 경계 검사 우회로 이어질 수 있습니다[13, 28, 30]. 간접 점프의 분기 대상은 BTB(분기 대상 버퍼)에 의해 예측됩니다. 공격자가 BTB의 잘못된 예측 결과에 영향을 미칠 수 있다면 추측성 반환 지향 프로그래밍 공격이 가능합니다[10, 13, 16, 30]. 반환 명령어를 실행하는 동안 반환 주소를 예측하는 RSB(Return Stack Buffer)가 제공하는 예측의 경우에도 마찬가지입니다[13, 31, 33]. 최근 결과에 따르면 일부 최신 CPU는 RSB가 언더플로우될 경우 반환 주소 예측을 위해 BTB를 사용하는 것으로 나타났습니다[52]. Spectre 공격의 또 다른 소스는 저장-로드 종속성을 예측하는 것입니다. 로드가 이전 저장소에 의존하지 않는 것으로 잘못 예측되면 오래된 데이터에 대해 예측적으로 실행되어 예측적 저장소 우회가 발생할 수 있습니다[22]. 이러한 가젯은 모두 기본적으로 악용할 수 없지만 지금 설명하는 다른 두 구성 요소에 따라 달라집니다.

두 번째 구성 요소는 공격자가 앞서 언급한 가젯에 대한 입력을 제어하는 방법입니다. 공격자는 사용자 입력, 파일 콘텐츠, 네트워크 패킷 또는 기타 아키텍처 메커니즘을 통해 가젯 입력 값을 직접 정의할 수 있습니다. 반면 공격자는 로드 값 주입[12] 또는 부동 소수점 값 주입[42]을 통해 일시적으로 가젯에 데이터를 주입할 수 있습니다. 공격자가 추측 기간 동안 액세스하거나 실행되는 데이터 또는 명령에 영향을 미칠 수 있다면 가젯 입력을 성공적으로 제어할 수 있습니다.

세 번째 구성 요소는 추측적인 마이크로아키텍처 상태를 아키텍처 상태로 전송하여 추측적으로 액세스한 데이터를 영구 환경으로 유출하는 데 사용되는 비밀 채널입니다. 캐시 비밀 채널[39, 40, 54]은 피해자 코드가 추론적으로 접근한 비밀 데이터에 따라 임시 메모리 접근을 수행하는 경우 적용 가능하다[30]. 비밀이 추론적으로 액세스되어 온코어 버퍼에 로드되는 경우 공격자는 MDS 기반 채널[14, 46, 50]을 사용하여 유출된 데이터를 공격자 스레드로 일시적으로 전송할 수 있으며, 여기서 데이터는 아키텍처로 전송됩니다. 예를 들어 캐시 비밀 채널을 통해 상태를 알립니다. 마지막으로 피해자가 비밀 데이터에 따라 코드를 실행하면 공격자는 포트 경합을 관찰하여 비밀을 알아낼 수 있다[3, 11, 18, 43, 44].

2.5.1 완화. 다양한 Spectre 변종을 완화하기 위해 많은 대책이 개발되었습니다. 세 가지 필수 구성 요소 중 하나가 제거되면 특정 Spectre 변형이 효과적으로 비활성화됩니다. Spectre 가젯에 대한 입력을 제어할 수 없는 공격자는 공격을 성공적으로 시작할 가능성이 없습니다. 추측 상태를 아키텍처 상태로 변환하기 위한 비밀 채널을 사용할 수 없는 경우에도 마찬가지입니다. 그러나 이는 일반적으로 보장하기 어렵기 때문에 스펙터 대응책은 주로 잘못된 예측을 중지하는 데 중점을 둡니다. 중요한 코드 섹션 앞에 lfence 명령어를 삽입하면 이 지점 이후의 추측 실행이 비활성화되므로 일반적인 대책으로 사용할 수 있습니다. 그러나 높은 성능 오버헤드로 인해 보다 구체적인 대책이 개발되었습니다. Spectre-BTB 대책에는 Retpoline[48]과 IBRS, STIBP 또는 IBPB[23]와 같은 마이크로코드 업데이트가 포함됩니다. Spectre-RSB 및 Spectre-BTB-via-RSB는 RSB에 값을 채워 악성 항목을 덮어쓰고 RSB의 언더플로를 방지하거나 IBRS 마이크로코드 업데이트를 설치하여 완화할 수 있습니다. Spectre-STL은 SSBD 마이크로코드 업데이트[23]를 통해 완화될 수 있습니다. 공격자가 공유 분기 예측 버퍼를 변조하는 것을 방지하는 또 다른 과감한 옵션은 SMT를 비활성화하는 것입니다. SMT를 비활성화하면 상당한 성능 손실을 감수하면서 동시 테넌트 간에 분기 예측 하드웨어 리소스를 효과적으로 분할합니다.

2.6 AWS의 격리 모델

Firecracker는 서버리스 및 컨테이너 애플리케이션을 위해 특별히 제작되었으며[1] 현재 AWS의 Fargate CaaS 및 Lambda FaaS에서 사용됩니다. 이 두 서비스 모델 모두에서 Firecracker는 모든 개별 Fargate 작업 또는 Lambda 이벤트를 지원하는 기본 격리 시스템입니다. 이 두 서비스 모델 모두 상대적으로 작고 수명이 짧은 작업을 매우 많이 실행하도록 설계되었습니다. AWS는 결국 Firecracker가 된 격리 시스템에 대한 설계 요구 사항을 다음과 같이 항목화합니다.

격리 : 동일한 하드웨어에서 여러 기능을 실행하는 것이 안전해야 하며 권한 상승, 정보 공개, 비밀 채널 및 기타 위험으로부터 보호되어야 합니다.

오버헤드 및 밀도: 낭비를 최소화하면서 단일 시스템에서 수천 가지 기능을 실행할 수 있어야 합니다.

성능: 함수는 기본적으로 실행되는 것과 유사하게 수행되어야 합니다. 성능도 일관되어야 하며 동일한 하드웨어의 이웃 동작과 격리되어야 합니다.

호환성 : Lambda를 사용하면 함수에 임의의 Linux 바이너리 및 라이브러리가 포함될 수 있습니다. 이는 코드 변경이나 재컴파일 없이 지원되어야 합니다.

빠른 전환: 새로운 기능을 시작하고 오래된 기능을 빠르게 정리할 수 있어야 합니다.

소프트 할당: CPU, 메모리 및 기타 리소스를 과도하게 커밋할 수 있어야 하며, 각 기능은 권한이 있는 리소스가 아닌 필요한 리소스만 소비합니다. [1]

우리는 특히 격리 요구 사항에 관심이 있으며 마이크로아키텍처 공격이 Firecracker 위협 모델의 범위 내로 선언된다는 점을 강조합니다. AWS의 공개 Firecracker Git 저장소에 있는 "설계" 페이지는 격리 모델에 대해 자세히 설명하고 그림 2에 재현된 유용한 다이어그램을 제공합니다. 이 다이어그램은 주로 권한 상승에 대한 보호와 관련이 있습니다. 가장 바깥쪽 보호 계층은 VMM 및 기타 관리 구성 요소를 실행하는 동안 컨테이너 격리 기술을 사용하여 Firecracker의 호스트 커널 액세스를 제한하는 Jailer입니다.

호스트 사용자 공간에서 단일 프로세스의 스레드로 Firecracker를 사용합니다. Firecracker 프로세스 내에서 사용자의 워크로드는 다른 스레드에서 실행됩니다. 워크로드 스레드는 가상 머신의 게스트 운영 체제와 게스트에서 실행되는 모든 프로그램을 실행합니다. 가상 머신 게스트에서 사용자 코드를 실행하면 호스트와의 직접적인 상호 작용이 KVM 및 Firecracker 관리 스레드의 특정 부분과의 사전 설정된 상호 작용으로 제한됩니다. 따라서 호스트 커널의 관점에서 볼 때 VMM과 사용자의 코드가 포함된 VM은 동일한 프로세스에서 실행됩니다. 이것이 AWS가 각 VM이 단일 프로세스에 상주한다고 명시하는 이유입니다. 그러나 VM은 하드웨어 가상화 기술을 통해 분리되어 있기 때문에 사용자 코드, 게스트 커널, VMM은 별도의 주소 공간에서 작동한다. 따라서 게스트의 코드는 게스트의 주소 공간에 매핑되지 않으므로 VMM 또는 게스트 커널 메모리 주소에 구조적으로 또는 일시적으로 액세스할 수 없습니다. 나머지 마이크로아키텍처 공격 표면은 주소 공간 경계를 무시하고 CPU 내부 버퍼에서 정보를 유출하는 MDS 공격과 공격자가 정보 자체 유출을 위해 다른 프로세스의 분기 예측을 조작하는 Spectre 공격으로 제한됩니다.

그림 2에는 표시되지 않았지만 AWS의 위협 모델에서 마찬가지로 중요한 것은 특히 소프트 할당 요구 사항을 고려할 때 하드웨어가 공유될 때 기능을 서로 격리하는 것입니다. 호스트 커널을 손상시키면 모든 게스트의 보안이 손상될 수 있다는 사실 외에도 호스트 하드웨어를 대상으로 하는 마이크로아키텍처 공격은 사용자 코드를 직접적으로 위협할 수도 있습니다. 단일 Firecracker 프로세스에는 사용자 기능으로 가상 머신을 실행하는 데 필요한 모든 스레드가 포함되어 있으므로 소프트 할당은 호스트 운영 체제에서 간단히 수행할 수 있습니다[1]. 이는 표준 Linux 프로세스 격리 시스템이 가상 머신 격리 위에 배치되어 있음을 의미합니다.

2.6.1 Firecracker 보안 권장 사항. Firecracker 문서에서는 마이크로아키텍처 측면 채널[8]로부터 보호하기 위해 다음과 같은 예방 조치를 권장합니다.

• SMT 비활성화

• 커널 페이지 테이블 격리 활성화

• 커널 kame 페이지 병합 비활성화

• Spectre-BTB 완화 기능으로 컴파일된 커널을 사용합니다(예: x86의 IBRS 및 IBPB).

• Spectre-PHT 완화 확인

• L1TF 완화 활성화 • Spectre-STL 완화 활성화

• Rowhammer 완화에 메모리 사용

• 스왑을 비활성화하거나 보안 스왑을 사용합니다.

[1] 가상화된 링 0과 링 3은 네이티브에 가까운 코드 실행이 달성되는 핵심 이유 중 하나입니다.