- Maestro เป็นโครงการที่ต้องการสร้างระบบปฏิบัติการตระกูล Unix แบบใหม่ด้วย Rust ให้มีน้ำหนักเบาและเข้ากันได้กับ Linux มากพอสำหรับการใช้งานประจำวัน
- เริ่มต้นเป็นโปรเจ็กต์ในโรงเรียนเมื่อปี 2018 โดยช่วงแรกพัฒนาด้วย C แต่ภายหลังเปลี่ยนมาใช้ Rust เพราะปัญหาในการดูแลโค้ดเบสและความต้องการด้านความปลอดภัยในการพัฒนาเคอร์เนล
- ปัจจุบันเป็น monolithic kernel สำหรับ x86 แบบ 32 บิต และมีการทำ Linux system call ไปแล้ว 135 จาก 437 รายการ หรือราว 31%
- กำลังพัฒนา boot system และตัวจัดการ daemon อย่าง Solfège, ชุด system utility, และตัวจัดการแพ็กเกจ blimp ควบคู่กันไป โดยมี musl, bash และ GNU coreutils บางส่วนที่ทำงานได้แล้ว
- ยังอยู่ในระยะเริ่มต้นมากและไม่เสถียร โดยทดสอบหลักบน QEMU, VMWare และ VirtualBox ดังนั้นจึงปลอดภัยกว่าหากไม่ติดตั้งบนเครื่องที่มีข้อมูลสำคัญ
เป้าหมายและจุดเริ่มต้นของ Maestro
- Maestro คือ ระบบปฏิบัติการตระกูล Unix ที่เขียนขึ้นใหม่ทั้งหมดด้วย Rust
- เป้าหมายคือสร้างระบบที่เบา และเข้ากันได้กับ Linux มากพอสำหรับการใช้งานในชีวิตประจำวัน
- โครงการนี้เริ่มต้นขึ้นเพื่อสร้างสภาพแวดล้อมที่สามารถเข้าใจระบบได้ด้วยตนเองตั้งแต่ A ถึง Z และปรับแต่งได้ตามต้องการ
เหตุผลที่เปลี่ยนจาก C ไปเป็น Rust
- คอมมิตแรกถูกสร้างเมื่อ 22 ธันวาคม 2018 เวลา 03:18 และโครงการเริ่มต้นจากงานที่ได้รับมอบหมายในโรงเรียน
- การพัฒนาช่วงแรกดำเนินด้วย C เป็นเวลาประมาณ 1 ปีครึ่ง แต่เริ่มยากที่จะรักษาโค้ดเบสให้สะอาดอยู่เสมอ
- ข้อดีที่ได้จากการเริ่มใหม่ด้วย Rust
- สามารถออกแบบโครงการใหม่ตั้งแต่ต้น โดยอิงจากบทเรียนที่ได้จากความผิดพลาดก่อนหน้า
- เปิดทางให้ลองสิ่งใหม่ ๆ ได้มากกว่าการเขียนเคอร์เนลคล้าย Linux ซ้ำอีกครั้งด้วย C
- ด้วย type system ของ Rust ภาระความรับผิดชอบด้าน memory safety บางส่วนจึงย้ายจากโปรแกรมเมอร์ไปอยู่ที่คอมไพเลอร์ได้
จุดที่ Rust ได้เปรียบในการพัฒนาเคอร์เนล
- การดีบักในการพัฒนาเคอร์เนลยากกว่าการพัฒนาแอปพลิเคชันทั่วไปมาก
- หาเอกสารอ้างอิงได้ยาก และตัว implementation ของ BIOS เองก็อาจมีข้อบกพร่อง
- ระหว่างบูต เคอร์เนลสามารถเข้าถึงหน่วยความจำทั้งหมดได้ จึงอาจเขียนทับตำแหน่งที่ไม่ควรเขียน เช่น โค้ดของตัวเอง
- ไม่สามารถใช้เครื่องมืออย่าง valgrind เพื่อติดตาม memory leak ได้
- gdb ใช้งานร่วมกับ QEMU และ VMWare ได้ แต่พฤติกรรมของเคอร์เนลอาจต่างกันไปตาม emulator หรือ virtual machine
- บางสภาพแวดล้อมอย่าง VirtualBox ไม่รองรับ gdb และแม้แต่ความสามารถรองรับ gdb ของ QEMU กับ VMWare เองก็ยังขาดบางส่วน รวมถึงมีกรณีที่ gdb ล่มได้
- เพื่อลดปัญหาเหล่านี้ ภาษาแบบ memory-safe จึงเป็นข้อได้เปรียบแม้ในการพัฒนาเคอร์เนล
- Rust ช่วยเพิ่มกลไกความปลอดภัยหลายอย่างให้กับเคอร์เนล และถูกมองว่าเป็นการตัดสินใจที่ดีที่สุดของโครงการ
สถานะการพัฒนาในปัจจุบัน
- ปัจจุบัน Maestro เป็น monolithic kernel และรองรับเฉพาะสถาปัตยกรรม x86 แบบ 32 บิต
- สถานะการพัฒนา ณ เวลาที่เขียน
- มีการทำ Linux system call ไปแล้ว 135 จาก 437 รายการ ในระดับหนึ่ง
- อัตราการรองรับ system call: {p:31}
- เมื่อนับรวมทั้ง repository มี 615 ไฟล์ และโค้ด 48,800 บรรทัด
- จำนวนบรรทัดคำนวณด้วยคำสั่ง
cloc
- องค์ประกอบของ OS นอกเหนือจากเคอร์เนล
- Solfège: boot system และตัวจัดการ daemon ที่คล้าย systemd ในระดับหนึ่ง แต่เบากว่า
- maestro-utils: ชุดคำสั่ง system utility
- blimp: ตัวจัดการแพ็กเกจ
- องค์ประกอบอื่น ๆ เปิดเผยต่อสาธารณะบน GitHub
- ซอฟต์แวร์ third-party ที่ยืนยันแล้วว่าใช้งานได้
- musl C standard library
-
bash
- คำสั่ง GNU coreutils บางส่วน เช่น
ls,cat,mkdir,rm,rmdir,uname,whoami - neofetch เวอร์ชันต้นฉบับยังไม่รู้จัก Maestro จึงต้องใช้ neofetch เวอร์ชันที่ผ่านการแพตช์แล้ว
- คำสั่ง GNU coreutils บางส่วน เช่น
วิธีทดสอบด้วยตนเองและข้อจำกัด
- OS นี้ยังอยู่ในระยะเริ่มต้นมากและไม่เสถียรอย่างมาก
- ไม่แนะนำให้ติดตั้งบนเครื่องที่มีข้อมูลสำคัญ
- จนถึงตอนนี้มีการทดสอบหลักบน QEMU, VMWare และ VirtualBox
- มีวิธีติดตั้ง 2 แบบ
- ดาวน์โหลดไฟล์
.isoแบบบีบอัดที่ build ไว้แล้ว - build ISO ด้วยตนเอง
- ดาวน์โหลดไฟล์
- ใน ISO มีโปรแกรมติดตั้ง OS รวมอยู่ และสามารถรันบน QEMU, VMWare, VirtualBox เป็นต้นได้
- การรัน ISO ต้องใช้ RAM เพียงพอ และ 1GB ก็เพียงพอ
- เพราะแพ็กเกจที่จะติดตั้งถูกเก็บไว้ใน RAM ของ initramfs ไม่ใช่บนดิสก์
- ขณะนี้ OS ยังไม่สามารถอ่าน USB stick หรือ CD-ROM ได้โดยตรง จึงต้องพึ่งพา bootloader
หัวข้อที่จะพูดถึงในบทความ
- เป้าหมายไม่ใช่การเขียนบทสอนสร้าง OS
- สำหรับแหล่งข้อมูลพื้นฐานด้านการสร้าง OS ขอแนะนำ osdev.org และ Philipp Oppermann’s blog
- ต่อจากนี้จะกล่าวถึงหัวข้อที่ลึกขึ้น กระบวนการแก้ปัญหา และวิธีที่คอมพิวเตอร์ ระบบปฏิบัติการ และอินเทอร์เน็ตทำงานภายใน
ทิศทางการพัฒนาต่อจากนี้
- ลำดับความสำคัญคือ การจัดระเบียบโค้ดเบส และการปรับแต่งประสิทธิภาพ
- เนื่องจากเริ่มต้นเป็นโปรเจ็กต์ในโรงเรียน จึงมีบางส่วนที่เลือกทางลัดเพื่อให้ทันกำหนด และจำเป็นต้องชำระหนี้ทางเทคนิคที่สะสมไว้
- ยังต้องแก้ memory leak บางส่วน และการปรับแต่งประสิทธิภาพก็อาจกลายเป็นหัวข้อของบทความได้
- เป้าหมายใหญ่ถัดไปคือทำให้ตัวจัดการแพ็กเกจทำงานได้อย่างสมบูรณ์บน OS
- ต้องมี การรองรับเครือข่าย ซึ่งกำลังอยู่ระหว่างการพัฒนา
- ต้องมี การรองรับ shared library
- shared library จำเป็นต้องแมปไฟล์เข้าไปในหน่วยความจำโดยตรง แต่ปัจจุบัน system call
mmapของเคอร์เนลยังไม่รองรับสิ่งนี้
- หลังจากนั้นจะติดตั้งและทดสอบโปรแกรมอย่าง gcc/g++, clang, rustc, make, Git และ Vim ได้ง่ายขึ้น
- เป้าหมายสุดท้ายคือทำให้สามารถพัฒนาเคอร์เนลบน Maestro เองได้
กระบวนการพัฒนาเพื่อเพิ่มความสมบูรณ์ของเคอร์เนล
- การพัฒนาดำเนินไปในลักษณะรันโปรแกรมบนเคอร์เนล แล้วหากทำงานไม่ได้ก็จะหาว่า system call ตัวใดเป็นสาเหตุ แล้วจึงนำไปพัฒนาหรือแก้ไข
- รันโปรแกรมบนเคอร์เนล
- หากไม่ทำงาน ให้ดูเอาต์พุตของ system call เพื่อหาว่า system call ตัวแรกที่ก่อปัญหาคืออะไร
- หาก system call นั้นยังไม่ถูก implement หรือมีบั๊ก ก็ให้ implement หรือแก้ไข
- จากนั้นรันโปรแกรมอีกครั้ง
- ยิ่งมีโปรแกรมที่ทำงานได้ถูกต้องบนเคอร์เนลมากเท่าไร เคอร์เนลก็จะยิ่ง เสถียร และสมบูรณ์มากขึ้น
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ขอบคุณมากที่ช่วยเชียร์ มันมีความหมายมากเพราะผมทุ่มเทกับโปรเจกต์นี้ไปเยอะ
ตอนนี้เว็บไซต์ดูเหมือนจะค่อนข้างช้าหรืออาจล่มไปแล้ว เพราะมี ทราฟฟิก มากกว่าที่คาด และสงสัยว่าอาจมี การโจมตี DoS ด้วย
ตอนนี้ผมอยู่ที่ทำงานเลยยังโฟกัสแก้ทันทีได้ยาก แต่พอกลับบ้านแล้วจะลองปรับให้ทำงานได้ดีขึ้น
เมื่อปี 2010 ตอนที่ยังไม่มี Rust ผมเคยลองแตะ ๆ OS งานอดิเรกตระกูล Unix ที่เขียนด้วย C หลังเพิ่งเรียนจบมหาวิทยาลัย สนุกมากจริง ๆ
อิจฉาที่หาเวลาพามันมาได้ไกลขนาดนี้
แถบนำทางกินพื้นที่หน้าจอไปประมาณ 33% และเอาออกไม่ได้
ไม่เข้าใจว่าทำไมคนถึงตรึงของแบบนี้ไว้แล้วแย่งพื้นที่อ่านอันมีค่าไป ถ้าต้องการก็เลื่อนกลับขึ้นบนสุดได้ในราว 300ms อยู่แล้ว
เป็นโปรเจกต์เล็ก ๆ ที่ยอดเยี่ยม น่าทึ่งที่บูตมาได้ไกลขนาดนี้ทั้งที่ยังไม่ได้อิมพลีเมนต์ system call ของ Linux ถึงหนึ่งในสามด้วยซ้ำ
แต่สิ่งที่ยังขาดอยู่น่าจะเป็นส่วนที่ซับซ้อนกว่า เช่น เลเยอร์ TTY ตอนนี้ดูยังค่อนข้างพื้นฐาน และถ้าจะทำให้ถูกต้องคงมีงานอีกมาก
ดังนั้นจึงยากที่จะคาดหวังว่า Maestro จะรันแอปพลิเคชัน Linux ได้ภายใน 3 ปีข้างหน้า แม้ยังไม่คิดถึงไดรเวอร์นับพันตัวที่ Linux มี
แพลตฟอร์มที่โตเต็มที่จะสะสมลอจิกไว้เพื่อรองรับหลายสถานการณ์ ทำให้ส่วนใหญ่ไม่จำเป็นต้องใช้ระบบทั้งหมดเป็นส่วนใหญ่
คล้ายคำพูดที่ว่า “ไม่มีใครใช้ Excel เกิน 10% แต่ 10% ที่แต่ละคนใช้นั้นไม่เหมือนกัน”
แค่อิมพลีเมนต์ฟังก์ชัน Excel 30% ก็อาจสร้างเอนจินที่เปิดสเปรดชีต 99% ในโลกได้แล้ว แต่ถ้าต้องการ ความเข้ากันได้ของเอกสารแบบสมบูรณ์ ก็ยังต้องไปอีกไกล
system call บางตัวถูกเรียกเฉพาะในเส้นทางโค้ดบางแบบ หรืออาจเป็น call ใหม่ที่จำเป็นเมื่อ target ไปที่เคอร์เนลรุ่นใหม่กว่าเท่านั้น
system call มีเยอะ และบางตัวก็พิสดารพอสมควร ถ้าเป็นการอิมพลีเมนต์ทดแทนแบบเปิดเต็มรูปแบบ สุดท้ายก็คงต้องรองรับให้ได้ส่วนใหญ่ แต่หนึ่งในสามถือเป็นจุดเริ่มต้นที่ดี
[1] ผมอยากรัน VM บน bare metal หรือบูตเป็น VM และถ้าไม่นับประมาณ
init=/path/to/the/vmแล้ว วิธีนี้ดูเหมือนเป็นทางที่ใช้แรงน้อยที่สุดเพื่อไปถึงจุดนั้น แต่แนวทางนั้นไม่ได้ให้สิ่งที่ผมต้องการจริง ๆ คือการมีไดรเวอร์ฮาร์ดแวร์และ TCP stack อยู่ในภาษา VMผมคิดว่าไม่จำเป็นต้องรัน Steam, LibreOffice, Firefox ได้ถึงจะมีประโยชน์ องค์ประกอบจำนวนมากในสถาปัตยกรรมเซิร์ฟเวอร์หรือไมโครเซอร์วิสทั่วไปทำงานค่อนข้างเรียบง่าย และน่าจะได้ประโยชน์มากจากเคอร์เนลที่ปลอดภัยและเรียบง่าย
ยังมี Kerla ซึ่งเป็นเคอร์เนลแบบ monolithic ที่เขียนด้วย Rust และตั้งเป้า เข้ากันได้กับ Linux ABI ด้วย แต่ดูเหมือนจะพักโครงการมาหลายปีแล้ว
[1] https://news.ycombinator.com/item?id=28986229
เป็นดีไซน์แบบ microkernel และน่าจะโตเต็มที่กว่านิดหน่อย ใช้ไลเซนส์ MIT เลยดูเหมือนยังมีโอกาสแชร์โค้ดกันได้
ถ้าอยากดูว่า “แค่เพราะมันเขียนด้วย Rust แฮกเกอร์ฝีมือดีจะหาอะไรเจอไหม” การลองทำ security/pentest/fuzzing น่าจะน่าสนุก
ผมมั่นใจ 100% ว่าถ้าทำ fuzzing test หรือ pentest จะเจอปัญหาเยอะ ตอนนี้ยังไม่มีเวลาพอจะลงกับเรื่องนั้น
ดูเหมือนเป็นสิ่งที่เคยลองทำไปแล้วในโปรเจกต์ Kerla ซึ่งตอนนี้หยุดไปแล้ว
ฟังดูเป็นโปรเจกต์ที่น่าสนใจ แต่ผมคิดว่าข้อเสียของการใช้ C และความยากของการพัฒนา OS ส่วนใหญ่อยู่ที่ การดีบัก
การเปลี่ยนมาใช้ Rust ทำให้ข้อผิดพลาดหน่วยความจำบางประเภทหายไปก็จริง แต่การดีบักยังคงทรมานอยู่ไหม? หรือมันลดลงจากเดิมจนพอทนได้แล้ว
การดีบักยังทรมานอยู่ แต่ก็น้อยกว่าเดิมมาก
ตัวอย่างเช่น โอกาสลืมใช้ mutex ไม่ได้สูงนัก เพราะคอมไพเลอร์จะแจ้งเป็นข้อผิดพลาดให้
แต่ก็ไม่ได้เป็นยาครอบจักรวาล ปัญหาอย่าง deadlock ยังมีอยู่ โดยเฉพาะเมื่อมี interrupt เข้ามาเกี่ยว
เช่น ถ้าล็อก mutex ไว้แล้วเกิด interrupt โค้ดที่ล็อก mutex นั้นจะหยุดจนกว่า interrupt จะจบ แต่ถ้าโค้ดจัดการ interrupt พยายามล็อก mutex เดียวกัน ก็จะเกิด deadlock และ type system ช่วยเรื่องนี้ไม่ได้
ทางแก้คือปิด การจัดการ interrupt ระหว่างที่ mutex ถูกล็อกอยู่ แต่คอมไพเลอร์บังคับเรื่องนี้ไม่ได้
นอกเรื่องนิดหน่อย แต่ผมชอบ Gource ที่ผู้เขียนใช้ในวิดีโอการมีส่วนร่วม
ก่อนหน้านี้ไม่เคยเห็นมาก่อน แต่เมื่อหลายปีก่อนเคยมีไอเดียอยากทำอะไรคล้าย ๆ กัน ดูเหมือนว่าไม่มีไอเดียอะไรใหม่จริง ๆ
โดยเฉพาะถ้าเพื่อการเรียนรู้ ผมชอบ การสร้างเคอร์เนลเอง มาก อยากรู้ว่าใช้แหล่งข้อมูลอะไรในการทำความเข้าใจเคอร์เนลและ OS โดยรวม
แปลกใจที่ไม่มีใครพูดถึง Theseus OS เป็น OS ที่กำลังพัฒนาและสร้างด้วย Rust ตั้งแต่ต้น โดยใช้ การรับประกันความปลอดภัยของหน่วยความจำ จากคอมไพเลอร์ Rust เพื่อให้สิ่งจำนวนมากที่ OS แบบเดิมต้องวางระบบอย่างระมัดระวังเกิดขึ้นโดยอัตโนมัติ
เช่น เป็นโครงสร้างระดับสิทธิ์เดียว พื้นที่ที่อยู่เดียว แต่ก็ยังปลอดภัย ทุกส่วนของ OS สามารถ hot-plug ได้
ข้อเสียคือโค้ด native ทั้งหมดต้องเป็น Rust แต่ปีที่แล้วมีการอิมพลีเมนต์ WASM runtime แล้ว เธรดที่เกี่ยวข้องเมื่อ 3 ปีก่อน:
https://news.ycombinator.com/item?id=25741729
ไม่คิดว่าจะมีคนบ้าพอจะรับมือโปรเจกต์ ft_penguin ได้ ยังไม่แน่ใจว่ายังใช้ชื่อนั้นอยู่ไหม แต่พูดตรง ๆ ว่าทำได้ดีมากจริง ๆ
เมื่อ 7 ปีก่อนตอนอยู่ที่โรงเรียน ผมคิดว่านี่เป็นหนึ่งในโปรเจกต์ที่ผลตอบแทนแย่ที่สุดเมื่อเทียบกับเวลาที่ต้องใช้
อยากรู้ว่าตอนแรกเริ่มกับเพื่อนหรือเปล่า และก่อนจะเขียนใหม่ด้วย Rust มันเป็นอย่างไร รวมถึงตอนนั้นทำโปรเจกต์อื่นไปพร้อมกันด้วยไหม
พอดูโค้ดแล้วทำให้นึกถึงความสนุกขึ้นมา จนตอนนี้อยากเลิกงาน DevOps แล้วกลับไปทำ embedded หรืองาน low-level อื่น ๆ ที่ตั้งใจจะทำแต่แรก