LiteBox - Library OS แบบโอเพนซอร์สที่เน้นความปลอดภัยซึ่ง Microsoft เปิดเผยสู่สาธารณะ

 (github.com/microsoft)
12 คะแนน โดย GN⁺ 2026-02-08 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Library OS ที่เน้นความปลอดภัย รองรับการรันได้ทั้งใน kernel mode และ user mode พร้อมมอบ สภาพแวดล้อม sandbox ที่ลดพื้นผิวการโจมตีด้วยการทำให้ host interface เหลือน้อยที่สุด
  • เขียนด้วย Rust และรองรับการทำงานร่วมกันระหว่างอินเทอร์เฟซระดับบนสไตล์ nix และ rustix กับแพลตฟอร์มระดับล่างที่หลากหลาย
  • กรณีใช้งานหลัก: รันโปรแกรมลินุกซ์บน Windows, sandbox แอปพลิเคชันลินุกซ์, รันบนสภาพแวดล้อม SEV SNP และ OP-TEE, รองรับแพลตฟอร์ม LVBS เป็นต้น
  • เป็นฐานการทดลองของสถาปัตยกรรม OS รุ่นถัดไปที่มุ่งเน้น การแยกด้านความปลอดภัย, virtualization และการลด system interface ให้เหลือน้อยที่สุด
  • ผสานโค้ดระบบที่ปลอดภัยซึ่งพัฒนาด้วย Rust เข้ากับ โมเดลการรันแบบรวม kernel-user mode ทำให้สามารถนำไปใช้กับ งานวิจัยด้านความปลอดภัยและการพัฒนาเทคโนโลยี cloud isolation ได้

ภาพรวมของ LiteBox

  • LiteBox คือ Library OS แบบโอเพนซอร์สที่เน้นความปลอดภัยซึ่ง Microsoft เปิดเผยสู่สาธารณะ และรองรับการรันได้ทั้งใน kernel mode และ user mode
    • เป้าหมายหลักคือ ลดอินเทอร์เฟซกับโฮสต์ให้น้อยที่สุด เพื่อลดพื้นผิวการโจมตี
    • ด้วยแนวทางนี้จึงสามารถสร้างสภาพแวดล้อมการรันแบบแยกส่วนในรูปแบบ sandbox ได้
  • ระบบถูกเขียนด้วยภาษา Rust และในชั้นบนมีอินเทอร์เฟซสไตล์ nix/rustix ให้ใช้งาน
    • ในชั้นล่างสามารถเชื่อมต่อแพลตฟอร์มที่หลากหลายผ่านอินเทอร์เฟซ Platform ทำให้จัดองค์ประกอบได้อย่างยืดหยุ่น

ฟีเจอร์หลักและกรณีใช้งาน

  • LiteBox ถูกออกแบบเป็นโครงสร้างที่รองรับการทำงานร่วมกันระหว่างสภาพแวดล้อมปฏิบัติการหลายแบบ
    • รันโปรแกรมลินุกซ์บน Windows
    • sandbox แอปพลิเคชันภายในลินุกซ์
    • รองรับสภาพแวดล้อมการรันที่ปลอดภัยบนพื้นฐาน SEV SNP
    • รันโปรแกรม OP-TEE บนลินุกซ์
    • รองรับการรันบนแพลตฟอร์ม LVBS

สถานะปัจจุบันและไลเซนส์

  • โปรเจกต์นี้ ยังอยู่ระหว่างการพัฒนาอย่างต่อเนื่อง และยังไม่ถึงขั้นปล่อยเวอร์ชันเสถียร
    • API และอินเทอร์เฟซอาจมีการเปลี่ยนแปลงได้ในอนาคต
    • สามารถใช้งานเชิงทดลองได้ แต่ควรระมัดระวังหากเป็นสภาพแวดล้อมที่ต้องการเสถียรภาพระยะยาว
  • ไลเซนส์ MIT

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

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

 
GN⁺ 2026-02-08
ความคิดเห็นจาก Hacker News

  • ตามหน้า GitHub, LiteBox คือ library OS สำหรับการแซนด์บ็อกซ์ ที่เน้นความปลอดภัย โดยลด host interface ให้เหลือน้อยที่สุดเพื่อลดพื้นผิวการโจมตี
    ถูกออกแบบมาให้เชื่อมต่ออินเทอร์เฟซ “North” ที่อิงกับ nix/rustix สไตล์ Rust เข้ากับแพลตฟอร์ม “South” ที่หลากหลาย
    ตัวอย่างเช่น รันโปรแกรม Linux บน Windows, แซนด์บ็อกซ์แอป Linux, หรือรันบน SEV SNP·OP-TEE·LVBS

    • ส่วนที่น่าสนใจที่สุดคือ “รันโปรแกรม Linux แบบไม่ต้องแก้ไขบน Windows”
      ที่ผ่านมารู้สึกว่า WSL2 เหมือนวิธีแก้ขัด ส่วน WSL1 ต่างหากที่เป็นตัวอย่างที่ดีของแนวคิด “personality modules” ของ Windows NT
    • มีการพูดถึงเพิ่มเติมใน เธรด Reddit และ โพสต์นำเสนอของ James Morris
    • เลยสงสัยว่านี่อาจเป็นแนวคิดแบบ WSLv1.2 ที่กลายเป็น ไฟร์วอลล์แบบไลบรารี ข้ามแพลตฟอร์มที่ใช้งานได้กว้างขึ้นหรือไม่
    • README มี คำศัพท์เชิงการตลาดทางเทคนิค เยอะมาก จนใช้เวลาพอสมควรกว่าจะเข้าใจว่าโปรเจกต์นี้ทำอะไรจริง ๆ
      ดูเหมือนเป็นตัวอย่างคลาสสิกของ Microsoft ที่เอาแนวคิดเดิมมาแพ็กชื่อใหม่ให้ดูเหมือนนวัตกรรม

  • ช่วงนี้ OS หลักของ Microsoft เต็มไปด้วยบั๊ก มาก จนรู้สึกว่ายากจะเชื่อใจโปรเจกต์ใหม่ที่ออกมา

    • Microsoft มีวิศวกรมากกว่าแสนคน ดังนั้นจะเหมารวมว่าทุกผลิตภัณฑ์แย่เพราะ Windows มีบั๊กก็คงไม่ยุติธรรมนัก
    • แม้ UI ของ Windows จะไม่นิ่ง แต่ส่วนเคอร์เนลและระดับล่างกลับค่อนข้างเสถียรและทำได้ดี
    • LiteBox ไม่ได้เป็นตัวแทน Windows และก็ไม่ใช่ GUI desktop OS
      ทีมที่พัฒนาสิ่งนี้น่าจะไม่เกี่ยวอะไรกับ Windows UX ยุคปัจจุบันเลย
    • แม้จะรู้ว่า Windows 11 โดนด่าเรื่องบั๊กกับปัญหา Copilot แต่ในฟอรัมแบบนี้ก็ดูเหมือนจะมี ปรากฏการณ์ echo chamber ที่ลดค่าผลิตภัณฑ์เพียงเพราะมาจาก Microsoft
    • Windows นั้นปิดและซับซ้อน แต่ LiteBox ทำงานอยู่บนระบบนิเวศ Linux จึงคาดหวังได้ว่าวัฒนธรรมวิศวกรรมจะต่างออกไป

  • ในรีโพของ LiteBox มี ไฟล์ตั้งค่าที่เกี่ยวกับ Copilot รวมอยู่ด้วย
    copilot-instructions.md

    • ทุกวันนี้หลายองค์กรกำหนดให้ใช้ AI เพื่อให้บรรลุ OKR ดังนั้นการมีการตั้งค่าแบบนี้ก็ถือว่าปกติ
    • ในทางปฏิบัติ โปรเจกต์ส่วนใหญ่ก็น่าจะมี โค้ดที่ AI สร้าง อยู่ในระดับหนึ่งแล้ว
      นี่แค่เป็นการแสดงการตั้งค่านั้นอย่างชัดเจนเท่านั้นเอง
    • มีข้อความว่า “การเปลี่ยนแปลงที่ง่ายมากไม่จำเป็นต้องมี unit test” ซึ่งถ้าไม่กำหนด กฎข้อยกเว้น แบบนี้ไว้ให้ชัด LLM ก็มักจะทำตามสัญชาตญาณไม่ได้

  • สงสัยว่า ‘Library OS’ คืออะไร

    • มันคือโครงสร้างที่นำอินเทอร์เฟซที่เดิม OS เป็นผู้ให้บริการอยู่ เช่น syscall, ioctl ฯลฯ มา ลิงก์เข้าแอปโดยตรงในรูปแบบไลบรารี
      กล่าวคือความสามารถของ OS ถูกรวมเข้าไปใน address space ของแอปพลิเคชัน และอินเทอร์เฟซภายนอกจะเปลี่ยนเป็นการเข้าถึงฮาร์ดแวร์หรือ hypercall
      Unikernel ก็ทำงานในลักษณะนี้ และ Wine ก็อาจมองได้ว่าเป็น Library OS ในความหมายกว้าง
      ตัวอย่างเช่น ลิงก์แอป Linux เข้ากับ LiteBox เพื่อรันบน SEV-SNP หรือรัน OP-TEE TA บน Linux
      แก่นสำคัญคือแทนที่จะต้องตรวจสอบ syscall ของ POSIX หลายร้อยรายการ ก็ทำให้เรียบง่ายเหลือเพียงการควบคุม primitive operations ของ intermediate representation ไม่กี่อย่าง
    • พูดง่าย ๆ คือเป็นแซนด์บ็อกซ์ที่ลิงก์ OS เหมือนไลบรารี และเปิดเผย API ของระบบจริงในรูปแบบที่ย่อส่วนลงเพื่อ ลดพื้นผิวการโจมตี
    • ดูคำอธิบายของ Wikipedia ประกอบได้

  • ถ้าต้องอธิบายความต่างระหว่าง Library OS กับแอปที่อิงเคอร์เนลให้มนุษย์ต่างดาวฟัง ก็รู้สึกว่า ต่างกันแบบละเอียดอ่อนจนยากจะอธิบายจริงจัง

    • ถ้าเป็น Library OS แบบแท้จริง จะ ไม่มี system call และทำงานอยู่ในพื้นที่เดียวกันโดยไม่มีการแบ่ง user/kernel space

  • ตอนแรกนึกว่า ‘Library OS’ หมายถึงระบบปฏิบัติการสำหรับห้องสมุด

    • ผมก็เหมือนกัน นึกถึงของเก่าอย่าง Dynix แล้วก็แอบรู้สึก nostalgic อยู่พักหนึ่ง
    • เข้าใจว่าถ้าลิงก์ OS เข้าไปแล้ว ก็จะเป็นโครงสร้างที่สามารถ รันตรงบน supervisor ได้ โดยไม่ต้องมี OS แยกต่างหาก
    • ตอนแรกคิดว่า “OS สำหรับห้องสมุดสาธารณะ ฟังดูน่าสนใจดี” แต่พอไม่ใช่ก็แอบเสียดายเล็กน้อย

  • ตอนแรกไม่คุ้นกับแนวคิด Library OS แต่พอฟังคำอธิบายแล้วก็รู้สึกว่า คล้าย Unikernel
    โปรแกรมรันตรงบนไฮเปอร์ไวเซอร์โดยไม่ต้องเรียก kernel mode และ LiteBox ก็สามารถทำงานเป็น Linux·Windows·BSD process ได้ด้วย

    • มองอีกมุมหนึ่ง มันก็ดูเหมือนแซนด์บ็อกซ์ที่โปรแกรมไม่ได้ใช้ OS โดยตรง แต่ถูกแยกให้รันอยู่ภายใน อินเทอร์เฟซร่วม
      เพียงแต่ยังไม่ชัดว่ามันใช้ ABI ของตัวเองหรือใช้ ABI ของ host OS
      จากคำอธิบายแล้วก็ให้ความรู้สึกเหมือนเป็นโปรเจกต์แบบ ‘vibe-coded’ อยู่บ้าง

  • ถ้า Microsoft ทำให้ LiteBox สามารถเขียน ไดรเวอร์ WFP callout ได้โดยไม่ต้องเซ็น ก็คิดว่าน่าสนใจมาก
    มันยังคงทำงานใน kernel mode อยู่ดี แต่ก็อาจยืดหยุ่นกว่า NetworkExtensions ของ MacOS

  • น่าเสียดายที่ไม่มีการพูดถึงขั้นตอนการพัฒนาที่อิงกับสเปกการออกแบบและ formal verification
    แม้จะเป็นความพยายามที่น่าสนใจ แต่ถ้าไม่มีแนวทางแบบนี้ ก็เสี่ยงที่ ช่องโหว่ด้านความปลอดภัย แบบเดิม ๆ ของ Windows จะกลับมาอีก

    • ทุกวันนี้ดูเหมือนจะมีแนวโน้มที่คนเชื่อว่าแค่เขียนด้วย Rust ก็ ปลอดภัยโดยอัตโนมัติ

  • เพิ่งเคยได้ยินคำว่า “Library OS” เป็นครั้งแรก เลยสงสัยว่า gVisor จัดอยู่ในกลุ่มนี้ด้วยหรือไม่
    มันดูมีโครงสร้างคล้ายกัน แต่ก็ไม่แน่ใจว่าอยู่ในหมวดเดียวกันแบบเป๊ะ ๆ หรือเปล่า
 
picopress 2026-02-09

ไม่ได้เจอโปรเจ็กต์ที่ดูน่าสนใจแบบนี้มาพักใหญ่แล้วนะ