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 เช่น Keystore สำหรับการดำเนินการเข้ารหัสด้วยคีย์อิงฮาร์ดแวร์ โดยรวมแล้ว นักพัฒนาแอปควรจะพบว่า 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

• HALs

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

Microdroid มีลักษณะคล้ายกับ Cuttlefish ตรงที่ทั้ง 2 อย่างมีสถาปัตยกรรมที่ คล้ายกับ 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 จะเกิดขึ้นหลังจากการบูตอุปกรณ์ การบูตอุปกรณ์ จะอธิบายไว้ในส่วนเฟิร์มแวร์ pVM ของเอกสารสถาปัตยกรรม รูปที่ 1 แสดงขั้นตอนที่เกิดขึ้นระหว่างลำดับการบูต Microdroid

คำอธิบายขั้นตอนมีดังนี้

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

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

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

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

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

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

5. init กระบวนการจะเริ่มตัวจัดการ Microdroid ซึ่งเข้าถึงอิมเมจอินสแตนซ์ บริการตัวจัดการ 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 ประเภทใน AIDL) โดยมีการควบคุมการเข้าถึงโดยเคอร์เนล 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 ของเคอร์เนล