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

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

ฉากหลัง

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

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

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

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

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

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

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

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

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

รูปต่อไปนี้แสดงขั้นตอนการเปิดเครื่อง pKVM

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

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

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

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

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

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

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

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

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

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

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

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

KVM ใช้การแปลที่อยู่อย่างเต็มประสิทธิภาพในขั้นตอนที่ 2 เพื่อใช้การแมป IPA/PA ที่ซับซ้อนสำหรับผู้มาเยือน ซึ่งสร้างภาพลวงตาความทรงจำต่อเนื่องสำหรับผู้เข้าร่วมแม้จะกระจัดกระจายทางกายภาพก็ตาม อย่างไรก็ตาม การใช้งาน MMU ขั้นที่ 2 สำหรับโฮสต์จะถูกจำกัดไว้เฉพาะการควบคุมการเข้าถึงเท่านั้น ขั้นที่ 2 ของโฮสต์มีการแมปข้อมูลประจำตัวเพื่อให้แน่ใจว่าหน่วยความจำที่ต่อเนื่องในพื้นที่ IPA ของโฮสต์อยู่ติดกันในพื้นที่ PA สถาปัตยกรรมนี้ช่วยให้ใช้การแมปขนาดใหญ่ในตารางหน้าได้ ซึ่งช่วยลดแรงกดของบัฟเฟอร์ฝั่งหน้าการแปล (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 ซึ่งมีทั้งการแยกและการกำหนดโดยตรงได้ก็คือสถาปัตยกรรม Arm System Memory Management Unit (SMMU) สถาปัตยกรรมนี้เป็นโซลูชันการอ้างอิงที่แนะนำ

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

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

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

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

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

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

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

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

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

การสนับสนุน GICv3

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

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

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

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

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

การจัดการ MMIO

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

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

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

อินเทอร์เฟซของผู้มาเยือน

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

ไฮเปอร์คอลทั่วไป

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

ไฮเปอร์คอลของ pKVM

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

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

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

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

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

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

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

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

แม้ว่าผู้มาเยือนจะไม่สามารถโต้ตอบกับ TrustZone ได้โดยตรง แต่โฮสต์ก็ยังคงต้องสามารถออกการเรียก SMC ไปยังระบบที่ปลอดภัยได้ การเรียกเหล่านี้สามารถระบุบัฟเฟอร์หน่วยความจำที่ระบุจริงซึ่งโฮสต์ไม่สามารถเข้าถึงได้ เนื่องจากซอฟต์แวร์ที่ปลอดภัยมักไม่ทราบถึงความสามารถในการเข้าถึงของบัฟเฟอร์ โฮสต์ที่ไม่หวังดีสามารถใช้บัฟเฟอร์นี้เพื่อทำการโจมตีผู้ช่วยแบบสับสน (คล้ายกับการโจมตี DMA) เพื่อป้องกันการโจมตีดังกล่าว pKVM จะดักจับการเรียก SMC ทั้งหมดของโฮสต์ไปยัง EL2 และทำหน้าที่เป็นพร็อกซีระหว่างโฮสต์กับจอภาพที่ปลอดภัยที่ 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 ด้วย Ioctls ที่ประกอบขึ้นเป็น KVM API Ioctls จะอยู่ในหมวดหมู่ต่อไปนี้

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

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

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

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

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

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

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

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

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

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

การกำหนดเวลา

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

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

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

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

crosvm รองรับอุปกรณ์ดังต่อไปนี้

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

เฟิร์มแวร์ pVM

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

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

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

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

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

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

การเปิดเครื่อง pVM

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

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

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