Microdroid

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

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

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

ฟีเจอร์

Microdroid เป็น Android เวอร์ชันที่ตัดองค์ประกอบบางอย่างออกและมีคอมโพเนนต์เพิ่มเติมอีก 2-3 อย่างสำหรับ pVM โดยเฉพาะ Microdroid รองรับการดำเนินการต่อไปนี้

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

Microdroid ไม่รองรับรายการต่อไปนี้

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

• SystemServer และ Zygote

• กราฟิก/UI

• HAL

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

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

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

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

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

ลำดับการบูต

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

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

1. crosvm จะโหลดบูตโหลดเดอร์ลงในหน่วยความจำและ pvmfw เริ่มทำงาน pvmfw จะทํางาน 2 อย่างก่อนข้ามไปยังบูตโหลดเดอร์

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

   จากนั้น Bootloader จะบูต Microdroid

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

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

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

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

6. บริการตัวจัดการ Microdroid จะเริ่มในวันที่ apexd

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

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

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

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

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

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

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

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

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

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

Binder RPC

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

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