Tinfoil은 보안 가상머신에서 쓰던 OVMF 펌웨어를 약 300줄의 어셈블리로 대체했다고 밝혔다. 커널과 초기 파일시스템 등을 빌드 시점에 미리 측정해 실행 중 펌웨어가 처리할 일을 줄였으며, 이 방식은 정해진 메모리 구성만 지원하는 Tinfoil의 균일한 환경에 맞춰 설계됐다.

Tinfoil은 호스트를 신뢰할 수 없는 위협 모델을 전제로 한다. 기존 OVMF는 백만 줄이 넘는 C 코드와 다양한 기능을 포함하지만, Tinfoil은 네트워크 부팅 등 필요한 기능이 아니라고 판단한 요소까지 보안 위험을 넓힌다고 봤다. 회사는 OVMF에서 발견된 취약점 사례로 EDK II PXE 드라이버의 부팅 전 원격 코드 실행 취약점을 들었다.

새 방식은 리눅스 커널, 초기 파일시스템(initramfs), 메모리 페이지 테이블, ACPI 테이블과 명령줄을 IGVM 이미지에 넣고, 가상머신이 시작될 때 전체 상태를 하나의 측정값으로 기록한다. 이때 쓰는 IGVM 형식은 Microsoft가 관리하는 규격이다. 펌웨어는 호스트가 제공하는 메모리 맵이 미리 만들어둔 구성과 맞는지, CPU 수가 허용 범위인지 확인한 뒤 리눅스로 제어를 넘긴다. 이후에는 펌웨어가 실행되지 않는다.

호스트가 실제와 다른 메모리 구성을 제시하면 부팅이 실패한다. CPU 수가 실제 할당과 다를 경우에도 리눅스가 추가 CPU를 올리지 못하거나 해당 CPU가 대기 상태에 머물 수 있다고 Tinfoil은 설명한다. 회사는 이런 경우 기밀성이 위협받지는 않는다고 본다. 다만 QEMU의 메모리 배치가 바뀌면 새 구성을 추가하기 전까지 부팅되지 않을 수 있다. 따라서 다양한 시스템에 맞춰 동작하는 범용 펌웨어보다, 구성이 일정한 자사 환경에 적합한 절충이라는 설명이다.

Tinfoil은 Google의 Project Oak Stage0도 검토했지만, Stage0가 부팅 시 커널을 불러 측정하고 호스트 입력을 처리하는 점이 자사의 위협 모델에는 맞지 않았다고 밝혔다. 대신 해당 작업을 빌드 단계로 옮기면 공격자가 실행 중에 조작할 입력과 코드 경로를 줄일 수 있다고 주장한다. 빌드 도구 역시 정확해야 한다는 한계는 인정하면서, 그 도구는 감사 대상이지만 실시간 공격자가 직접 도달하는 실행 코드에는 포함되지 않는다고 설명했다.

Tinfoil은 이 접근으로 OVMF의 기능을 줄이는 데 그치지 않고, 측정과 검증 과정에서 신뢰해야 하는 실행 코드도 줄였다고 본다. 펌웨어와 이미지 빌더는 tinfoilsh/cvmimage의 lothan/igvm 브랜치에 공개돼 있으며, 부팅 설계 문서에는 메모리 배치와 측정 방식, 플랫폼 요구사항이 담겼다. 보안 엔클레이브에 관한 배경은 Tinfoil의 안내서에서 볼 수 있다.