ไมโครดรอยด์

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 โดยเฉพาะ ไมโครดรอยด์รองรับ:

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

Microdroid ไม่รองรับ:

• Android Java APIs ในแพ็คเกจ android.\*

• SystemServer และไซโกต

• กราฟิก/UI

• HAL

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

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

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

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

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

ลำดับการบูต

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

ต่อไปนี้เป็นคำอธิบายขั้นตอนต่างๆ:

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

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

   bootloader จะบู๊ต Microdroid

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

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

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

5. กระบวนการ init จะเริ่มต้นตัวจัดการ Microdroid ซึ่งเข้าถึงอิมเมจอินสแตนซ์ บริการตัวจัดการ 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 จะสร้างออบเจ็กต์ RpcServer ลงทะเบียนออบเจ็กต์รูท และเริ่มฟังการเชื่อมต่อใหม่ ไคลเอนต์สามารถเชื่อมต่อกับเซิร์ฟเวอร์นี้โดยใช้ออบเจ็กต์ RpcSession รับออบเจ็กต์ Binder และใช้ออบเจ็กต์นั้นเหมือนกับที่ออบเจ็กต์ Binder ใช้กับไดรเวอร์เคอร์เนล Binder