แพตช์ RFC ชุดใหม่ที่เสนอการสนับสนุนสถาปัตยกรรม multikernel สำหรับ Linux ได้จุดประกายการอภิปรายอย่างเข้มข้นในชุมชนนักพัฒนาเกี่ยวกับความเป็นไปได้และผลกระทบด้านความปลอดภัย ข้อเสนอนี้ซึ่งจะอนุญาตให้ kernel หลายตัวที่เป็นอิสระทำงานพร้อมกันบน CPU core ที่แตกต่างกันในขณะที่แบ่งปันทรัพยากรฮาร์ดแวร์ สัญญาว่าจะให้ประโยชน์เช่นการแยก fault ที่ดีขึ้นและการใช้ทรัพยากรที่ดีกว่าเมื่อเปรียบเทียบกับ virtualization แบบดั้งเดิม
องค์ประกอบหลักของสถาปัตยกรรม Multikernel
- ระบบย่อย kexec ที่ได้รับการปรับปรุง: การติดตามและจัดการอิมเมจเคอร์เนลแบบไดนามิก
- เฟรมเวิร์ก IPI แบบทั่วไป: การสื่อสารและส่งข้อความระหว่างเคอร์เนล
- กลไกการบูตสตราป CPU: การสนับสนุนเฉพาะสถาปัตยกรรม (ปัจจุบันรองรับเฉพาะ x86 เท่านั้น)
- อินเทอร์เฟซ Proc:
/proc/multikernelสำหรับตรวจสอบอินสแตนซ์ที่โหลดแล้ว - เวกเตอร์การสื่อสار: MULTIKERNEL_VECTOR เฉพาะสำหรับการสื่อสารระหว่างเคอร์เนลใน x86
ข้อกังวลเรื่องการแบ่งปันทรัพยากรฮาร์ดแวร์ครองใจการอภิปราย
ประเด็นที่ถกเถียงกันมากที่สุดของข้อเสนอนี้มุ่งเน้นไปที่วิธีที่ kernel หลายตัวจะแบ่งปันทรัพยากรฮาร์ดแวร์โดยไม่เกิดความขัดแย้ง สมาชิกชุมชนได้แสดงความกังวลอย่างมากเกี่ยวกับอุปกรณ์ที่พึ่งพา state-keeping และ serialization ในไดรเวอร์ของพวกเขา ความท้าทายจะรุนแรงเป็นพิเศษกับอุปกรณ์ต่อพ่วงที่ซับซ้อนเช่นอุปกรณ์ USB และ Bluetooth ซึ่งผู้จำหน่ายโดยทั่วไปไม่ทดสอบสำหรับลำดับคำสั่งที่สลับกันหลายตัวจาก kernel instance ที่แตกต่างกัน
นักพัฒนาบางคนแนะนำแนวทางแบบลำดับชั้นที่ kernel หลักจะเป็นเจ้าของฮาร์ดแวร์สำคัญในขณะที่ kernel อื่นๆ สื่อสารผ่านช่องทางเฉพาะ อย่างไรก็ตาม สิ่งนี้สร้างจุดล้มเหลวเดียวที่ทำลายประโยชน์ที่สัญญาไว้บางอย่าง โดยเฉพาะสำหรับการแยก fault และการอัปเดต kernel แบบ zero-downtime
หมายเหตุ: State-keeping หมายถึงฮาร์ดแวร์ที่รักษาข้อมูลสถานะภายใน ในขณะที่ serialization หมายถึงการประมวลผลคำสั่งทีละครั้งตามลำดับที่เฉพาะเจาะจง
โมเดลความปลอดภัยทำให้เกิดคำถามเกี่ยวกับการแยก
ผลกระทบด้านความปลอดภัยของแนวทาง multikernel ได้จุดประกายการถกเถียงอย่างมาก ต่างจาก virtualization แบบดั้งเดิมที่พึ่งพาการแยกที่ช่วยด้วยฮาร์ดแวร์ โมเดลแบบร่วมมือนี้สันนิษฐานว่า kernel ทั้งหมดที่โหลดเป็นที่เชื่อถือได้ นักวิจารณ์ชี้ให้เห็นว่า kernel ที่ถูกบุกรุกบน core หนึ่งอาจสามารถ hijack core อื่นๆ ได้ โดยตั้งคำถามว่าสิ่งนี้ให้ขอบเขตความปลอดภัยที่มีความหมายหรือไม่
ผู้สนับสนุนโต้แย้งว่าแม้สถาปัตยกรรมจะไม่ป้องกันการโจมตีการดำเนินโค้ด แต่ก็สามารถจำกัดขอบเขตของการใช้ประโยชน์ทั่วไปเช่นช่องโหว่ syscall หรือการโจมตี memory mapping การแยกจะเป็นเรื่องของการจำกัดความเสียหายที่เกิดขึ้นโดยบังเอิญและการจำกัดผลกระทบของการใช้ประโยชน์มากกว่าการให้การรับประกันความปลอดภัยระดับ VM
ประโยชน์ที่อ้างว่ามี เทียบกับ ข้อกังวลของชุมชน
| ประโยชน์ที่อ้างว่ามี | ข้อกังวลของชุมชน |
|---|---|
| การแยกข้อผิดพลาดที่ดีขึ้น | สถานะฮาร์ดแวร์ขัดแย้งกับอุปกรณ์ที่ใช้ร่วมกัน |
| ความปลอดภัยที่เพิ่มขึ้นผ่านการแยกส่วน | ขอบเขตความปลอดภัยที่อ่อนแอเมื่อเทียบกับ VMs |
| การใช้ทรัพยากรที่ดีกว่า VMs | จุดเสียหายเดียวที่ส่งผลต่อทั้งระบบกับเคอร์เนล "หลัก" |
| การอัปเดตเคอร์เนลแบบไม่หยุดทำงาน ( KHO ) | การทดสอบที่จำกัดบนฮาร์ดแวร์ที่หลากหลาย |
| การทำงานร่วมกันของเคอร์เนลแบบเรียลไทม์และใช้งานทั่วไป | ความต้องการในการประสานงานไดรเวอร์ที่ซับซ้อน |
การเปรียบเทียบกับแนวทางในอดีตและทางเลือกอื่น
ข้อเสนอนี้ได้รับการเปรียบเทียบกับระบบในอดีตและโครงการวิจัยหลายแห่ง สมาชิกชุมชนสังเกตเห็นความคล้ายคลึงกับ OpenVMS Galaxy บนระบบ DEC Alpha , พาร์ติชัน IBM mainframe และระบบปฏิบัติการวิจัย Barrelfish การเปรียบเทียบเหล่านี้เน้นย้ำว่าแม้แนวคิดจะไม่ใหม่โดยสิ้นเชิง แต่การนำไปใช้ให้สำเร็จใน production kernel เช่น Linux นำเสนอความท้าทายที่เป็นเอกลักษณ์
ไม่มีทางที่เช่น ผู้จำหน่าย usb หรือ bluetooth โดยเฉลี่ยจะมี 'ลำดับคำสั่งที่สลับกันหลายตัว' ในการตั้งค่าการทดสอบของพวกเขา
การอภิปรายยังสัมผัสกับว่าแนวทางนี้ให้ข้อได้เปรียบเหนือเทคโนโลยี containerization ที่มีอยู่หรือ hardware virtualization หรือไม่ ในขณะที่สถาปัตยกรรม multikernel สามารถให้ประสิทธิภาพที่ดีกว่า VM โดยการกำจัด hypervisor overhead แต่ก็สละการรับประกันการแยกที่แข็งแกร่งที่ทำให้ virtualization น่าสนใจสำหรับ workload ที่ต้องการความปลอดภัยสูง
ความท้าทายในการนำไปใช้และแนวโน้มในอนาคต
ลักษณะ RFC ของแพตช์ชุดนี้ยอมรับว่ายังมีงานสำคัญที่เหลืออยู่ก่อนที่เทคโนโลยีจะพร้อมสำหรับการใช้งานจริง การนำไปใช้ปัจจุบันสนับสนุนเฉพาะสถาปัตยกรรม x86 และได้รับการทดสอบบนการกำหนดค่าฮาร์ดแวร์ที่จำกัด สมาชิกชุมชนเน้นย้ำว่าการทดสอบอย่างกว้างขวางในแพลตฟอร์มต่างๆ จะมีความสำคัญต่อการระบุปัญหาที่อาจเกิดขึ้น
ประวัติของผู้เขียนที่ Bytedance และการมีส่วนร่วมในเทคโนโลยี kernel อื่นๆ เช่น kernelscript ได้สร้างความมองโลกในแง่ดีอย่างระมัดระวังเกี่ยวกับศักยภาพของโครงการ อย่างไรก็ตาม นักพัฒนาหลายคนยังคงสงสัยว่าประโยชน์จะสมเหตุสมผลกับความซับซ้อนและปัญหาความน่าเชื่อถือที่อาจเกิดขึ้นหรือไม่ โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงความสมบูรณ์ของโซลูชัน virtualization ที่มีอยู่
สถาปัตยกรรม multikernel แสดงถึงจุดกึ่งกลางที่น่าสนใจระหว่างประสิทธิภาพ bare-metal และการแยก virtualized แต่ความสำเร็จของมันจะขึ้นอยู่กับการแก้ไขความท้าทายพื้นฐานของการแบ่งปันฮาร์ดแวร์แบบร่วมมือและการรักษาความเสถียรของระบบใน kernel instance หลายตัวในท้ายที่สุด
อ้างอิง: [RFC Patch 0/7] kernel: Introduce multikernel architecture support