ไมโครดรอยด์

Microdroid เป็นระบบปฏิบัติการ Android ขนาดเล็กที่ทำงานใน pVM คุณไม่จำเป็นต้องใช้ Microdroid คุณสามารถเริ่ม VM กับระบบปฏิบัติการใดก็ได้ อย่างไรก็ตาม กรณีการใช้งานหลักสำหรับ pVM ไม่ได้ใช้งานระบบปฏิบัติการแบบสแตนด์อโลน แต่ให้สภาพแวดล้อมการทำงานแบบแยกส่วนสำหรับการเรียกใช้ส่วนหนึ่งของแอปที่มีการรักษาความลับและการรับประกันความสมบูรณ์ที่เข้มงวดกว่า Android

สำหรับระบบปฏิบัติการแบบเดิม การรักษาความลับและความสมบูรณ์ที่เข้มงวดนั้นต้องใช้ปริมาณงานพอสมควร (มักจะทำซ้ำ) เนื่องจากระบบปฏิบัติการแบบเดิมไม่เหมาะกับสถาปัตยกรรม Android ที่ครอบคลุม ตัวอย่างเช่น ด้วยสถาปัตยกรรม Android มาตรฐาน นักพัฒนาจำเป็นต้องใช้วิธีการโหลดและดำเนินการส่วนหนึ่งของแอปอย่างปลอดภัยใน pVM และเพย์โหลดสร้างขึ้นจาก glibc แอป Android ใช้ Bionic การสื่อสารต้องใช้โปรโตคอลที่กำหนดเองผ่าน vsock และการดีบักโดยใช้ adb เป็นสิ่งที่ท้าทาย

Microdroid เติมเต็มช่องว่างเหล่านี้ด้วยการจัดเตรียมอิมเมจระบบปฏิบัติการนอกชั้นวางที่ออกแบบมาเพื่อให้นักพัฒนาต้องใช้ความพยายามน้อยที่สุดในการโหลดส่วนหนึ่งของแอปลงใน pVM โค้ดเนทีฟสร้างขึ้นเพื่อต่อต้าน Bionic การสื่อสารเกิดขึ้นผ่าน Binder และอนุญาตให้นำเข้า APEX จาก Android และเปิดเผยชุดย่อยของ Android API เช่น ที่เก็บคีย์สำหรับการดำเนินการเข้ารหัสด้วยคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์ โดยรวมแล้ว นักพัฒนาซอฟต์แวร์ควรพบว่า Microdroid เป็นสภาพแวดล้อมที่คุ้นเคยด้วยเครื่องมือที่พวกเขาคุ้นเคยในระบบปฏิบัติการ Android เต็มรูปแบบ

คุณสมบัติ

Microdroid เป็น Android เวอร์ชันเก่าที่มีส่วนประกอบเพิ่มเติมเฉพาะสำหรับ pVM Microdroid รองรับ:

• ชุดย่อยของ NDK API (มี API ทั้งหมดสำหรับการใช้งาน libc และ Bionic ของ Android)
• คุณสมบัติการดีบัก เช่น adb, logcat, tombstone และ gdb
• เปิดใช้งาน Verified Boot และ SELinux แล้ว
• กำลังโหลดและดำเนินการไบนารีพร้อมกับไลบรารีที่แชร์ซึ่งฝังอยู่ใน APK
• Binder RPC เหนือ vsock และแลกเปลี่ยนไฟล์ด้วยการตรวจสอบความสมบูรณ์โดยปริยาย
• กำลังโหลด APEXes

Microdroid ไม่รองรับ:

• Android Java APIs ใน android.\* packages

  หมายเหตุ: Core Java APIs ในแพ็คเกจ java.\* สามารถสนับสนุนได้โดยการเปิดใช้งาน ART APEX ใน VM

• SystemServer และ Zygote

• กราฟิก/UI

• HALs

สถาปัตยกรรมไมโครดรอยด์

Microdroid นั้นคล้ายกับ Cuttlefish โดยที่ทั้งคู่มีสถาปัตยกรรมที่คล้ายกับ Android มาตรฐาน Microdroid ประกอบด้วยอิมเมจพาร์ติชั่นต่อไปนี้ซึ่งจัดกลุ่มเข้าด้วยกันในอิมเมจดิสก์คอมโพสิต:

• bootloader - ตรวจสอบและเริ่มต้นเคอร์เนล
• boot.img - ประกอบด้วยเคอร์เนลและ init ramdisk
• vendor\_boot.img - ประกอบด้วยโมดูลเคอร์เนลเฉพาะของ VM เช่น virtio
• super.img - ประกอบด้วยระบบและโลจิคัลพาร์ติชันของผู้ขาย
• vbmeta.img - มีข้อมูลเมตาการบูตที่ตรวจสอบแล้ว

อิมเมจของพาร์ติชันจัดส่งใน Virtualization APEX และจัดแพ็กเกจเป็นอิมเมจดิสก์คอมโพสิตโดย VirtualizationService นอกเหนือจากอิมเมจดิสก์คอมโพสิต OS หลัก VirtualizationService ยังรับผิดชอบในการสร้างพาร์ติชันอื่นๆ เหล่านี้:

• payload - ชุดของพาร์ติชั่นที่สนับสนุนโดย APEXes และ APK ของ Android
• instance - พาร์ติชั่นที่เข้ารหัสสำหรับการคงอยู่ต่อข้อมูลการบูตที่ยืนยันต่ออินสแตนซ์ เช่น เกลือต่ออินสแตนซ์ คีย์สาธารณะ APEX ที่เชื่อถือได้ และตัวนับย้อนกลับ

ลำดับการบูต

ลำดับการบู๊ต Microdroid เกิดขึ้นหลังจาก Device boot มีการกล่าวถึงการบู๊ตอุปกรณ์ในเอกสาร สถาปัตยกรรม รูปที่ 1 แสดงขั้นตอนที่เกิดขึ้นระหว่างลำดับการบู๊ต Microdroid:

รูปที่ 1. บูตโฟลว์ที่ปลอดภัยของอินสแตนซ์ microdroid

นี่คือคำอธิบายของขั้นตอน:

1. bootloader ถูกโหลดเข้าสู่หน่วยความจำโดย crossvm และ pvmfw เริ่มดำเนินการ ก่อนข้ามไปที่ bootloader pvmfw ดำเนินการสองอย่าง:

   • ตรวจสอบโปรแกรมโหลดบูตเพื่อตรวจสอบว่ามาจากแหล่งที่เชื่อถือได้ (Google หรือ OEM)
   • ตรวจสอบให้แน่ใจว่ามีการใช้ bootloader เดียวกันอย่างสม่ำเสมอในการบู๊ต pVM เดียวกันหลายครั้งผ่านการใช้อิมเมจอินสแตนซ์ โดยเฉพาะอย่างยิ่ง pVM ถูกบูตด้วยอิมเมจอินสแตนซ์ที่ว่างเปล่าในขั้นต้น pvmfw เก็บข้อมูลประจำตัวของ bootloader ในอิมเมจอินสแตนซ์และเข้ารหัส ดังนั้น ในครั้งต่อไปที่ pVM ถูกบู๊ตด้วยอิมเมจอินสแตนซ์เดียวกัน pvmfw จะถอดรหัสข้อมูลประจำตัวที่บันทึกไว้จากอิมเมจอินสแตนซ์และยืนยันว่าเป็นข้อมูลเดียวกันกับที่เคยบันทึกไว้ก่อนหน้านี้ หากข้อมูลประจำตัวต่างกัน pvmfw ปฏิเสธที่จะบูต

   bootloader ทำการบู๊ต Microdroid

2. bootloader เข้าถึงดิสก์อินสแตนซ์ เช่นเดียวกับ pvmfw bootloader มีดิสก์ไดรฟ์อินสแตนซ์ที่มีข้อมูลเกี่ยวกับอิมเมจพาร์ติชั่นที่ใช้ในอินสแตนซ์นี้ระหว่างการบู๊ตครั้งก่อน รวมถึงคีย์สาธารณะ

3. bootloader ตรวจสอบ vbmeta และพาร์ติชั่นลูกโซ่ เช่น boot และ super และหากสำเร็จ จะได้ความลับ pVM ขั้นถัดไป จากนั้น Microdroid จะควบคุมเคอร์เนล

4. เนื่องจาก super partition ได้รับการตรวจสอบแล้วโดย bootloader (ขั้นตอนที่ 3) เคอร์เนลจึงติดตั้ง super partition โดยไม่มีเงื่อนไข เช่นเดียวกับ Android แบบเต็ม ซูเปอร์พาร์ติชั่นประกอบด้วยโลจิคัลพาร์ติชั่นหลายตัวที่ติดตั้งบน dm-verity จากนั้นการควบคุมจะถูกส่งไปยังกระบวนการ init ซึ่งเริ่มบริการเนทีฟต่างๆ สคริปต์ init.rc นั้นคล้ายกับสคริปต์ของ Android เต็มรูปแบบ แต่ปรับให้เข้ากับความต้องการของ Microdroid

5. กระบวนการเริ่มต้นเริ่มต้นตัวจัดการ init ซึ่งเข้าถึงอิมเมจอินสแตนซ์ บริการตัวจัดการ Microdroid ถอดรหัสรูปภาพโดยใช้คีย์ที่ส่งผ่านจากขั้นตอนก่อนหน้า และอ่านคีย์สาธารณะและตัวนับย้อนกลับของ APK และ APEX ของไคลเอ็นต์ที่ pVM เชื่อถือ ข้อมูลนี้ถูกใช้ในภายหลังโดย zipfuse และ apexd เมื่อติดตั้ง APK ของไคลเอ็นต์และร้องขอ APEX ตามลำดับ

6. บริการตัวจัดการ Microdroid เริ่มต้น apexd

7. apexd ติดตั้ง APEXes ที่ไดเร็กทอรี /apex/<name> ข้อแตกต่างเพียงอย่างเดียวระหว่างวิธีที่ Android และ Microdroid mounta APEXes คือใน Microdroid ไฟล์ APEX นั้นมาจากอุปกรณ์บล็อกเสมือน ( /dev/vdc1 , …) ไม่ใช่จากไฟล์ปกติ ( /system/apex/*.apex )

8. zipfuse เป็นระบบไฟล์ FUSE ของ Microdroid zipfuse ติดตั้ง APK ของไคลเอ็นต์ซึ่งโดยพื้นฐานแล้วเป็นไฟล์ Zip เป็นระบบไฟล์ ด้านล่าง ไฟล์ APK จะถูกส่งผ่านเป็นอุปกรณ์บล็อกเสมือนโดย pVM ที่มี dm-verity เช่นเดียวกับ APEX APK มีไฟล์กำหนดค่าพร้อมรายการ APEX ที่นักพัฒนาแอปร้องขอสำหรับอินสแตนซ์ pVM นี้ รายการถูกใช้โดย apexd เมื่อเปิดใช้งาน APEX

9. ขั้นตอนการบู๊ตจะกลับสู่บริการตัวจัดการ Microdroid จากนั้น บริการผู้จัดการจะสื่อสารกับ VirtualizationService ของ Android โดยใช้ Binder RPC เพื่อให้สามารถรายงานเหตุการณ์สำคัญ เช่น ข้อขัดข้องหรือการปิดระบบ และยอมรับคำขอ เช่น การยกเลิก pVM บริการผู้จัดการจะอ่านตำแหน่งของไบนารีหลักจากไฟล์ปรับแต่งของ APK และดำเนินการ

การแลกเปลี่ยนไฟล์ (AuthFS)

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

โดยพื้นฐานแล้ว AuthFS เป็นระบบไฟล์ระยะไกลที่มีการตรวจสอบความสมบูรณ์ที่โปร่งใสในการดำเนินการเข้าถึงแต่ละรายการ คล้ายกับ fs-verity การตรวจสอบช่วยให้ฟรอนท์เอนด์ เช่น โปรแกรมอ่านไฟล์ที่ทำงานใน pVM ตรวจพบว่าแบ็กเอนด์ที่ไม่น่าเชื่อถือ ซึ่งโดยทั่วไปคือ Android ถูกดัดแปลงเนื้อหาไฟล์หรือไม่

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

ปัจจุบันการขนส่งพื้นฐานอิงตาม Binder RPC อย่างไรก็ตาม อาจมีการเปลี่ยนแปลงในอนาคตเพื่อเพิ่มประสิทธิภาพการทำงาน

การจัดการคีย์

pVM มี คีย์การปิดผนึก ที่เสถียรซึ่งเหมาะสำหรับข้อมูลถาวรที่มีการป้องกัน และ คีย์การรับรอง ซึ่งเหมาะสำหรับการสร้างลายเซ็นที่ pVM สร้างขึ้นที่ตรวจสอบยืนยันได้

เครื่องผูก RPC

อินเทอร์เฟซของ Android ส่วนใหญ่แสดงเป็น AIDL ซึ่งสร้างขึ้นบนไดรเวอร์เคอร์เนล Binder Linux เพื่อสนับสนุนอินเทอร์เฟซระหว่าง pVM โปรโตคอล Binder ได้รับการเขียนใหม่เพื่อทำงานบนซ็อกเก็ต vsock ในกรณีของ pVM การใช้งานผ่านซ็อกเก็ตช่วยให้สามารถใช้อินเทอร์เฟซ AIDL ที่มีอยู่ของ Android ในสภาพแวดล้อมใหม่นี้ได้

ในการตั้งค่าการเชื่อมต่อ จุดปลายหนึ่งจุด เช่น pVM payload จะสร้างวัตถุ RpcServer ลงทะเบียนวัตถุราก และเริ่มรับฟังการเชื่อมต่อใหม่ ลูกค้าสามารถเชื่อมต่อกับเซิร์ฟเวอร์นี้โดยใช้วัตถุ RpcSession รับวัตถุ Binder และใช้งานได้เหมือนกับวัตถุ Binder ที่ใช้กับไดรเวอร์เคอร์เนล Binder