[lec02-pre] 6.566: Computer Systems Security - LXC, gVisor, Firecracker
Reading ก่อน Lecture 2 ของ 6.566 -- Computer Systems Security พูดถึง OS and VM isolation และเปรียบเทียบแนวทางหลักอย่าง LXC, gVisor และ Firecracker
โจทย์พื้นฐานคือ ในระบบสมัยใหม่ โดยเฉพาะ serverless และ container platform เรามักต้องรัน application จำนวนมากจากผู้ใช้หลายคนอยู่บน physical server เครื่องเดียวกัน บาง workload อาจเป็น untrusted code ดังนั้นระบบต้องทำให้ application เหล่านี้ไม่สามารถเข้าถึงหรือรบกวนกันได้
เรื่องนี้มี trade-off ระหว่าง security กับ overhead
ตัวอย่างเช่น ถ้า server มี RAM 1 TB และ serverless application หนึ่งตัวใช้เพียง 128 MB ในเชิง resource เราสามารถใส่ application จำนวนหลายพันตัวลงในเครื่องเดียวได้ ยิ่งสามารถ pack workload ได้หนาแน่นเท่าไร infrastructure ก็ยิ่งมีประสิทธิภาพ แต่ isolation ระหว่าง workload ก็ต้องแข็งแรงเพียงพอด้วย
แนวทางในการสร้าง isolation มีหลายระดับ ตั้งแต่ Linux container, language-specific isolation เช่น JVM ไปจนถึง virtualization ที่ใช้ hardware feature
LXC เป็นแนวทางที่ใกล้กับ baseline Linux container มากที่สุด โดยแต่ละ container ใช้ host Linux kernel ร่วมกัน แล้วอาศัยกลไกของ OS ในการแยก process และ resource ออกจากกัน
ข้อดีคือมี overhead ต่ำ เพราะไม่ต้องสร้าง kernel ใหม่สำหรับทุก workload แต่ isolation boundary ยังขึ้นอยู่กับ shared host kernel ถ้า workload เป็น untrusted code ความเสียหายจากช่องโหว่ใน kernel จึงอาจข้ามขอบเขตของ container ได้
gVisor เลือกแนวทางที่ต่างออกไป โดยเพิ่ม layer ระหว่าง application กับ host kernel
แทนที่ application จะส่ง system call เข้า Linux kernel โดยตรง gVisor จะ intercept system call เหล่านั้น และมี user-space kernel ของตัวเองคอย implement interface ที่ application คาดหวัง
ผลคือ application ได้เห็น environment ที่คล้าย Linux แต่เข้าถึง host kernel โดยตรงได้น้อยลง ซึ่งช่วยลด attack surface
gVisor เขียนด้วย Go และไม่จำเป็นต้องพึ่ง hardware virtualization แบบเดียวกับ KVM แต่การมี layer เพิ่มขึ้นก็ทำให้ workload บางประเภทมี overhead มากกว่า container ปกติ โดยเฉพาะกรณีที่ต้องใช้ system call หรือ I/O จำนวนมาก
Firecracker ใช้อีกแนวทาง คือ virtualization ผ่าน KVM ซึ่งเป็น virtualization mechanism ใน Linux kernel
ต่างจาก container ที่แชร์ kernel กัน แต่ละ Firecracker microVM สามารถมี guest kernel ของตัวเอง ทำให้ isolation boundary อยู่ใกล้กับ virtual machine มากกว่า container
ปัญหาคือ VM แบบทั่วไปมักมี overhead สูงเกินไปสำหรับ workload อย่าง serverless ที่ต้องสร้างและทำลาย instance จำนวนมากอย่างรวดเร็ว
Firecracker จึงออกแบบเป็น lightweight virtual machine monitor หรือ VMM โดยลดจำนวน virtual devices และ functionality ที่ไม่จำเป็น เพื่อให้ microVM มีขนาดเล็ก เริ่มทำงานได้เร็ว และลด attack surface เมื่อเทียบกับ VM แบบทั่วไป
Firecracker ถูกพัฒนาโดย Amazon บน KVM และมีต้นกำเนิดบางส่วนจาก crosvm ของ Google ก่อนจะถูกนำไปใช้กับ infrastructure อย่าง AWS Lambda และ AWS Fargate
ดังนั้นสามแนวทางนี้จึงเลือก isolation boundary ต่างกัน
LXC พึ่ง host Linux kernel โดยตรง จึงเบาและเร็ว แต่แชร์ kernel ระหว่าง workload
gVisor เพิ่ม user-space kernel เพื่อไม่ให้ application ติดต่อ host kernel โดยตรงใน system call ส่วนใหญ่
Firecracker ใช้ hardware virtualization และแยก guest kernel ออกจาก host ทำให้ isolation ใกล้เคียง VM แต่พยายามลด overhead ให้เหมาะกับ workload จำนวนมาก
ไม่มีแนวทางใดเหมาะกับทุกสถานการณ์ การเลือกจึงขึ้นอยู่กับ workload และ threat model
ถ้า workload ค่อนข้าง trusted และต้องการ performance กับ density สูง LXC อาจเหมาะกว่า
ถ้าต้องการ isolation มากกว่า container ปกติ แต่ไม่ต้องการใช้ VM เต็มรูปแบบ gVisor เป็นอีกจุดหนึ่งใน design space
ถ้าต้องรัน untrusted code ใน multi-tenant environment และต้องการ isolation boundary ที่แข็งแรงกว่า shared kernel ขณะเดียวกันยังต้องรองรับการสร้าง instance จำนวนมาก Firecracker เป็นแนวทางที่ออกแบบมาเพื่อตอบโจทย์ลักษณะนี้
Reading นี้จึงเป็นการเปรียบเทียบว่าเราสามารถวาง isolation boundary ไว้ตรงไหนได้บ้าง ตั้งแต่ OS kernel, user-space kernel ไปจนถึง hardware virtualization และแต่ละทางเลือกต้องแลก security กับ performance และ resource overhead ในระดับที่ต่างกัน