Asterinas - โครงการเคอร์เนลใหม่ที่เข้ากันได้กับ Linux

 (lwn.net)
8 คะแนน โดย GN⁺ 2025-06-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นเคอร์เนลใหม่ที่เข้ากันได้กับ Linux ABI เขียนด้วย Rust และนำสถาปัตยกรรม “framekernel” มาใช้เพื่อผสานข้อดีของ monolithic kernel และ microkernel
  • ออกแบบให้ห่อหุ้มโค้ด unsafe ทั้งหมดไว้ภายในไลบรารีที่มีขอบเขตจำกัด เพื่อให้บริการเคอร์เนลส่วนที่เหลือพัฒนาได้ด้วย abstraction ของ Rust ที่ปลอดภัย จึงบรรลุทั้งความปลอดภัยด้านหน่วยความจำและโครงสร้าง shared memory ที่เรียบง่ายไปพร้อมกัน
  • จุดที่แตกต่างจาก Rust OS เดิมอย่าง RedLeaf, Tock, Rust for Linux คือ การรองรับ hardware isolation และการใช้งานแบบทั่วไป, Linux-compatible ABI, และการรัน user space ได้หลายภาษา
  • มุ่งลด TCB (trusted computing base) และผลักดันการทำ formal verification (ใช้ Verus) พร้อมรองรับฮาร์ดแวร์ trusted execution environment อย่าง Intel TDX และยังมีเฟรมเวิร์กพัฒนา OS อย่าง OSTD/OSDK แยกต่างหากด้วย
  • ยังอยู่ในช่วงพัฒนาเริ่มต้น โดยรองรับ x86/RISC-V และติดตั้ง system call แล้ว 206 รายการ เน้น Docker/คอนเทนเนอร์/สภาพแวดล้อมคลาวด์ แต่ก็เริ่มทดลองขยายไปสู่เดสก์ท็อปอย่าง X11/Xfce

Asterinas คืออะไร?

  • Asterinas คือโครงการเคอร์เนลใหม่ที่เข้ากันได้กับ Linux ABI ซึ่งพัฒนาด้วย Rust
  • สถาปัตยกรรม “framekernel” คือการจำกัดโค้ด Rust แบบ unsafe (ส่วนที่ไม่ปลอดภัยด้านหน่วยความจำ) ไว้ในไลบรารีของเฟรมเวิร์ก แล้วห่อด้วย API ที่ปลอดภัย เพื่อให้บริการเคอร์เนลส่วนที่เหลือทั้งหมดพัฒนาด้วย Rust ที่ปลอดภัย
  • มุ่งไปพร้อมกันทั้งโครงสร้างที่เรียบง่าย/ประสิทธิภาพสูงแบบ monolithic kernel และการลด TCB (trusted computing base)/ความปลอดภัยแบบ microkernel
  • ภายในเคอร์เนล บริการต่าง ๆ จะทำงานแยกจากกันภายใน address space เดียวกัน และแต่ละบริการจะใช้ได้เฉพาะทรัพยากรที่ core library มอบหมายให้เท่านั้น

คำอธิบายสถาปัตยกรรม framekernel

  • แนวคิด framekernel ถูกเสนอครั้งแรกในงานวิจัย "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation"
  • Monolithic kernel เป็นโครงสร้างที่รวมโค้ดทั้งหมดไว้ใน kernel-mode address space เดียว ส่วน microkernel จะจัดสรรพื้นที่เคอร์เนลให้เฉพาะ TCB ขั้นต่ำ และมอบหมายฟังก์ชันส่วนใหญ่ไปยังบริการใน user mode
  • Framekernel จะห่อหุ้มโค้ดที่ต้องใช้ความสามารถ unsafe ของ Rust ไว้เป็นไลบรารี และพัฒนาบริการเคอร์เนลส่วนที่เหลือด้วยabstraction ของ Rust ที่ปลอดภัยด้านหน่วยความจำ
  • แต่ละบริการรันอยู่ภายใน kernel address space แต่ถูกจำกัดให้เข้าถึงได้เฉพาะทรัพยากรที่ไลบรารีเปิดให้อย่างชัดเจน
  • การทำให้ TCB มีขนาดเล็กช่วยให้การพิสูจน์เชิงรูปแบบ (formal verification) ทำได้ง่ายขึ้น และเพิ่มความน่าเชื่อถือกับเสถียรภาพของทั้งระบบ
  • เป็นแนวทางที่ผสานทั้งshared memory-based (ประสิทธิภาพสูงแบบ monolithic kernel) และการแยกสิทธิ์ภายใน/ความปลอดภัย (ข้อดีของ microkernel)

เปรียบเทียบกับ Rust OS และ framekernel เดิม

  • RedLeaf: microkernel ที่สร้างด้วย Rust และไม่ได้ใช้ hardware isolation
  • Asterinas: OS สำหรับงานทั่วไป ใช้ hardware isolation เข้ากันได้กับ Linux ABI และรองรับการรัน user space จากหลายภาษา
  • Tock: เจาะกลุ่ม embedded SoC มีโครงสร้างแยก core (อนุญาต unsafe) กับ capsule (โค้ดปลอดภัย) และไม่รองรับ hardware isolation
  • โครงการ Rust for Linux เองก็มีเป้าหมายห่อหุ้ม kernel interface ด้วย abstraction ที่ปลอดภัย เพื่อให้เขียน kernel driver ด้วย Rust ได้อย่างปลอดภัยเช่นกัน

การพิสูจน์เชิงรูปแบบและความปลอดภัย

  • เป้าหมายหลักของการลด TCB คือเพื่อให้การตรวจพิสูจน์เชิงรูปแบบ (formal verification) เป็นสิ่งที่ทำได้จริงในทางปฏิบัติ
  • Asterinas เป็นกรณีเดียวที่ตั้งเป้าพร้อมกันทั้งTCB ขนาดเล็กที่ตรวจพิสูจน์ได้แบบ seL4, ความเข้ากันได้กับ Linux ABI และโครงสร้าง shared memory
  • กำลังทำงานด้าน formal verification บนพื้นฐาน Verus ร่วมกับ CertiK บริษัทผู้เชี่ยวชาญด้านการตรวจสอบความปลอดภัย
    • ในรายงานการประเมินความปลอดภัยของ CertiK มีการเปิดเผยจุดที่ตรวจสอบและประเด็นปัญหาที่ค้นพบในโครงการ

ไลบรารีและเครื่องมือพัฒนา

  • นอกจากตัวเคอร์เนลแล้ว ยังมี OSTD (เฟรมเวิร์ก Rust OS) และ OSDK (เครื่องมือพัฒนาบนฐาน Cargo) ให้ด้วย
  • เป้าหมายหลักของ OSTD:
    • ลดอุปสรรคในการเริ่มพัฒนา OS และวางรากฐานสำหรับนวัตกรรม
    • เสริมความปลอดภัยด้านหน่วยความจำของระบบปฏิบัติการ Rust และทำ abstraction ให้กับ low-level API
    • ส่งเสริมการนำโค้ดกลับมาใช้ซ้ำระหว่างโครงการ Rust OS
    • ทดสอบโค้ดใหม่ใน user mode ได้ (เพิ่มประสิทธิภาพการพัฒนา)
  • เคอร์เนลที่สร้างบน OSD และ OSTD ไม่จำเป็นต้องเข้ากันได้กับ Linux โดยให้ high-level memory-safe API สำหรับการควบคุมฮาร์ดแวร์ x86, virtual memory, multiprocessing (SMP), timer เป็นต้น
  • Intel เข้าร่วมเป็นสปอนเซอร์ โดยเฉพาะเทคโนโลยีด้าน Trust Domain Extensions (TDX) และการแยกกั้น virtual machine ที่สอดคล้องกัน

สถานะการพัฒนาและผู้สนับสนุนหลัก

  • เปิดซอร์สครั้งแรกเมื่อต้นปี 2024 (สัญญาอนุญาต MPL) ปัจจุบันมีผู้มีส่วนร่วม 45 คน โดยผู้มีส่วนร่วมหลักมาจากนักศึกษาปริญญาเอกของ SUSTech, มหาวิทยาลัยปักกิ่ง, มหาวิทยาลัย Fudan และ Ant Group ในจีน
  • รองรับ x86, RISC-V และติดตั้ง Linux system call แล้ว 206 รายการ (จากทั้งหมด 368 รายการ)
  • ยังรันแอปไม่ได้, ตั้งเป้าพัฒนาดิสโทรเริ่มต้นและรองรับคอนเทนเนอร์ (Docker), รวมถึงทดลองดิสโทรบนฐาน Nix
  • ไม่รองรับการโหลด Linux kernel module และไม่มีแผนจะรองรับในอนาคตอย่างถาวร

แผนต่อจากนี้

  • จัดให้การขยายไปยัง CPU architecture ที่หลากหลายขึ้น, การเพิ่มการรองรับฮาร์ดแวร์ และความพร้อมใช้งานจริงในสภาพแวดล้อมคลาวด์ เป็นงานสำคัญระยะสั้น
  • รองรับอุปกรณ์ Linux virtio แล้ว และตั้งเป้าตลาดหลักเป็นตลาดคลาวด์จีน (Alibaba Cloud, Aliyun)
  • เป้าหมายหลักคือการพัฒนา host OS สำหรับคอนเทนเนอร์ที่มีทั้ง TCB ที่ปลอดภัยและย่อขนาดลง พร้อมรองรับฟีเจอร์ trusted computing ของ Intel
  • แม้มีเป้าหมายคล้าย Rust for Linux แต่ Rust for Linux จำกัดอยู่ที่การนำ Rust มาใช้กับไดรเวอร์ภายในเคอร์เนลเดิม ขณะที่ Asterinas มุ่งออกแบบเคอร์เนลใหม่ทั้งระบบและลด TCB
  • ปัจจุบันยังทดลองหลายทิศทาง เช่น การรองรับ X11, Xfce และ OSTD เองก็มีศักยภาพที่จะได้รับความสนใจจากนักพัฒนา OS ทั่วไป

ความแตกต่างจาก Rust for Linux

  • Rust for Linux: นำ Rust มาใช้เฉพาะไดรเวอร์ที่ปลอดภัยในเคอร์เนล Linux เดิม ขณะที่ตัวเคอร์เนลทั้งหมดยังเป็น C
  • Asterinas: สร้างเคอร์เนลใหม่ตั้งแต่ต้นด้วย Rust จำกัดการใช้ unsafe อย่างเข้มงวด ผลักดัน formal verification และเน้นสภาพแวดล้อมคลาวด์/คอนเทนเนอร์

สรุปและแนวโน้ม

  • Asterinas กำลังลองแนวทางใหม่ที่น่าสนใจในด้านความปลอดภัยของหน่วยความจำ, formal verification และการใช้งานจริงในสภาพแวดล้อมคลาวด์
  • ยังไม่มีตัวอย่างการใช้งานจริงหรือการตรวจสอบจากชุมชนในวงกว้าง, แต่กำลังได้รับความสนใจในแวดวงวิจัย OS, คลาวด์ และความปลอดภัย
  • เฟรมเวิร์กอย่าง OSTD ก็มีโอกาสถูกนำไปใช้ใน ecosystem การพัฒนา Rust OS ในอนาคต

สรุปประเด็นหลักจากคอมเมนต์ LWN เกี่ยวกับ Asterinas

  • การถกเถียงเรื่อง Singularity OS และขอบเขตความปลอดภัยที่อิงกับภาษา
    • framekernel ของ Asterinas คล้ายกับ Singularity OS ของ Microsoft แต่ใช้ borrow checker ของ Rust เพื่อเพิ่มความปลอดภัยด้านหน่วยความจำ
    • เกิดความเห็นต่างระหว่างแนวคิดที่ปกป้องระบบด้วยขอบเขตความปลอดภัยของตัวภาษาเอง (เช่น Rust, Java, WASM/JS) โดยมีฝ่ายวิจารณ์ว่า “ไม่อาจเชื่อถือได้อย่างสมบูรณ์ และในทางปฏิบัติก็ต้องใช้ร่วมกับ sandbox ระดับฮาร์ดแวร์/OS” กับอีกฝ่ายที่มองว่า “มีข้อดีในการป้องกันข้อผิดพลาดและการพิสูจน์เชิงรูปแบบ”
    • แม้ WASM, JS, Java จะมีข้อถกเถียงเรื่องความปลอดภัย แต่ในการให้บริการจริงก็มักไม่ถือว่าภาษา sandbox เพียงอย่างเดียวเพียงพอ และโดยทั่วไปจะต้องใช้ sandbox ของฮาร์ดแวร์หรือ OS ควบคู่กัน
  • แนวโน้มการพัฒนาระบบปฏิบัติการและบริบทภูมิรัฐศาสตร์
    • ในช่วงไม่กี่ปีที่ผ่านมา มีโครงการ OS ใหม่หลากหลายโผล่ขึ้นมา และบรรยากาศของนวัตกรรมด้าน OS ก็กำลังขยายตัว
    • จีนกำลังเร่งพัฒนา OS ทางเลือกแทน Linux เพื่อตอบสนองต่อมาตรการคว่ำบาตรทางเทคโนโลยีของสหรัฐและความเสี่ยงด้านซัพพลายเชน
    • เกิดการถกเถียงทางการเมืองอย่างเข้มข้นเกี่ยวกับมาตรการของสหรัฐ, GPL และธรรมาภิบาลระดับโลกของโอเพนซอร์ส ตลอดจนแนวคิดที่ว่าจีน ยุโรป และประเทศต่าง ๆ ควรสร้าง ecosystem เทคโนโลยีที่เป็นอิสระของตนเอง
    • ความยากของการดูแลฟอร์กจาก Linux เทียบกับการสร้างเคอร์เนลใหม่ทั้งหมด การพึ่งพาความรู้/โนว์ฮาวของชุมชน และกำแพงภาษาก็เป็นประเด็นถกเถียงเช่นกัน
  • ข้อถกเถียงเรื่องความเข้ากันได้กับ Linux/จำนวน system call
    • มีหลายความเห็นว่า “การวัดความเข้ากันได้ด้วยจำนวน Linux system call นั้นไม่เหมาะสม”
    • system call เดียว (เช่น ioctl) อาจครอบคลุม API ย่อยจำนวนมาก ดังนั้นสำหรับความเข้ากันได้จริง การรันทดสอบด้วย kernel test suite หรือแอปจริงจึงสำคัญกว่า
    • ยังมีความเห็นเชิงปฏิบัติที่ยกประวัติการเติบโตของ Linux ซึ่งเริ่มจากการทำ syscall ทีละตัวเพื่อให้ได้ความเข้ากันได้ระดับ POSIX ว่า หากรองรับ syscall สำคัญได้ 99% ก็อาจรันซอฟต์แวร์ได้มากพอสมควรแล้ว
  • สัญญาอนุญาตและ ecosystem ของ Rust
    • มีการพูดถึงการที่ Asterinas เลือก MPL: มีความเห็นเชิงบวกว่า MPL เข้ากับ ecosystem ของ crate และลิขสิทธิ์แบบโมดูลาร์ของ Rust ได้ดี
    • อีกมุมหนึ่งมองว่า GPL ไม่ได้เหมาะที่สุดเสมอไป และหากได้รับการสนับสนุนจากภาคธุรกิจ ก็อาจเลือกใช้สัญญาอนุญาตที่เป็นมิตรกับองค์กรอย่าง MPL ได้
  • dependency ของโครงการ/ความปลอดภัย
    • มีการตั้งคำถามว่าการใช้ crate ภายนอกจำนวนมากใน Rust-based OS จะปลอดภัยเพียงใด และเสนอว่าควรมีระบบอัตโนมัติด้านความปลอดภัย/การตรวจสอบซัพพลายเชนผ่าน cargo deny/vet เป็นต้น
    • มีการกล่าวถึงด้วยว่าในทางปฏิบัติ lockfile เพียงอย่างเดียวทำให้เห็นพื้นผิว dependency ได้ยาก และ ecosystem ของ Rust ก็มีความซับซ้อนจาก transitive dependency และ dependency ที่ต่างกันไปตาม OS
  • แรงบันดาลใจทางเทคนิค/สถาปัตยกรรมที่คล้ายกัน
    • มีผู้ชี้ว่าแนวคิด framekernel คล้ายกับสถาปัตยกรรม SPIN OS ของ University of Washington ในยุค 90
    • SPIN เองก็เน้น modularity ที่เข้มแข็ง และการควบคุม interface/การเข้าถึงโดยคอมไพเลอร์
  • ข้อถกเถียงเรื่ององค์ประกอบของผู้คอมมิต
    • มีการพูดถึงว่าจากผู้มีส่วนร่วม 45 คน คอมมิตจำนวนมากมาจากนักศึกษาปริญญาเอกเพียงไม่กี่คน
    • ขณะเดียวกันก็มีความเห็นโต้แย้งต่อความเข้าใจผิดที่ว่า การมีส่วนร่วมจากนักศึกษาปริญญาเอกมีคุณค่าในฐานะผู้คอมมิตต่ำ โดยมองว่าในฐานะโครงการนวัตกรรมที่ขับเคลื่อนด้วยงานวิจัยก็ยังมีความหมาย
  • ข้อถกเถียงทางการเมือง/ประวัติศาสตร์และการชี้ว่าไม่เกี่ยวประเด็น
    • การพูดคุยเรื่อง OS ขยายไปสู่ข้อถกเถียงด้านภูมิรัฐศาสตร์/การเมือง/ประวัติศาสตร์ของสหรัฐ ยุโรป และจีน จนบรรณาธิการต้องเตือนว่า “นอกประเด็น” หลายครั้ง
    • ผู้ใช้บางรายเน้นว่า ecosystem ของโอเพนซอร์ส·FOSS ก็อาจได้รับผลกระทบจากการเปลี่ยนแปลงของสภาพแวดล้อมภูมิรัฐศาสตร์ด้วย
  • อื่น ๆ
    • มีการแชร์งานวิจัยเชิงวิชาการเกี่ยวกับความปลอดภัยของ WASM
    • มุมมองทั้งเชิงบวกและเชิงวิจารณ์ต่อสถานะการพัฒนาเคอร์เนลมีปะปนกัน

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
eususu 2025-06-24

ความพยายามแบบนี้ดูดีมากจริงๆ
ก็แอบคิดเหมือนกันว่าอีกไม่นานเราอาจจะได้เห็นเคอร์เนลที่ไม่ล่มง่ายๆ
 
GN⁺ 2025-06-23
ความคิดเห็นบน Hacker News

  • รู้สึกว่าเป็นแนวทางที่น่าสนใจและหวังว่าจะประสบความสำเร็จ แต่ก็ยังมีข้อกังขาอยู่ดี ยังจำได้ถึงสิ่งที่ Linus เคยพูดถึงคู่แข่งในบทสัมภาษณ์ทางทีวีช่วงปลายยุค 90 หรือต้นยุค 2000 ได้อยู่ Linus เคยพูดทำนองว่า "ไม่มีใครสนุกกับการเขียนไดรเวอร์ ดังนั้นก็ยังปลอดภัยอยู่จนกว่าจะมีใครสักคนที่ยังหนุ่มยังหิวและเก่งด้านวิศวกรรมไดรเวอร์โผล่มา" ตอนนั้นเขาก็รับรู้อยู่แล้วว่าการคงให้ driver interface ไม่เสถียรเป็นกลยุทธ์ป้องกันตัว ผ่านมา 25 ปีแล้ว ตอนนี้เคอร์เนลที่รันบนฮาร์ดแวร์เสมือนเป็นเรื่องธรรมดามาก แต่ระบบปฏิบัติการที่ใช้งานได้จริงและรองรับฮาร์ดแวร์จริงพร้อมสร้าง abstraction ได้สำเร็จก็ยังมีอยู่เพียงไม่กี่ตัว

    • ในประเด็นที่ว่า "การคงให้ driver interface ไม่เสถียรเป็นกลยุทธ์ป้องกันตัว" ผมคิดว่าในอนาคตอาจมีนักวิจัยระบบรุ่นใหม่ที่ยังหิว หรือ AI เข้ามา โดยให้ AI agent แปล Linux driver ที่เขียนด้วย C ไปเป็น Asterinas driver ที่เขียนด้วย Rust อย่างปลอดภัย อีกแนวทางที่เป็นจริงได้คือเอา Linux kernel เองไปใส่ไว้ในสภาพแวดล้อมแบบแยกส่วนเพื่อเอามาใช้ซ้ำ เช่น HongMeng kernel ใช้ User-Mode Linux เพื่อ reuse ไดรเวอร์ Asterinas ก็อาจใช้กลยุทธ์คล้ายกันได้ อ้างอิง: https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • ผมสงสัยว่า Linus ตั้งใจจะสร้าง "คูเมืองป้องกัน" จริงหรือไม่ เขาไม่ใช่ผู้ก่อตั้งสตาร์ตอัปสายเทค แต่เดิมก็เป็นแค่ kernel hacker และได้สร้างฐานะที่อยู่ได้ไปตลอดชีวิตแล้ว การตีความว่าความไม่เสถียรของ driver interface ภายในเคอร์เนลเป็นกลยุทธ์จงใจป้องกันคู่แข่ง น่าจะเป็นการมองเกินไปมาก

    • ก่อนหน้านี้ก็มีตัวอย่างอย่าง SPIN OS (Modula 3), JX OS (Java), House OS (Haskell), Verve ทั้งหมดใช้ภาษาแบบ type-safe และ memory-safe เพื่อสร้างฟังก์ชันของเคอร์เนล โดยทั่วไปจะมีโครงสร้างที่ซ่อนส่วนอันตรายไว้หลัง checked function call และบางตัวก็ใช้ VM ด้วย ถ้าไม่นับเรื่องประสิทธิภาพหรือการยอมรับใช้งาน จุดอ่อนหลักคือช่องโหว่ของ abstraction, การเลี่ยงผ่าน unsafe code, การพังของ safety model จากคอมไพเลอร์/JIT, และข้อบกพร่องของฮาร์ดแวร์ทั่วไป เช่น cosmic ray บนยานอวกาศ ถึงอย่างนั้นก็ยังปลอดภัยกว่าเคอร์เนลหรือแอปที่ใช้ภาษา unsafe มาก ถ้าจะไปไกลกว่านี้ ก็อาจใช้ static analysis กับ unsafe code, รับประกันว่า unsafe function ทั้งหมดปฏิบัติตาม interface ที่ type-safe และ memory-safe, ใช้คอมไพเลอร์ที่รักษาความปลอดภัยของ abstraction ตอนรวมระบบ, และอาจใช้คอมไพเลอร์ที่ผ่านการรับรองสำหรับแต่ละองค์ประกอบด้วย เครื่องมือด้าน productivity ส่วนใหญ่มีอยู่แล้ว เหลือเพียงอย่างเดียวคือ "การคอมไพล์แบบ abstracted อย่างปลอดภัยทั้งหมด" ซึ่งตอนนี้ยังอยู่ในงานวิจัย และก็ตรวจด้วยมือได้เช่นกัน

    • ที่มีระบบปฏิบัติการที่ใช้งานได้จริงอยู่เพียงไม่กี่ตัวก็มีเหตุผล ในโลกของฮาร์ดแวร์มี interface "มาตรฐาน" อยู่มากมาย แต่ฮาร์ดแวร์จริงกลับแทบไม่ทำงานตามมาตรฐานเป๊ะ ๆ ถ้าไม่มีเวลาเขียนโค้ดให้ไดรเวอร์รองรับความเพี้ยนสารพัดและข้อบกพร่องแก้ไม่ได้ต่าง ๆ (errata) ก็ยากมากที่จะให้มันทำงานได้ดีและรองรับฮาร์ดแวร์กายภาพจริง

    • แต่อีกด้านหนึ่ง Linux ที่ผมใช้งานจริง 98% รันอยู่ในสภาพแวดล้อมเสมือน บนเดสก์ท็อป/แล็ปท็อปก็เปิด Virtualbox แบบเต็มจอ และใช้ไดรเวอร์สำหรับ Windows เฉพาะตอนจำเป็นจริง ๆ บน Mac ก็เป็น headless VM ที่ Docker.app จัดการให้ เวิร์กโหลด production ทั้งหมดของบริษัทอยู่บน AWS VM แม้แต่ฮาร์ดแวร์ Linux ที่บ้านซึ่งเป็นโฮมเซิร์ฟเวอร์ ก็มีแผนจะเปลี่ยนเป็น Mac mini VM ที่ซื้อมาจาก eBay ถ้ามีเคอร์เนลที่เข้ากันได้กับ Linux แต่ปลอดภัยกว่าและประสิทธิภาพใกล้เคียงกัน ทุกวันนี้ต่อให้ไดรเวอร์ยังไม่ครบ การเลือกทางเลือกใหม่ก็ง่ายขึ้นมาก

  • เห็นว่าช่วงหลังไมโครเคอร์เนลแก้ปัญหาประสิทธิภาพ IPC ได้มากแล้ว จำตัวเลขจริงไม่ได้ว่าดีขึ้นแค่ไหน แต่ดูเหมือนวงการจะมีบาดแผลจาก Mach อยู่มาก พอดูในเว็บไซต์โครงการแล้วกลับพบว่าโครงสร้างคือมีเพียง Framework (โหมดสิทธิพิเศษ) เท่านั้นที่ใช้ Rust แบบ unsafe ได้ ส่วน Services (ไม่มีสิทธิพิเศษ) ใช้ได้เฉพาะ safe Rust รู้สึกแปลก ๆ เพราะถ้าโค้ดฝั่งไม่มีสิทธิพิเศษเป็น unsafe มันก็ยังอันตรายไม่ใช่หรือ? ขณะที่โค้ด unsafe ที่ควรต้องตรวจสอบมากที่สุดกลับอยู่ฝั่งที่ใช้ได้ไม่จำกัด? แล้วดูจากไลเซนส์ Asterinas ใช้ Mozilla Public License (MPL) 2.0 เป็นหลัก และบางองค์ประกอบใช้ไลเซนส์ที่ผ่อนปรนกว่า ก็ให้ความรู้สึกอยู่กึ่งกลาง ไม่ใช่ทั้ง GPL และไม่ใช่ BSD

    • สำหรับคำถามว่า "ถ้าฝั่งไม่มีสิทธิพิเศษเป็น unsafe ก็อันตราย และแปลกที่ไปกองโค้ดที่ต้องตรวจสอบจริง ๆ ไว้ฝั่งมีสิทธิพิเศษ" ต้องตีความในบริบทของ framekernel ทั้งระบบ framekernel ที่สร้างด้วย Rust รันอยู่ใน kernel space แต่ในเชิงตรรกะแบ่งเป็นสองส่วนคือ privileged OS framework กับ unprivileged OS services ฝั่ง privileged รวมทั้ง safe และ unsafe Rust kernel code ส่วนฝั่ง unprivileged มีได้เฉพาะ safe Rust kernel code นโยบายนี้ใช้กับ kernel code ทั้งหมด ใน framekernel ไม่มีข้อจำกัดเรื่องภาษาของโปรแกรมผู้ใช้

    • เท่าที่ทราบ ไมโครเคอร์เนลยุคใหม่ส่วนใหญ่ปรับปรุงประสิทธิภาพ IPC ได้อย่างมาก ตัวอย่างเด่นคือ SeL4 ที่ optimize IPC แบบหนักมาก จน IPC เร็วกว่าระบบ syscall ทั่วไปของ Linux มาก โปรแกรมส่วนใหญ่จำนวนมากอาจรันบน SeL4 ได้เร็วกว่าเสียอีก อยากเห็นข้อมูลเปรียบเทียบประสิทธิภาพจริง

    • ไมโครเคอร์เนลสมัยใหม่แก้ปัญหา IPC ได้ดีขึ้นจริง ที่จริงปัญหาที่ลึกกว่านั้นคือบนฮาร์ดแวร์สมัยใหม่ แม้แต่ syscall ของ monolithic kernel เองก็ช้ามาก นั่นจึงเป็นเหตุผลที่ interface อย่าง io_uring หรือ virtio ให้ประสิทธิภาพดี เพราะประมวลผลคำขอและคำตอบระหว่างระบบกับแอป (หรือระหว่างไฮเปอร์ไวเซอร์กับ guest) แบบคิว จึงหลีกเลี่ยงการสลับ address space ได้ ระบบปฏิบัติการแห่งอนาคตไม่ว่าจะโครงสร้างแบบไหนก็ต้องมี syscall mechanism แบบอิงการ queue และถ้าเลือกแนวทางนี้แล้ว ต่อให้แยกเป็น monolithic, microkernel หรือโครงสร้างอื่น ๆ ความต่างด้านประสิทธิภาพก็แทบไม่มีนัยสำคัญ

    • ใน Framekernel การแยก privileged/unprivileged ไม่ได้หมายถึง kernel/userspace ทั้งระบบปฏิบัติการรันที่ระดับสิทธิ์ของเคอร์เนลเหมือนกัน เพียงแต่ในเชิงตรรกะแบ่งเป็นโค้ดไลบรารีแกนกลาง (privileged, อนุญาตให้ใช้ unsafe) กับโค้ดองค์ประกอบเคอร์เนลส่วนที่เหลือ (unprivileged, ใช้ไลบรารีได้แต่ห้ามใช้ unsafe โดยตรง) น่าจะบังคับด้วย static check อย่าง linter เป็นต้น เป็นโครงสร้างที่สับสนได้ง่ายเพราะใช้คำซ้ำกัน

    • แม้แต่ task แบบไม่มีสิทธิพิเศษก็ยังทำงานอยู่ในพื้นที่หน่วยความจำเดียวกับแกนกลางของเคอร์เนล ดังนั้นจึงไม่มีวิธีป้องกันพฤติกรรมที่ไม่ปลอดภัยในระดับ runtime ถ้าจะให้แยกสิทธิ์กันจริงในระดับ runtime ก็ต้องใช้โครงสร้างไมโครเคอร์เนล ที่นี่สิทธิ์จึงถูกทำให้เป็นแบบ static ไม่ใช่ runtime กล่าวคือใช้การห้าม unsafe code เพื่อทำหน้าที่เป็นกลไกสิทธิ์

  • อยากรู้ว่าแนวคิดการแยกเคอร์เนลออกเป็นแกน unsafe ขนาดเล็กกับโมดูล safe ขนาดใหญ่ เป็นความพยายามใหม่หรือไม่ มันน่าสนใจและชวนคาดหวังมาก เพราะไม่มี overhead ฝั่งฮาร์ดแวร์แบบไมโครเคอร์เนล เลี่ยงปัญหาความปลอดภัยของ monolithic ได้ด้วย และใช้ประโยชน์จากคุณสมบัติการแยก safe/unsafe ของภาษา system ได้ดี

  • ทำให้นึกถึงบทความ Drew DeVault's Rust in Linux review และก็โยงไปยังการถกเถียงบน HN ได้ด้วย https://news.ycombinator.com/item?id=41404733

  • คิดว่าเป็นความพยายามที่ยอดเยี่ยมมาก และประทับใจที่ผู้เขียนมาอยู่ในเธรดนี้ด้วย อยากรู้ว่า usable แค่ไหนแล้ว อย่างน้อยก็อยากลอง build server image มาทดลองในสภาพแวดล้อมที่จำกัดบางแบบ

    • Asterinas ยังเป็นเคอร์เนลที่ค่อนข้างใหม่ จึงยังมีจุดที่ต้องปรับอีกมากก่อนจะใช้ได้แบบทั่วไป แต่ถ้าเป้าหมายคือใช้งาน production service ที่มีประสิทธิภาพและน่าเชื่อถือจริง ๆ ช่องว่างนั้นไม่ได้ใหญ่ขนาดนั้น และอาจไปถึงเป้าหมายได้ภายใน 1 ปี ตอนนี้กำลังทำฟีเจอร์สำคัญอย่าง Linux namespaces, cgroups และกำลังทำดิสโทรตัวแรกที่สร้างบน Asterinas เป้าหมายระยะแรกคือใช้ Asterinas เป็น guest OS สำหรับ Confidential VMs ซึ่งมีจุดแข็งชัดเจนกว่าลินุกซ์ด้านความปลอดภัยเพราะมี memory safety และ TCB ที่เล็กกว่า

  • เวลาเห็นคำอธิบายว่าไมโครเคอร์เนลไม่ค่อยนิยมเพราะ IPC ช้า ก็รู้สึกสบายใจขึ้นนิดหน่อยที่แม้แต่คนเก่งมากทางเทคนิคก็ยังอาจเข้าใจเหตุผลการยอมรับใช้งานจริงและกระบวนการที่ทำให้เกิดมันแบบคลาดเคลื่อนได้

    • ถ้าอย่างนั้นก็ควรอธิบายให้ชัดเจนว่าตีความผิดตรงไหน เพื่อจะได้เป็นประโยชน์กับทุกคน

  • ไลเซนส์เป็น MPL ซึ่งส่วนตัวคิดว่ายังมีไลเซนส์ที่ดีกว่าได้ เช่น GPLv3

    • ในเอกสารมีอธิบายเหตุผลที่เลือก MPL ไว้ตรง ๆ แม้ไม่ใช่ตัวเลือกที่ผมชอบ แต่ก็พอเข้าใจเหตุผลได้

  • คิดว่าเป็นไอเดียที่ดีมาก ซอฟต์แวร์จำนวนมากถูกสร้างขึ้นแล้ว และการมีรากฐานทางเลือกก็อาจสร้างข้อดีหรือทางเลือกที่สำคัญได้จากเหตุผลที่ไม่ใช่เรื่องเทคนิคอย่างเดียว ทำให้นึกถึง kFreeBSD และ GNU/Hurd

  • เคอร์เนลแบบนี้ควรเรียกว่าอะไรดี *nux?