สถาปัตยกรรม AVF

Android มีการติดตั้งใช้งานอ้างอิงของคอมโพเนนต์ทั้งหมดที่จำเป็นต่อการ ติดตั้งใช้งานเฟรมเวิร์กการจำลองการทำงานแบบเสมือนของ Android ปัจจุบันการใช้งานนี้ จำกัดเฉพาะ ARM64 หน้านี้จะอธิบายสถาปัตยกรรมของเฟรมเวิร์ก

ฉากหลัง

สถาปัตยกรรม Arm อนุญาตให้มีระดับข้อยกเว้นได้สูงสุด 4 ระดับ โดยระดับข้อยกเว้น 0 (EL0) มีสิทธิ์น้อยที่สุด และระดับข้อยกเว้น 3 (EL3) มีสิทธิ์มากที่สุด ส่วนที่ ใหญ่ที่สุดของฐานของโค้ด Android (คอมโพเนนต์ทั้งหมดใน User Space) จะทำงานที่ EL0 ส่วนที่เหลือของสิ่งที่เรียกกันโดยทั่วไปว่า "Android" คือเคอร์เนล Linux ซึ่ง ทำงานที่ EL1

เลเยอร์ EL2 ช่วยให้สามารถใช้ไฮเปอร์ไวเซอร์ที่ช่วยแยก หน่วยความจำและอุปกรณ์ออกเป็น pVM แต่ละรายการที่ EL1/EL0 โดยมีการรับประกันความลับ และความสมบูรณ์ที่รัดกุม

ไฮเปอร์ไวเซอร์

เครื่องเสมือนที่ใช้เคอร์เนลที่ได้รับการปกป้อง (pKVM) สร้างขึ้นบน ไฮเปอร์ไวเซอร์ KVM ของ Linux ซึ่งได้รับการขยายความสามารถในการจำกัดการเข้าถึงเพย์โหลด ที่ทำงานในเครื่องเสมือนของแขกที่ทำเครื่องหมายว่า "ได้รับการปกป้อง" ในขณะที่สร้าง

KVM/arm64 รองรับโหมดการดำเนินการต่างๆ ขึ้นอยู่กับความพร้อมใช้งานของ ฟีเจอร์ CPU บางอย่าง ได้แก่ ส่วนขยายโฮสต์การจำลองเสมือน (VHE) (ARMv8.1 ขึ้นไป) ในโหมดใดโหมดหนึ่งดังกล่าว ซึ่งโดยทั่วไปเรียกว่าโหมดที่ไม่ใช่ VHE ระบบจะแยกโค้ดไฮเปอร์ไวเซอร์ออกจากอิมเมจเคอร์เนลระหว่างการบูตและติดตั้งที่ EL2 ในขณะที่เคอร์เนลเองจะทำงานที่ EL1 แม้ว่าจะเป็นส่วนหนึ่งของ โค้ดเบสของ Linux แต่คอมโพเนนต์ EL2 ของ KVM เป็นคอมโพเนนต์ขนาดเล็กที่รับผิดชอบ การสลับระหว่าง EL1 หลายรายการ คอมโพเนนต์ไฮเปอร์ไวเซอร์ได้รับการคอมไพล์ด้วย Linux แต่จะอยู่ในส่วนหน่วยความจำเฉพาะที่แยกต่างหากของอิมเมจ vmlinux pKVM ใช้ประโยชน์จากการออกแบบนี้โดยการขยายโค้ดไฮเปอร์ไวเซอร์ด้วยฟีเจอร์ใหม่ๆ ที่ช่วยให้สามารถจำกัดเคอร์เนลโฮสต์ Android และพื้นที่ผู้ใช้ รวมถึงจำกัดการเข้าถึงหน่วยความจำของแขกและไฮเปอร์ไวเซอร์ของโฮสต์

โมดูลของผู้ให้บริการ pKVM

โมดูลผู้ให้บริการ pKVM เป็นโมดูลเฉพาะฮาร์ดแวร์ที่มีฟังก์ชันการทำงานเฉพาะอุปกรณ์ เช่น ไดรเวอร์หน่วยจัดการหน่วยความจำอินพุต/เอาต์พุต (IOMMU) โมดูลเหล่านี้ช่วยให้คุณพอร์ตฟีเจอร์ด้านความปลอดภัยที่ต้องใช้สิทธิ์เข้าถึงระดับข้อยกเว้น 2 (EL2) ไปยัง pKVM ได้

ดูวิธีติดตั้งใช้งานและโหลดโมดูลของผู้ให้บริการ pKVM ได้ที่ ติดตั้งใช้งานโมดูลของผู้ให้บริการ pKVM

ขั้นตอนการเปิดเครื่อง

รูปภาพต่อไปนี้แสดงขั้นตอนการบูต pKVM

ขั้นตอนการเปิดเครื่อง pKVM

รูปที่ 1 ขั้นตอนการบูต pKVM

  1. การเริ่มต้น: Bootloader จะเข้าสู่เคอร์เนลทั่วไปที่ EL2 จากนั้นโค้ดเคอร์เนลที่เชื่อถือได้ที่ทั้ง EL2 และ EL1 จะเริ่มต้น pKVM และโมดูลของ pKVM ในระหว่าง ขั้นตอนนี้ EL2 จะเชื่อถือ EL1 จึงไม่มีการเรียกใช้โค้ดที่ไม่น่าเชื่อถือ
  2. ลดสิทธิ์ของเคอร์เนล: เคอร์เนลทั่วไปตรวจพบว่ากำลังทำงานที่ EL2 และลดสิทธิ์ของตัวเองเป็น EL1 ส่วน pKVM และโมดูลจะยังคงทำงานที่ EL2 ต่อไป
  3. รันไทม์: เคอร์เนลทั่วไปจะบูตตามปกติ โดยโหลดไดรเวอร์อุปกรณ์ที่จำเป็นทั้งหมดจนกว่าจะถึงพื้นที่ผู้ใช้ ในตอนนี้ pKVM พร้อมใช้งานและจัดการตารางหน้าเว็บระยะที่ 2

ขั้นตอนการเปิดเครื่องจะเชื่อถือ Bootloader ในการยืนยันและรักษาความสมบูรณ์ของ อิมเมจเคอร์เนลสำหรับระยะเริ่มต้น หลังจากที่เคอร์เนลถูกลดสิทธิ์ ไฮเปอร์ไวเซอร์จะไม่ถือว่าเคอร์เนลเป็นสิ่งที่เชื่อถือได้อีกต่อไป ซึ่งจะทำให้ไฮเปอร์ไวเซอร์มีหน้าที่ ปกป้องตัวเองแม้ว่าเคอร์เนลจะถูกบุกรุกก็ตาม

การมีเคอร์เนล Android และไฮเปอร์ไวเซอร์ในอิมเมจไบนารีเดียวกันช่วยให้มีอินเทอร์เฟซการสื่อสารที่เชื่อมโยงกันอย่างใกล้ชิดระหว่างทั้ง 2 อย่าง การเชื่อมต่อที่แน่นแฟ้นนี้ รับประกันการอัปเดตแบบอะตอมของคอมโพเนนต์ทั้ง 2 รายการ ซึ่งช่วยให้ไม่ต้อง รักษาอินเทอร์เฟซระหว่างคอมโพเนนต์ให้เสถียร และมอบความยืดหยุ่น อย่างมากโดยไม่กระทบต่อความสามารถในการบำรุงรักษาในระยะยาว การเชื่อมต่อแบบแน่น ยังช่วยให้เพิ่มประสิทธิภาพได้เมื่อทั้ง 2 คอมโพเนนต์ทำงานร่วมกัน โดยไม่ส่งผลต่อการรับประกันความปลอดภัยที่ไฮเปอร์ไวเซอร์มอบให้

นอกจากนี้ การนำ GKI มาใช้ในระบบนิเวศของ Android ยังช่วยให้สามารถ ติดตั้งไฮเปอร์ไวเซอร์ pKVM ในอุปกรณ์ Android ในไบนารีเดียวกันกับ เคอร์เนลได้โดยอัตโนมัติ

การป้องกันการเข้าถึงหน่วยความจำ CPU

สถาปัตยกรรม Arm ระบุหน่วยจัดการหน่วยความจำ (MMU) ที่แยกออกเป็น 2 ขั้นตอนอิสระ ซึ่งทั้ง 2 ขั้นตอนสามารถใช้เพื่อใช้การแปลที่อยู่ และการควบคุมการเข้าถึงส่วนต่างๆ ของหน่วยความจำได้ MMU ระยะที่ 1 ควบคุมโดย EL1 และอนุญาตให้มีการแปลที่อยู่ระดับแรก MMU ระยะที่ 1 ใช้โดย Linux เพื่อจัดการพื้นที่ที่อยู่เสมือนที่จัดให้แก่กระบวนการแต่ละอย่างในพื้นที่ผู้ใช้ และพื้นที่ที่อยู่เสมือนของตัวเอง

MMU ขั้นที่ 2 ควบคุมโดย EL2 และช่วยให้ใช้การแปลที่อยู่ครั้งที่ 2 กับที่อยู่เอาต์พุตของ MMU ขั้นที่ 1 ได้ ซึ่งส่งผลให้ได้ที่อยู่จริง (PA) ไฮเปอร์ไวเซอร์สามารถใช้การแปลระยะที่ 2 เพื่อ ควบคุมและแปลการเข้าถึงหน่วยความจำจาก VM ของแขกรับเชิญทั้งหมด ดังที่แสดงในรูปที่ 2 เมื่อเปิดใช้การแปลทั้ง 2 ขั้นตอน ที่อยู่เอาต์พุตของ ขั้นตอนที่ 1 จะเรียกว่าที่อยู่จริงระดับกลาง (IPA) หมายเหตุ: ระบบจะแปลที่อยู่เสมือน (VA) เป็น IPA แล้วจึงแปลเป็น PA

การป้องกันการเข้าถึงหน่วยความจำ CPU

รูปที่ 2 การป้องกันการเข้าถึงหน่วยความจำ CPU

โดยปกติแล้ว KVM จะทำงานโดยเปิดใช้การแปลระยะที่ 2 ขณะเรียกใช้แขกรับเชิญ และปิดใช้ระยะที่ 2 ขณะเรียกใช้เคอร์เนล Linux ของโฮสต์ สถาปัตยกรรมนี้ช่วยให้การเข้าถึงหน่วยความจำจาก MMU ระดับ 1 ของโฮสต์ผ่าน MMU ระดับ 2 ได้ จึงทำให้โฮสต์เข้าถึงหน้าหน่วยความจำของแขกได้โดยไม่มีข้อจำกัด ในทางกลับกัน pKVM จะเปิดใช้การป้องกันระยะที่ 2 แม้ในบริบทของโฮสต์ และให้ไฮเปอร์ไวเซอร์เป็นผู้รับผิดชอบในการปกป้องหน้าหน่วยความจำของแขก แทนโฮสต์

KVM ใช้การแปลที่อยู่ที่ขั้นที่ 2 อย่างเต็มที่เพื่อใช้การแมป IPA/PA ที่ซับซ้อนสำหรับแขก ซึ่งสร้างภาพลวงตาของหน่วยความจำที่ต่อเนื่องสำหรับแขกแม้ว่าจะมีการกระจายทางกายภาพก็ตาม อย่างไรก็ตาม การใช้งาน MMU ระดับ 2 สำหรับโฮสต์จะจำกัดไว้ที่การควบคุมการเข้าถึงเท่านั้น โฮสต์สเตจ 2 จะได้รับการแมปแบบระบุตัวตนเพื่อให้มั่นใจว่าหน่วยความจำที่ต่อเนื่องในพื้นที่ IPA ของโฮสต์ จะต่อเนื่องในพื้นที่ PA สถาปัตยกรรมนี้ช่วยให้ใช้การแมปขนาดใหญ่ในตารางหน้าเว็บได้ และช่วยลดแรงกดดันใน Translation Lookaside Buffer (TLB) เนื่องจาก PA จัดทำดัชนีการจับคู่ข้อมูลประจำตัวได้ จึงใช้ โฮสต์ระยะที่ 2 เพื่อติดตามการเป็นเจ้าของหน้าเว็บในตารางหน้าเว็บโดยตรงด้วย

การป้องกันการเข้าถึงหน่วยความจำโดยตรง (DMA)

ดังที่อธิบายไว้ก่อนหน้านี้ การยกเลิกการแมปหน้าผู้เยี่ยมชมจากโฮสต์ Linux ในตารางหน้า CPU เป็นขั้นตอนที่จำเป็นแต่ไม่เพียงพอสำหรับการปกป้องหน่วยความจำของแขกรับเชิญ pKVM ยังต้องป้องกันการเข้าถึงหน่วยความจำที่ทำโดยอุปกรณ์ที่รองรับ DMA ภายใต้การควบคุมของเคอร์เนลโฮสต์ และความเป็นไปได้ของการโจมตี DMA ที่เริ่มต้นโดยโฮสต์ที่เป็นอันตราย เพื่อป้องกันไม่ให้อุปกรณ์ดังกล่าวเข้าถึงหน่วยความจำของแขกรับเชิญ pKVM จึงต้องใช้ฮาร์ดแวร์หน่วยจัดการหน่วยความจำอินพุต/เอาต์พุต (IOMMU) สำหรับอุปกรณ์ที่ใช้ DMA ได้ทุกเครื่องในระบบ ดังที่แสดงในรูปที่ 3

การป้องกันการเข้าถึงหน่วยความจำ DMA

รูปที่ 3 การป้องกันการเข้าถึงหน่วยความจำ DMA

อย่างน้อยที่สุด ฮาร์ดแวร์ IOMMU จะมีวิธีการให้และเพิกถอน สิทธิ์เข้าถึงแบบอ่าน/เขียนสำหรับอุปกรณ์ไปยังหน่วยความจำจริงที่ระดับความละเอียดของหน้า อย่างไรก็ตาม ฮาร์ดแวร์ IOMMU นี้จำกัดการใช้อุปกรณ์ใน pVM เนื่องจากฮาร์ดแวร์ดังกล่าวถือว่ามี ระยะที่ 2 ที่มีการแมปข้อมูลประจำตัว

เพื่อให้มั่นใจว่ามีการแยกกันระหว่างเครื่องเสมือน ธุรกรรมหน่วยความจำที่สร้างขึ้นใน นามของเอนทิตีต่างๆ ต้องแยกแยะได้โดย IOMMU เพื่อให้ใช้ชุดตารางหน้าเว็บที่เหมาะสมสำหรับการแปลได้

นอกจากนี้ การลดปริมาณโค้ดเฉพาะ SoC ที่ EL2 ยังเป็นกลยุทธ์สำคัญ ในการลดฐานการประมวลผลที่เชื่อถือได้ (TCB) โดยรวมของ pKVM และขัดต่อ การรวมไดรเวอร์ IOMMU ไว้ในไฮเปอร์ไวเซอร์ เพื่อลดปัญหานี้ โฮสต์ที่ EL1 มีหน้าที่รับผิดชอบงานการจัดการ IOMMU เสริม เช่น การจัดการพลังงาน การเริ่มต้น และการจัดการการขัดจังหวะ (หากมี)

อย่างไรก็ตาม การให้โฮสต์ควบคุมสถานะของอุปกรณ์จะทำให้มีข้อกำหนดเพิ่มเติม ในอินเทอร์เฟซการเขียนโปรแกรมของฮาร์ดแวร์ IOMMU เพื่อให้มั่นใจว่า การตรวจสอบสิทธิ์จะไม่ถูกข้ามด้วยวิธีอื่น เช่น การรีเซ็ตอุปกรณ์

IOMMU มาตรฐานที่ได้รับการสนับสนุนอย่างดีสำหรับอุปกรณ์ Arm ซึ่งทำให้ทั้งการแยกและการกำหนดโดยตรงเป็นไปได้คือสถาปัตยกรรมหน่วยจัดการหน่วยความจำของระบบ (SMMU) ของ Arm สถาปัตยกรรมนี้เป็นโซลูชันอ้างอิงที่แนะนำ

การเป็นเจ้าของความทรงจำ

ในเวลาที่บูต ระบบจะถือว่าโฮสต์เป็นเจ้าของหน่วยความจำทั้งหมดที่ไม่ใช่ไฮเปอร์ไวเซอร์ และ ไฮเปอร์ไวเซอร์จะติดตามหน่วยความจำดังกล่าว เมื่อสร้าง pVM โฮสต์จะบริจาคหน้าหน่วยความจำเพื่อให้บูตได้ และไฮเปอร์ไวเซอร์จะเปลี่ยนสิทธิ์การเป็นเจ้าของหน้าเหล่านั้นจากโฮสต์ไปยัง pVM ดังนั้น ไฮเปอร์ไวเซอร์จึงกำหนดข้อจำกัดการควบคุมการเข้าถึงในตารางหน้าของโฮสต์ในระยะที่ 2 เพื่อป้องกันไม่ให้เข้าถึงหน้าดังกล่าวอีกครั้ง ซึ่งจะช่วยรักษาความลับให้กับแขกรับเชิญ

การสื่อสารระหว่างโฮสต์และแขกรับเชิญเกิดขึ้นได้จากการแชร์หน่วยความจำที่ควบคุม ระหว่างกัน ระบบอนุญาตให้แขกแชร์บางหน้าของตนเองกลับไปให้ โฮสต์โดยใช้ไฮเปอร์คอล ซึ่งจะสั่งให้ไฮเปอร์ไวเซอร์ทำการแมปหน้าเหล่านั้นใหม่ ในตารางหน้าของโฮสต์ในระยะที่ 2 ในทำนองเดียวกัน การสื่อสารของโฮสต์กับ TrustZone จะเป็นไปได้ด้วยการแชร์หน่วยความจำและ/หรือการดำเนินการยืม ซึ่งทั้งหมดนี้ได้รับการตรวจสอบและควบคุมอย่างใกล้ชิดโดย pKVM โดยใช้ข้อกำหนดเฟรมเวิร์กเฟิร์มแวร์สำหรับ Arm (FF-A)

เนื่องจากข้อกำหนดด้านหน่วยความจำของ pVM อาจเปลี่ยนแปลงไปตามกาลเวลา จึงมี Hypercall ซึ่งช่วยให้สามารถสละสิทธิ์การเป็นเจ้าของหน้าเว็บที่ระบุซึ่งเป็นของผู้เรียก กลับไปยังโฮสต์ได้ ในทางปฏิบัติ ไฮเปอร์คอลนี้ใช้ กับโปรโตคอล Virtio Balloon เพื่อให้ VMM ขอหน่วยความจำ จาก pVM และเพื่อให้ pVM แจ้ง VMM เกี่ยวกับหน้าที่สละสิทธิ์ ในลักษณะที่ควบคุมได้

ไฮเปอร์ไวเซอร์มีหน้าที่ติดตามความเป็นเจ้าของหน้าหน่วยความจำทั้งหมดในระบบ รวมถึงติดตามว่ามีการแชร์หรือให้ยืมแก่เอนทิตีอื่นๆ หรือไม่ การติดตามสถานะส่วนใหญ่ นี้ทำได้โดยใช้ข้อมูลเมตาที่แนบมากับตารางหน้าของระยะที่ 2 ของโฮสต์และแขกรับเชิญ โดยใช้บิตที่สงวนไว้ในรายการตารางหน้า (PTE) ซึ่งตามชื่อที่ระบุไว้ จะสงวนไว้สำหรับการใช้งานซอฟต์แวร์

โฮสต์ต้องตรวจสอบว่าไม่ได้พยายามเข้าถึงหน้าเว็บที่ไฮเปอร์ไวเซอร์ทำให้เข้าถึงไม่ได้ การเข้าถึงโฮสต์อย่างผิดกฎหมายจะทำให้ไฮเปอร์ไวเซอร์แทรกข้อยกเว้นแบบซิงโครนัส ลงในโฮสต์ ซึ่งอาจส่งผลให้ งานในพื้นที่ผู้ใช้ที่รับผิดชอบได้รับสัญญาณ SEGV หรือเคอร์เนลของโฮสต์ ขัดข้อง เพื่อป้องกันการเข้าถึงโดยไม่ตั้งใจ หน้าที่โฮสต์เคอร์เนลบริจาคให้ผู้เข้าร่วมจะ ไม่มีสิทธิ์ในการสลับหรือผสาน

การจัดการการขัดจังหวะและตัวจับเวลา

การขัดจังหวะเป็นส่วนสำคัญของวิธีที่แขกรับเชิญโต้ตอบกับอุปกรณ์ และสำหรับการสื่อสารระหว่าง CPU ซึ่งการขัดจังหวะระหว่างโปรเซสเซอร์ (IPI) เป็น กลไกการสื่อสารหลัก โมเดล KVM คือการมอบหมายการจัดการอินเทอร์รัปต์เสมือนทั้งหมดให้กับโฮสต์ใน EL1 ซึ่งมีลักษณะเป็นส่วนที่ไม่น่าเชื่อถือของไฮเปอร์ไวเซอร์เพื่อวัตถุประสงค์ดังกล่าว

pKVM มีการจำลองตัวควบคุมการขัดจังหวะทั่วไปเวอร์ชัน 3 (GICv3) เต็มรูปแบบ โดยอิงตามโค้ด KVM ที่มีอยู่ ตัวจับเวลาและ IPI จะได้รับการจัดการเป็นส่วนหนึ่งของโค้ดการจำลองที่ไม่น่าเชื่อถือนี้

การรองรับ GICv3

อินเทอร์เฟซระหว่าง EL1 กับ EL2 ต้องตรวจสอบว่าโฮสต์ EL1 มองเห็นสถานะการขัดจังหวะทั้งหมด รวมถึงสำเนาของรีจิสเตอร์ไฮเปอร์ไวเซอร์ที่เกี่ยวข้องกับการขัดจังหวะ โดยปกติแล้ว การมองเห็นนี้จะทำได้โดยใช้รีเจียนหน่วยความจำที่ใช้ร่วมกัน ซึ่งมี 1 รีเจียนต่อ CPU เสมือน (vCPU)

สามารถลดความซับซ้อนของโค้ดการสนับสนุนรันไทม์ของรีจิสทรีระบบเพื่อรองรับเฉพาะรีจิสทรีการขัดจังหวะที่สร้างโดยซอฟต์แวร์ (SGIR) และรีจิสทรีการดักจับรีจิสทรีการขัดจังหวะการปิดใช้งาน (DIR) สถาปัตยกรรมกำหนดให้รีจิสเตอร์เหล่านี้ ต้องดักจับไปยัง EL2 เสมอ ขณะที่การดักจับอื่นๆ นั้นจนถึงตอนนี้มีประโยชน์ ในการลดผลกระทบจากข้อผิดพลาดเท่านั้น ส่วนอื่นๆ จะได้รับการจัดการในฮาร์ดแวร์

ในส่วนของ MMIO ทุกอย่างจะได้รับการจำลองที่ EL1 โดยใช้โครงสร้างพื้นฐานปัจจุบันทั้งหมดใน KVM ซ้ำ สุดท้ายนี้ Wait for Interrupt (WFI) จะส่งต่อให้ EL1 เสมอ เนื่องจากนี่เป็นหนึ่งใน Primitive การจัดกำหนดการพื้นฐานที่ KVM ใช้

การรองรับตัวจับเวลา

ค่าตัวเปรียบเทียบสำหรับตัวจับเวลาเสมือนต้องแสดงต่อ EL1 ในแต่ละ การดักจับ WFI เพื่อให้ EL1 สามารถแทรกการขัดจังหวะของตัวจับเวลาขณะที่ vCPU ถูกบล็อก ระบบจะจำลองตัวจับเวลาจริงทั้งหมด และส่งต่อการดักจับทั้งหมดไปยัง EL1

การจัดการ MMIO

หากต้องการสื่อสารกับ Virtual Machine Monitor (VMM) และจำลอง GIC ต้องส่งต่อการดักจับ MMIO กลับไปยังโฮสต์ใน EL1 เพื่อการจัดลำดับความสำคัญเพิ่มเติม pKVM ต้องมีสิ่งต่อไปนี้

  • IPA และขนาดของการเข้าถึง
  • ข้อมูลในกรณีของการเขียน
  • Endianness ของ CPU ณ จุดที่ดักจับ

นอกจากนี้ ระบบจะส่งต่อกับดักที่มีรีจิสเตอร์อเนกประสงค์ (GPR) เป็น แหล่งที่มา/ปลายทางโดยใช้รีจิสเตอร์เสมือนการโอนแบบนามธรรม

อินเทอร์เฟซสำหรับผู้เข้าร่วม

ผู้ใช้ชั่วคราวสามารถสื่อสารกับผู้ใช้ชั่วคราวที่ได้รับการปกป้องได้โดยใช้การผสมผสานระหว่าง Hypercall และการเข้าถึงหน่วยความจำไปยังรีเจียนที่ถูกดัก Hypercall จะแสดงตามมาตรฐาน SMCCC โดยมีช่วงที่ KVM สงวนไว้สำหรับการจัดสรรของผู้ให้บริการ Hypercall ต่อไปนี้มีความสำคัญเป็นพิเศษ ต่อแขกรับเชิญของ pKVM

Hypercall ทั่วไป

  • PSCI มีกลไกมาตรฐานสำหรับแขกในการควบคุมวงจรของ vCPU รวมถึงการออนไลน์ การออฟไลน์ และการปิดระบบ
  • TRNG มีกลไกมาตรฐานสำหรับแขกในการขอเอนโทรปีจาก pKVM ซึ่งส่งต่อการเรียกไปยัง EL3 กลไกนี้มีประโยชน์อย่างยิ่ง ในกรณีที่ไม่สามารถเชื่อถือโฮสต์ให้จำลองเครื่องสร้างตัวเลขสุ่ม (RNG) ของฮาร์ดแวร์ได้

ไฮเปอร์คอล pKVM

  • การแชร์ความทรงจำกับโฮสต์ ในตอนแรก โฮสต์จะเข้าถึงหน่วยความจำของแขกรับเชิญทั้งหมดไม่ได้ แต่จำเป็นต้องมีสิทธิ์เข้าถึงโฮสต์สำหรับการสื่อสารหน่วยความจำที่ใช้ร่วมกันและสำหรับอุปกรณ์ Paravirtualized ที่ใช้บัฟเฟอร์ที่ใช้ร่วมกัน Hypercall สำหรับการแชร์และยกเลิกการแชร์หน้าเว็บกับโฮสต์ช่วยให้แขกตัดสินใจได้ว่าจะให้ส่วนใดของหน่วยความจำเข้าถึงได้สำหรับ Android ที่เหลือโดยไม่ต้องมีการแฮนด์เชค
  • การสละสิทธิ์ในหน่วยความจำให้แก่โฮสต์ โดยปกติแล้ว หน่วยความจำของแขกจะเป็นของแขกจนกว่าจะถูกทำลาย สถานะนี้อาจไม่เพียงพอสำหรับ VM ที่มีอายุการใช้งานยาวนาน ซึ่งมีข้อกำหนดด้านหน่วยความจำที่แตกต่างกันไปตามเวลา relinquish Hypercall ช่วยให้แขกโอนความเป็นเจ้าของหน้าเว็บกลับไปยัง โฮสต์ได้อย่างชัดเจนโดยไม่ต้องสิ้นสุดการเข้าพัก
  • การดักจับการเข้าถึงหน่วยความจำไปยังโฮสต์ โดยปกติแล้ว หากแขกรับเชิญ KVM เข้าถึง ที่อยู่ที่ไม่ได้สอดคล้องกับรีเจียนหน่วยความจำที่ถูกต้อง เธรด vCPU จะออกจากโฮสต์ และโดยทั่วไปการเข้าถึงจะใช้สำหรับ MMIO และ จำลองโดย VMM ในพื้นที่ผู้ใช้ เพื่ออำนวยความสะดวกในการจัดการนี้ pKVM ต้องกระจายข้อมูลรายละเอียดเกี่ยวกับคำสั่งที่ผิดพลาด เช่น แอดเดรส พารามิเตอร์รีจิสเตอร์ และเนื้อหาที่อาจมี กลับไปยังโฮสต์ ซึ่งอาจเปิดเผยข้อมูลที่ละเอียดอ่อนโดยไม่ตั้งใจ จากแขกที่ได้รับการปกป้องหากไม่ได้คาดการณ์การดักจับ pKVM จะแก้ปัญหานี้ โดยถือว่าข้อผิดพลาดเหล่านี้ร้ายแรง เว้นแต่แขกจะเคย ออกไฮเปอร์คอลเพื่อระบุช่วง IPA ที่ผิดพลาดเป็นช่วงที่ ได้รับอนุญาตให้เข้าถึงเพื่อดักจับกลับไปยังโฮสต์ โซลูชันนี้เรียกว่าการป้องกัน MMIO

อุปกรณ์ I/O เสมือน (virtio)

Virtio เป็นมาตรฐานยอดนิยมแบบพกพาและมีเสถียรภาพสำหรับการติดตั้งใช้งานและ การโต้ตอบกับอุปกรณ์ที่ใช้ Paravirtualization อุปกรณ์ส่วนใหญ่ที่แสดงต่อแขกรับเชิญที่ได้รับการปกป้องจะใช้ virtio นอกจากนี้ Virtio ยังเป็นรากฐานของการใช้งาน vsock ที่ใช้สำหรับการสื่อสารระหว่างแขกรับเชิญที่ได้รับการปกป้องกับส่วนอื่นๆ ของ Android

โดยทั่วไปแล้ว VMM จะติดตั้งใช้งานอุปกรณ์ Virtio ในพื้นที่ผู้ใช้ของโฮสต์ ซึ่งจะสกัดกั้นการเข้าถึงหน่วยความจำที่ดักจับจากแขกไปยังอินเทอร์เฟซ MMIO ของอุปกรณ์ Virtio และจำลองลักษณะการทำงานที่คาดไว้ การเข้าถึง MMIO มีค่าใช้จ่ายค่อนข้างสูงเนื่องจากการเข้าถึงอุปกรณ์แต่ละครั้งต้องมีการเดินทางไปกลับไปยัง VMM และกลับมา ดังนั้นการโอนข้อมูลจริงส่วนใหญ่ระหว่างอุปกรณ์และแขกจึงเกิดขึ้นโดยใช้ชุด Virtqueue ในหน่วยความจำ สมมติฐานหลักของ virtio คือโฮสต์สามารถเข้าถึงหน่วยความจำของแขกรับเชิญได้โดยพลการ สมมติฐานนี้ เห็นได้ชัดในการออกแบบ Virtqueue ซึ่งอาจมีพอยน์เตอร์ไปยัง บัฟเฟอร์ในแขกที่การจำลองอุปกรณ์ตั้งใจจะเข้าถึงโดยตรง

แม้ว่าไฮเปอร์คอลที่อธิบายไว้ก่อนหน้านี้เกี่ยวกับการแชร์หน่วยความจำจะใช้เพื่อ แชร์บัฟเฟอร์ข้อมูล virtio จากแขกไปยังโฮสต์ได้ แต่การแชร์นี้ จำเป็นต้องดำเนินการที่ระดับหน้า และอาจทำให้มีการเปิดเผยข้อมูลมากกว่าที่จำเป็น หากขนาดบัฟเฟอร์น้อยกว่าขนาดของหน้า แต่จะกำหนดค่าให้ระบบปฏิบัติการแขก จัดสรรทั้ง Virtqueue และบัฟเฟอร์ข้อมูลที่เกี่ยวข้อง จากหน้าต่างหน่วยความจำที่ใช้ร่วมกันแบบคงที่ โดยจะคัดลอก (ส่งต่อ) ข้อมูล ไปยังและจากหน้าต่างตามที่จำเป็น

อุปกรณ์เสมือนจริง

รูปที่ 4 อุปกรณ์ Virtio

การโต้ตอบกับ TrustZone

แม้ว่าแขกรับเชิญจะโต้ตอบกับ TrustZone โดยตรงไม่ได้ แต่ผู้จัดจะต้องยังคงสามารถออกการเรียก SMC ไปยังโลกที่ปลอดภัยได้ การเรียกเหล่านี้สามารถระบุ บัฟเฟอร์หน่วยความจำที่ระบุที่อยู่จริงซึ่งโฮสต์เข้าถึงไม่ได้ เนื่องจากโดยทั่วไปแล้วซอฟต์แวร์ที่ปลอดภัยจะไม่ทราบถึงการเข้าถึงบัฟเฟอร์ โฮสต์ที่เป็นอันตรายจึงอาจใช้บัฟเฟอร์นี้เพื่อทำการโจมตีแบบ Confused Deputy (คล้ายกับการโจมตี DMA) pKVM จะดักจับการเรียก SMC ของโฮสต์ทั้งหมดไปยัง EL2 และทำหน้าที่เป็นพร็อกซีระหว่างโฮสต์กับ Secure Monitor ที่ EL3 เพื่อป้องกันการโจมตีดังกล่าว

ระบบจะส่งต่อการเรียก PSCI จากโฮสต์ไปยังเฟิร์มแวร์ EL3 โดยมีการแก้ไขน้อยที่สุด โดยเฉพาะอย่างยิ่ง จุดแรกเข้าสำหรับ CPU ที่ออนไลน์หรือ กลับมาทำงานต่อจากโหมดพักจะได้รับการเขียนใหม่เพื่อให้มีการ ติดตั้งตารางหน้าของระยะที่ 2 ที่ EL2 ก่อนที่จะกลับไปยังโฮสต์ที่ EL1 ในระหว่างการบูต pKVM จะบังคับใช้ การป้องกันนี้

สถาปัตยกรรมนี้ขึ้นอยู่กับ SoC ที่รองรับ PSCI ซึ่งควรใช้ TF-A เวอร์ชันล่าสุด เป็นเฟิร์มแวร์ EL3

เฟรมเวิร์กเฟิร์มแวร์สำหรับ Arm (FF-A) จะกำหนดมาตรฐานการโต้ตอบระหว่างโลกปกติและโลกที่ปลอดภัย โดยเฉพาะอย่างยิ่งในกรณีที่มีไฮเปอร์ไวเซอร์ที่ปลอดภัย ส่วนสำคัญของ ข้อกำหนดจะกำหนดกลไกสำหรับการแชร์หน่วยความจำกับโลกที่ปลอดภัย โดยใช้ทั้งรูปแบบข้อความทั่วไปและโมเดลสิทธิ์ที่กำหนดไว้อย่างดีสำหรับ หน้าเว็บพื้นฐาน พร็อกซี pKVM จะส่งต่อข้อความ FF-A เพื่อให้มั่นใจว่าโฮสต์ ไม่ได้พยายามแชร์หน่วยความจำกับฝั่งที่ปลอดภัยซึ่งไม่มี สิทธิ์เพียงพอ

สถาปัตยกรรมนี้อาศัยซอฟต์แวร์โลกที่ปลอดภัยซึ่งบังคับใช้โมเดลการเข้าถึงหน่วยความจำ เพื่อให้มั่นใจว่าแอปที่เชื่อถือได้และซอฟต์แวร์อื่นๆ ที่ทำงานในโลกที่ปลอดภัยจะเข้าถึงหน่วยความจำได้ก็ต่อเมื่อ โลกที่ปลอดภัยเป็นเจ้าของหน่วยความจำนั้นแต่เพียงผู้เดียว หรือมีการแชร์หน่วยความจำนั้นกับโลกที่ปลอดภัยอย่างชัดเจน โดยใช้ FF-A ในระบบที่มี S-EL2 การบังคับใช้โมเดลการเข้าถึงหน่วยความจำควร ดำเนินการโดย Secure Partition Manager Core (SPMC) เช่น Hafnium ซึ่งดูแลตารางหน้าของสเตจ 2 สำหรับโลกที่ปลอดภัย ในระบบที่ไม่มี S-EL2 TEE จะบังคับใช้โมเดลการเข้าถึงหน่วยความจำผ่านตารางหน้าของระยะที่ 1 แทน

หากการเรียก SMC ไปยัง EL2 ไม่ใช่การเรียก PSCI หรือข้อความที่กำหนดโดย FF-A ระบบจะส่งต่อ SMC ที่ไม่ได้จัดการไปยัง EL3 สมมติฐานคือเฟิร์มแวร์ที่ปลอดภัย (ซึ่งต้องเชื่อถือได้) สามารถจัดการ SMC ที่ไม่ได้จัดการได้อย่างปลอดภัย เนื่องจากเฟิร์มแวร์เข้าใจข้อควรระวังที่จำเป็นในการรักษาการแยก pVM

โปรแกรมตรวจสอบเครื่องเสมือน

crosvm คือโปรแกรมตรวจสอบเครื่องเสมือน (VMM) ที่เรียกใช้เครื่องเสมือนผ่านอินเทอร์เฟซ KVM ของ Linux สิ่งที่ทำให้ crosvm แตกต่างคือการมุ่งเน้น ด้านความปลอดภัยด้วยการใช้ภาษาโปรแกรม Rust และแซนด์บ็อกซ์รอบๆ อุปกรณ์เสมือนเพื่อปกป้องเคอร์เนลของโฮสต์ ดูข้อมูลเพิ่มเติมเกี่ยวกับ crosvm ได้ในเอกสารประกอบอย่างเป็นทางการที่นี่

ตัวอธิบายไฟล์และ ioctl

KVM จะแสดงอุปกรณ์อักขระ /dev/kvm ให้กับพื้นที่ผู้ใช้ด้วย ioctl ที่ประกอบกันเป็น KVM API ioctls อยู่ในหมวดหมู่ต่อไปนี้

  • การค้นหา ioctl ของระบบและการตั้งค่าแอตทริบิวต์ส่วนกลางที่ส่งผลต่อทั้งระบบย่อย KVM และการสร้าง pVM
  • ioctls ของ VM จะค้นหาและตั้งค่าแอตทริบิวต์ที่สร้าง CPU เสมือน (vCPU) และ อุปกรณ์ รวมถึงส่งผลต่อ pVM ทั้งหมด เช่น การรวมเลย์เอาต์หน่วยความจำและ จำนวน CPU เสมือน (vCPU) และอุปกรณ์
  • ioctl ของ vCPU จะค้นหาและตั้งค่าแอตทริบิวต์ที่ควบคุมการทำงานของ CPU เสมือนเดียว
  • Device ioctls จะค้นหาและตั้งค่าแอตทริบิวต์ที่ควบคุมการทำงานของ อุปกรณ์เสมือนเครื่องเดียว

กระบวนการ crosvm แต่ละรายการจะเรียกใช้เครื่องเสมือน 1 อินสแตนซ์ กระบวนการนี้ ใช้ ioctl ของระบบ KVM_CREATE_VM เพื่อสร้างตัวอธิบายไฟล์ VM ที่ใช้ ออก ioctl ของ pVM ได้ KVM_CREATE_VCPU หรือ KVM_CREATE_DEVICE ioctl ใน FD ของ VM จะสร้าง vCPU/อุปกรณ์และแสดงตัวบอกไฟล์ที่ชี้ไปยัง ทรัพยากรใหม่ คุณสามารถใช้ ioctl ใน FD ของ vCPU หรืออุปกรณ์เพื่อควบคุมอุปกรณ์ ที่สร้างขึ้นโดยใช้ ioctl ใน FD ของ VM สำหรับ vCPU ซึ่งรวมถึง งานสำคัญในการเรียกใช้โค้ดของแขก

ภายใน crosvm จะลงทะเบียนตัวอธิบายไฟล์ของ VM กับเคอร์เนลโดยใช้epollอินเทอร์เฟซที่ทริกเกอร์ขอบ จากนั้นเคอร์เนลจะแจ้งให้ crosvm ทราบทุกครั้งที่มีเหตุการณ์ใหม่ที่รอดำเนินการในตัวอธิบายไฟล์

pKVM เพิ่มความสามารถใหม่ KVM_CAP_ARM_PROTECTED_VM ซึ่งใช้เพื่อ รับข้อมูลเกี่ยวกับสภาพแวดล้อม pVM และตั้งค่าโหมดที่ได้รับการปกป้องสำหรับ VM ได้ crosvm จะใช้ความสามารถนี้ในระหว่างการสร้าง pVM หากมีการส่งแฟล็ก --protected-vm เพื่อค้นหาและจองหน่วยความจำในปริมาณที่เหมาะสมสำหรับ เฟิร์มแวร์ pVM แล้วจึงเปิดใช้โหมดที่ได้รับการปกป้อง

การจัดสรรหน่วยความจำ

หน้าที่หลักอย่างหนึ่งของ VMM คือการจัดสรรหน่วยความจำของ VM และ การจัดการเลย์เอาต์หน่วยความจำของ VM โดย crosvm สร้าง เลย์เอาต์หน่วยความจำแบบคงที่ซึ่งอธิบายคร่าวๆ ไว้ในตารางด้านล่าง

FDT ในโหมดปกติ PHYS_MEMORY_END - 0x200000
พื้นที่ว่าง ...
Ramdisk ALIGN_UP(KERNEL_END, 0x1000000)
เคอร์เนล 0x80080000
Bootloader 0x80200000
FDT ในโหมด BIOS 0x80000000
ฐานหน่วยความจำจริง 0x80000000
เฟิร์มแวร์ pVM 0x7FE00000
หน่วยความจำอุปกรณ์ 0x10000 - 0x40000000

หน่วยความจำจริงจะได้รับการจัดสรรด้วย mmap และหน่วยความจำจะได้รับการบริจาคให้กับ VM เพื่อ สร้างภูมิภาคหน่วยความจำที่เรียกว่า memslots ด้วย KVM_SET_USER_MEMORY_REGION ioctl ดังนั้นหน่วยความจำ pVM ของแขกรับเชิญทั้งหมดจึง เชื่อมโยงกับอินสแตนซ์ crosvm ที่จัดการหน่วยความจำดังกล่าว และอาจส่งผลให้ กระบวนการถูกปิด (สิ้นสุด VM) หากโฮสต์เริ่มมีหน่วยความจำว่างไม่เพียงพอ เมื่อหยุด VM ไฮเปอร์ไวเซอร์จะล้างหน่วยความจำโดยอัตโนมัติและส่งคืนไปยังเคอร์เนลของโฮสต์

ภายใต้ KVM ปกติ VMM จะยังคงมีสิทธิ์เข้าถึงหน่วยความจำของผู้ใช้ทั้งหมด เมื่อใช้ pKVM ระบบจะยกเลิกการแมปหน่วยความจำของเครื่องเสมือนจากพื้นที่ที่อยู่จริงของโฮสต์เมื่อมีการบริจาค ให้กับเครื่องเสมือน ข้อยกเว้นเพียงอย่างเดียวคือหน่วยความจำที่แขกแชร์กลับมาอย่างชัดเจน เช่น สำหรับอุปกรณ์ Virtio

ระบบจะไม่แมปรีเจียน MMIO ในพื้นที่ที่อยู่ของแขก การเข้าถึงรีเจียนเหล่านี้ โดยแขกจะถูกดักจับและส่งผลให้เกิดเหตุการณ์ I/O ใน FD ของ VM กลไกนี้ใช้เพื่อติดตั้งใช้งานอุปกรณ์เสมือน ในโหมดที่ได้รับการปกป้อง แขกรับเชิญ ต้องรับทราบว่าระบบจะใช้ภูมิภาคของพื้นที่ที่อยู่สำหรับ MMIO โดยใช้ ไฮเปอร์คอล เพื่อลดความเสี่ยงที่ข้อมูลจะรั่วไหลโดยไม่ตั้งใจ

การตั้งเวลา

CPU เสมือนแต่ละรายการจะแสดงด้วยเธรด POSIX และกำหนดเวลาโดยตัวกำหนดเวลา Linux ของโฮสต์ เธรดจะเรียก KVM_RUN ioctl ใน vCPU FD ซึ่งส่งผลให้ ไฮเปอร์ไวเซอร์เปลี่ยนไปใช้บริบท vCPU ของแขก ตัวกำหนดเวลาโฮสต์ จะพิจารณาเวลาที่ใช้ในบริบทของแขกเป็นเวลาที่ใช้โดยเธรด vCPU ที่เกี่ยวข้อง KVM_RUN จะส่งคืนเมื่อมีเหตุการณ์ที่ VMM ต้องจัดการ เช่น I/O, สิ้นสุดการขัดจังหวะ หรือ vCPU หยุดทำงาน VMM จะจัดการ เหตุการณ์และเรียกใช้ KVM_RUN อีกครั้ง

ในระหว่าง KVM_RUN ตัวจัดกำหนดการของโฮสต์จะยังคงขัดจังหวะเธรดได้ ยกเว้น การดำเนินการโค้ดไฮเปอร์ไวเซอร์ EL2 ซึ่งขัดจังหวะไม่ได้ pVM ของแขกรับเชิญ ไม่มีกลไกในการควบคุมลักษณะการทำงานนี้

เนื่องจากมีการกำหนดเวลาเธรด vCPU ทั้งหมดเหมือนกับงานในพื้นที่ผู้ใช้อื่นๆ จึง ขึ้นอยู่กับกลไก QoS มาตรฐานทั้งหมด กล่าวคือ แต่ละเธรด vCPU สามารถ เชื่อมโยงกับ CPU จริง วางไว้ใน cpusets เพิ่มประสิทธิภาพหรือจำกัดโดยใช้ การหน่วงการใช้งาน เปลี่ยนนโยบายลำดับความสำคัญ/การจัดกำหนดการ และอื่นๆ

อุปกรณ์เสมือน

crosvm รองรับอุปกรณ์หลายอย่าง ซึ่งรวมถึงอุปกรณ์ต่อไปนี้

  • virtio-blk สำหรับอิมเมจดิสก์แบบคอมโพสิต แบบอ่านอย่างเดียวหรืออ่าน-เขียน
  • vhost-vsock สำหรับการสื่อสารกับโฮสต์
  • virtio-pci เป็นการรับส่ง virtio
  • นาฬิกาแบบเรียลไทม์ (RTC) pl030
  • UART 16550a สำหรับการสื่อสารแบบอนุกรม

เฟิร์มแวร์ pVM

เฟิร์มแวร์ pVM (pvmfw) เป็นโค้ดแรกที่ pVM ดำเนินการ ซึ่งคล้ายกับ ROM การบูตของอุปกรณ์จริง เป้าหมายหลักของ pvmfw คือการเริ่มต้น การบูตที่ปลอดภัยและรับค่าลับที่ไม่ซ้ำกันของ pVM pvmfw ไม่ได้จำกัดการใช้งาน กับระบบปฏิบัติการใดๆ โดยเฉพาะ เช่น Microdroid ตราบใดที่ระบบปฏิบัติการนั้นรองรับ โดย crosvm และได้รับการลงนามอย่างถูกต้อง

ไบนารี pvmfw จะจัดเก็บอยู่ในพาร์ติชันแฟลชที่มีชื่อเดียวกันและจะ อัปเดตโดยใช้ OTA

การเปิดเครื่องอุปกรณ์

ระบบจะเพิ่มลำดับขั้นตอนต่อไปนี้ลงในขั้นตอนการบูตของ อุปกรณ์ที่เปิดใช้ pKVM

  1. โปรแกรม Bootloader ของ Android (ABL) จะโหลด pvmfw จากพาร์ติชันลงในหน่วยความจำและยืนยันอิมเมจ
  2. ABL จะรับข้อมูลลับของ Device Identifier Composition Engine (DICE) (ตัวระบุอุปกรณ์แบบรวม (CDI) และห่วงโซ่ใบรับรอง DICE) จากรูทของความน่าเชื่อถือ
  3. ABL จะได้รับ CDI ที่จำเป็นสำหรับ pvmfw และต่อท้าย CDI เหล่านั้นกับไบนารี pvmfw
  4. ABL จะเพิ่มโหนดlinux,pkvm-guest-firmware-memory reserved memory region ลงใน DT ซึ่งอธิบายตำแหน่งและขนาดของไบนารี pvmfw และ ข้อมูลลับที่ได้มาจากขั้นตอนก่อนหน้า
  5. ABL จะส่งต่อการควบคุมไปยัง Linux และ Linux จะเริ่มต้น pKVM
  6. pKVM จะยกเลิกการแมปภูมิภาคหน่วยความจำ pvmfw จากตารางหน้าของระยะที่ 2 ของโฮสต์และ ปกป้องจากโฮสต์ (และแขก) ตลอดระยะเวลาที่อุปกรณ์ทำงาน

หลังจากเปิดเครื่องอุปกรณ์แล้ว Microdroid จะเริ่มทำงานตามขั้นตอนในส่วนลำดับการบูตของเอกสารMicrodroid

การบูต pVM

เมื่อสร้าง pVM, crosvm (หรือ VMM อื่น) ต้องสร้าง memslot ที่มีขนาดใหญ่เพียงพอ เพื่อให้ไฮเปอร์ไวเซอร์ป้อนข้อมูลอิมเมจ pvmfw นอกจากนี้ VMM ยัง ถูกจำกัดในรายการรีจิสเตอร์ที่มีค่าเริ่มต้นที่สามารถตั้งค่าได้ (x0-x14 สำหรับ vCPU หลัก และไม่มีสำหรับ vCPU รอง) รีจิสเตอร์ที่เหลือจะ สงวนไว้และเป็นส่วนหนึ่งของ ABI ของไฮเปอร์ไวเซอร์-pvmfw

เมื่อเรียกใช้ pVM ไฮเปอร์ไวเซอร์จะส่งการควบคุม vCPU หลัก ให้กับ pvmfw ก่อน เฟิร์มแวร์คาดหวังว่า crosvm จะโหลดเคอร์เนลที่ลงนาม AVB ซึ่งอาจเป็น Bootloader หรืออิมเมจอื่นๆ และ FDT ที่ไม่ได้ลงนามลงในหน่วยความจำที่ออฟเซ็ตที่รู้จัก pvmfw จะตรวจสอบลายเซ็น AVB และหากสำเร็จ จะสร้างแผนผังอุปกรณ์ที่เชื่อถือได้จาก FDT ที่ได้รับ ล้างข้อมูลลับออกจากหน่วยความจำ และแยกไปยังจุดแรกเข้าของเพย์โหลด หากขั้นตอนการยืนยันขั้นตอนใดขั้นตอนหนึ่งไม่สำเร็จ เฟิร์มแวร์จะออก SYSTEM_RESET ไฮเปอร์คอล PSCI

ระหว่างการบูต ระบบจะจัดเก็บข้อมูลเกี่ยวกับอินสแตนซ์ pVM ไว้ในพาร์ติชัน (อุปกรณ์ virtio-blk) และเข้ารหัสด้วยความลับของ pvmfw เพื่อให้แน่ใจว่าหลังจากการรีบูต ระบบจะจัดสรรความลับให้กับอินสแตนซ์ที่ถูกต้อง