ค่าใช้จ่ายที่เพิ่มสูงขึ้นของการโจมตีทางไซเบอร์ได้ผลักดันให้ความปลอดภัยของหน่วยความจำจากเรื่องกังวลทางวิชาการกลายเป็นความเร่งด่วนระดับสูง ในขณะที่โซลูชันระดับฮาร์ดแวร์อย่าง CHERI ได้รับการสนับสนุนจากสถาบันต่างๆ ชุมชนเทคโนโลยีกำลังอภิปรายอย่างจริงจังว่าแนวทางทางเลือกอาจให้ความเข้ากันได้ ประสิทธิภาพ หรือการรับประกันความปลอดภัยที่ดีกว่าสำหรับสภาพแวดล้อมการคำนวณที่แตกต่างกันหรือไม่
ทางเลือกด้านซอฟต์แวร์ท้าทายความโดดเด่นของฮาร์ดแวร์
ในขณะที่ CHERI และ OMA เป็นโซลูชันระดับฮาร์ดแวร์ นักพัฒนาบางส่วนแย้งว่าแนวทางแบบซอฟต์แวร์อาจบรรลุประโยชน์ด้านความปลอดภัยที่ใกล้เคียงกันโดยไม่ต้องใช้ซิลิกอนรุ่นใหม่ ตัวอย่างหนึ่งที่ถูกพูดถึงคือ Fil-C การนำความปลอดภัยแบบ capability-based ไปใช้ในซอฟต์แวร์ซึ่งรักษาความเข้ากันได้กับ C/C++ โดยไม่เปลี่ยนขนาดของพอยน์เตอร์
Fil-C ที่ทำงานบนเครื่อง x86 ใดๆ ก็ตามทำงานเร็วกว่าการนำ CHERI ไปใช้ใดๆ ที่เคยมีมา นั่นน่าจะเป็นจริงแม้ในระบบ embedded เพียงเพราะความสัมพันธ์ระหว่างปริมาณและประสิทธิภาพในซิลิกอน
มุมมองนี้เน้นยึงถึงความตึงเครียดที่สำคัญในการนำความปลอดภัยของหน่วยความจำไปใช้: การแลกเปลี่ยนระหว่างโซลูชันซอฟต์แวร์ที่ใช้ได้ทันทีและการเปลี่ยนแปลงฮาร์ดแวร์ในระยะยาว ผู้สร้าง Fil-C ระบุว่าแนวทางของพวกเขารักษาความเข้ากันได้กับฐานโค้ดที่มีอยู่เช่น CPython ซึ่งรายงานว่าไม่ทำงานบนระบบ CHERI เนื่องจากการจัดการพอยน์เตอร์ในการใช้งาน bytecode
ช่องว่างด้านความปลอดภัยชั่วคราว
ความแตกต่างทางเทคนิคหลักที่ปรากฏในการอภิปรายมุ่งเน้นไปที่ความปลอดภัยชั่วคราว - การป้องกันการเข้าถึงหน่วยความจำหลังจากที่มันถูกปล่อยแล้ว การวิเคราะห์ของชุมชนเปิดเผยว่าแนวทางของ CHERI ต่อปัญหานี้เผชิญกับการวิพากษ์วิจารณ์ โดยมีผู้แสดงความคิดเห็นท่านหนึ่งระบุว่า เรื่องราวของ CHERI นั้น อ่อนมาก เมื่อเทียบกับการเก็บกวาดขยะที่รวมอยู่ในฮาร์ดแวร์ของ OMA
การอภิปรายเปิดเผยว่า CHERI ไม่ได้ตรวจจับข้อผิดพลาด use-after-free ทันทีเสมอไป หากโปรแกรมทำงานเร็วพอระหว่างการปล่อยหน่วยความจำและการทำให้พอยน์เตอร์ไร้ผล ขีดจำกัดนี้ได้กระตุ้นให้มีการวิจัยแนวทางเสริมเช่น Cornucopia-Reloaded ซึ่งทำให้ capability ไร้ผลเมื่อโหลดพอยน์เตอร์ไปยังหน้าหน่วยความจำที่ถูกปล่อยแล้ว ในขณะเดียวกัน การเก็บกวาดขยะระดับฮาร์ดแวร์ของ OMA มุ่งหมายที่จะให้การรับประกันความปลอดภัยชั่วคราวที่แน่นอน
ความกังวลเรื่องความเข้ากันได้และอุปสรรคในการนำไปใช้
ความเข้ากันได้ทางเทคนิคปรากฏเป็นหัวข้อหลักทั่วทั้งกระทู้แสดงความคิดเห็น ชุมชนระบุถึงความท้าทายสำคัญในการย้ายซอฟต์แวร์ที่มีอยู่ไปสู่สถาปัตยกรรมใหม่เหล่านี้ โดยมุ่งความสนใจไปที่เคอร์เนลของระบบปฏิบัติการและรันไทม์ของภาษาเป็นพิเศษ
ผู้แสดงความคิดเห็นท่านหนึ่งตั้งคำถามว่า OMA ต้องการ ISA + kernel + userland ใหม่ทั้งหมดหรือไม่ ซึ่งเน้นย้ำถึงการเปลี่ยนแปลงทั่วทั้งระบบนิเวศที่จำเป็นสำหรับการนำไปใช้เต็มรูปแบบ บางคนระบุว่าโค้ด C ในเคอร์เนลโดยทั่วไปไม่ได้รับการจัดรูปแบบที่ดีในลักษณะที่จะปรับตัวเข้ากับระบบหน่วยความจำแบบออบเจ็กต์ได้ง่ายๆ ชี้ให้เห็นว่าความพยายามทางวิศวกรรมอย่างมากจะต้องไม่ว่าสถาปัตยกรรมใดจะชนะ
ข้อกังวลหลักของชุมชน
- ความเข้าใช้งานร่วมกันได้: CPython และโค้ดเคอร์เนลมีความท้าทายในการพอร์ต
- การนำมาใช้งาน: การเข้าถึงฮาร์ดแวร์เฉพาะทางที่จำกัดทำให้การพัฒนาช้าลง
- ประสิทธิภาพ: การแลกเปลี่ยนระหว่างโอเวอร์เฮดด้านความปลอดภัยกับความเร็ว
- ความปลอดภัยเชิงเวลา: แนวทางฮาร์ดแวร์เทียบกับซอฟต์แวร์ในการป้องกัน use-after-free
- แหล่งที่มา: คำถามเกี่ยวกับต้นกำเนิดของเทคโนโลยีและความเป็นเจ้าของสิทธิบัตร
โซลูชันที่มีอยู่และข้อจำกัดของพวกมัน
การสนทนาไม่จำกัดอยู่แค่เทคโนโลยีเกิดใหม่ ผู้แสดงความคิดเห็นชี้ไปที่คุณสมบัติความปลอดภัยของหน่วยความจำที่มีอยู่เช่น SPARC Application Data Integrity (ADI) และ Arm Memory Tagging Extensions (MTE) ที่เคยถูกใช้ในสภาพแวดล้อมการผลิต อย่างไรก็ตาม แนวทางเหล่านี้เผชิญกับการวิพากษ์วิจารณ์สำหรับการให้ความปลอดภัยแบบความน่าจะเป็นผ่านแท็กที่กำหนดโดยซอฟต์แวร์ซึ่งผู้ไม่ประสงค์ดีอาจเดาหรือปลอมแปลงได้
การละเมิดล่าสุดของ Arm MTE แสดงให้เห็นถึงข้อจำกัดของแนวทางเหล่านี้ แม้ว่าผู้แสดงความคิดเห็นจะยอมรับว่าบางครั้งความสมบูรณ์แบบก็เป็นศัตรูของสิ่งที่ดีเมื่อพูดถึงการนำความปลอดภัยไปใช้ ลักษณะความน่าจะเป็นของโซลูชันเหล่านี้ขัดแย้งกับการรับประกันความปลอดภัยที่พิสูจน์ได้ทางคณิตศาสตร์ของ CHERI และ OMA
การเปรียบเทียบแนวทางความปลอดภัยของหน่วยความจำ
| แนวทาง | ประเภท | คุณสมบัติหลัก | ความปลอดภัยเชิงเวลา | กรณีการใช้งานหลัก |
|---|---|---|---|---|
| CHERI | ฮาร์ดแวร์ | ตัวชี้แบบ Capability-based | ใช้ซอฟต์แวร์ | ระบบฝังตัว โครงสร้างพื้นฐานที่สำคัญ |
| OMA | ฮาร์ดแวร์ | หน่วยความจำแบบ Object-based | การเก็บขยะด้วยฮาร์ดแวร์ | ภาษาที่มีการจัดการ ศูนย์ข้อมูล |
| Fil-C | ซอฟต์แวร์ | Capabilities แบบล่องหน | การทำงานด้วยซอฟต์แวร์ | ระบบ x86 ที่มีอยู่แล้ว |
| Arm MTE | ฮาร์ดแวร์ | การแท็กหน่วยความจำ | แบบความน่าจะเป็น | อุปกรณ์มือถือ |
| SPARC ADI | ฮาร์ดแวร์ | การแท็กหน่วยความจำ | แบบความน่าจะเป็น | เซิร์ฟเวอร์องค์กร |
ถนนสู่การนำไปใช้อย่างแพร่หลาย
แม้จะมีคำมั่นสัญญาทางเทคนิค แต่ความรู้สึกของชุมชนชี้ให้เห็นว่าทั้ง CHERI และ OMA ต่างเผชิญกับอุปสรรคสำคัญในการนำไปใช้ ลักษณะพิเศษของฮาร์ดแวร์ CHERI - โดยมีผู้แสดงความคิดเห็นท่านหนึ่งระบุว่านักพัฒนาส่วนใหญ่ไม่มีโอกาสได้ใช้มัน - เน้นย้ำถึงปัญหาว่าไก่กับไข่อะไรเกิดก่อนหน้าที่สถาปัตยกรรมความปลอดภัยใหม่ๆ กำลังเผชิญ
การสนับสนุนของรัฐบาลสำหรับ CHERI ผ่านโปรแกรมเช่น initiative Digital Security by Design ของสหราชอาณาจักรอาจช่วยเอาชนะอุปสรรคเหล่านี้สำหรับแอปพลิเคชันเฉพาะได้ อย่างไรก็ตาม ความต้านทานต่อการเปลี่ยนแปลงพื้นฐานของระบบนิเวศการคำนวณที่กว้างขึ้นชี้ให้เห็นว่าความปลอดภัยของหน่วยความจำอาจมาถึงผ่านการปรับปรุงทีละน้อยมากกว่าการแทนที่แบบปฏิวัติ
สรุป
การอภิปรายของชุมชนเปิดเผยภาพภูมิทัศน์ที่ซับซ้อนซึ่งไม่มีโซลูชันใดโซลูชันหนึ่งครอบงำ แนวทางฮาร์ดแวร์เช่น CHERI และ OMA ให้การรับประกันความปลอดภัยที่แข็งแกร่งแต่เผชิญกับความท้าทายด้านความเข้ากันได้และการนำไปใช้ โซลูชันซอฟต์แวร์เช่น Fil-C ให้ประโยชน์ทันทีบนฮาร์ดแวร์ที่มีอยู่แต่อาจขาดการพิสูจน์ความปลอดภัยที่เข้มงวดในระดับเดียวกัน เมื่อความปลอดภัยของหน่วยความจำมีความสำคัญมากขึ้นเรื่อยๆ ความหลากหลายของแนวทางสะท้อนถึงความต้องการที่หลากหลายของอุตสาหกรรมการคำนวณและการยอมรับว่าสภาพแวดล้อมที่แตกต่างกันอาจต้องการโซลูชันที่แตกต่างกันเพื่อแก้ไขความท้าทายด้านความปลอดภัยพื้นฐานนี้
อ้างอิง: Two Paths to Memory Safety: CHERI and OMA in the Fight Against Cyber Threats