รายละเอียดทางเทคนิคเกี่ยวกับ Control Flow Integrity
"ความพร้อมใช้งานของตัวชี้ฟังก์ชันจำนวนมากในเคอร์เนลช่วยให้รูปแบบการโจมตีนี้ได้รับความนิยม แม้ว่าผู้โจมตีจะไม่สามารถแทรกโค้ดปฏิบัติการของตนเองได้ แต่ส่วนต่างๆ ของโค้ดเคอร์เนลที่มีอยู่ก็สามารถดำเนินการได้ตามอำเภอใจเพื่อให้การหาประโยชน์เสร็จสมบูรณ์
LLVMCFI ของพยายามบรรเทาการโจมตีเหล่านี้โดยการจำกัดเป้าหมายการโทรที่ถูกต้อง และบังคับให้เคอร์เนลตื่นตระหนกเมื่อตรวจพบการละเมิด CFI มีการเพิ่มเช็คก่อนแต่ละสาขาทางอ้อมเพื่อยืนยันว่าที่อยู่เป้าหมายชี้ไปยังฟังก์ชันที่ถูกต้องพร้อมลายเซ็นที่ถูกต้อง สิ่งนี้จะป้องกันไม่ให้สาขาทางอ้อมข้ามไปยังตำแหน่งรหัสที่กำหนดเองและยังจำกัดฟังก์ชันที่สามารถเรียกใช้ได้ ผู้โจมตีจะยังคงสามารถเปลี่ยนตัวชี้ฟังก์ชันได้ หากข้อบกพร่องอนุญาตให้เข้าถึงได้ แต่ CFI ของ LLVM จำกัดการโทรทางอ้อม 55% ไว้ที่สูงสุด 5 เป้าหมายที่เป็นไปได้ และ 80% สูงสุด 20 เป้าหมาย เพื่อกำหนดเป้าหมายการโทรที่ถูกต้องทั้งหมดสำหรับแต่ละสาขาทางอ้อม คอมไพลเลอร์จำเป็นต้องดูโค้ดเคอร์เนลทั้งหมดในครั้งเดียว
การใช้งาน LTO (การเพิ่มประสิทธิภาพเวลาลิงก์) ทำให้สิ่งนี้เป็นไปได้ CFI ของ LLVM ต้องการการใช้ LTO โดยที่คอมไพเลอร์สร้างบิตโค้ดเฉพาะ LLVM สำหรับ C ทั้งหมด หน่วยการคอมไพล์และตัวเชื่อมโยง LTO-aware ใช้แบ็กเอนด์ LLVM เพื่อรวมบิตโค้ดและคอมไพล์ลงใน รหัสพื้นเมือง
นอกเหนือจากการอนุญาตให้ใช้ CFI แล้ว LTO ยังได้รับประสิทธิภาพรันไทม์ที่ดีขึ้นผ่านการวิเคราะห์ทั้งโปรแกรมและการเพิ่มประสิทธิภาพข้ามโมดูล
ThinLTO เกือบจะตามทันการปรับปรุงประสิทธิภาพของ LTO ในโหมด ThinLTO เช่นเดียวกับ LTO ทั่วไป เสียงดังกราว ปล่อยบิตโค้ด LLVM หลังจากขั้นตอนการคอมไพล์ บิตโค้ด ThinLTO ได้รับการเสริมด้วยการสรุปแบบย่อของโมดูล ในระหว่างขั้นตอนการเชื่อมโยง เฉพาะข้อมูลสรุปเท่านั้นที่จะถูกอ่านและรวมเข้ากับดัชนีสรุปแบบรวม ซึ่งรวมถึงดัชนีของตำแหน่งฟังก์ชันสำหรับการนำเข้าฟังก์ชันข้ามโมดูลในภายหลัง หลังจากนั้นการวิเคราะห์ทั้งโปรแกรมอย่างรวดเร็วและมีประสิทธิภาพจะดำเนินการบนดัชนีสรุปแบบรวม ThinLTO อนุญาตให้มีกระบวนการเชื่อมโยงแบบมัลติเธรด ซึ่งส่งผลให้เวลาในการคอมไพล์ลดลง
เนื่องจาก CFI ขัดจังหวะการทำงานของโปรแกรมเมื่อโจมตีคลาสข้อบกพร่องบางประเภท CFI จึงจัดเป็นเครื่องมือค้นหาข้อบกพร่องตามที่กล่าวไว้ก่อนหน้านี้ เมื่อใช้ในโหมดอนุญาต CFI ที่อนุญาตจะแสดงการละเมิด CFI ในบันทึกเคอร์เนล โดยไม่บังคับให้เคอร์เนลตื่นตระหนก เคอร์เนลคอร์ 4.9 (อุปกรณ์รุ่น Pixel 3) และ 4.14 (อุปกรณ์รุ่น Pixel 4) มีฟังก์ชันหลายประเภท ไม่ตรงกันส่งผลให้เกิดการละเมิด CFI ซึ่งได้รับการแก้ไขโดย Google ในชุดแพตช์ที่มีอยู่บนเคอร์เนล/ทั่วไป ซื้อคืน
อย่างไรก็ตาม เนื่องจากธรรมชาติของระบบนิเวศของ Android ความไม่ตรงกันเหล่านี้จึงมีแนวโน้มที่จะพบได้ในรหัสเฉพาะของผู้ผลิต SoC (ในกรณีนี้คือ Qualcomm) หรือ OEM (OnePlus) เช่นกัน การละเมิด CFI หลายครั้งในรหัส Qualcomm ที่แตกต่างจากเคอร์เนล 4.19 ได้รับการแก้ไขบนเคอร์เนล Kirisakura สำหรับ OnePlus 8 Pro (ตัวอย่าง: 1, 2, 3).
การรันเคอร์เนลใน CFI ที่อนุญาตเผยให้เห็นการละเมิด CFI ในโค้ดที่เกี่ยวข้องกับไดรเวอร์ OnePlus เช่นกัน (สามารถพบคอมมิตที่เกี่ยวข้องได้ ที่นี่ และ ที่นี่). เคอร์เนลคิริซากุระสำหรับ OnePlus 8 Pro ทำงานโดยบังคับใช้ CFI เพื่อปกป้องผู้ใช้จากการโจมตีด้วยโค้ดซ้ำประเภทนี้"
อ่านเพิ่มเติม
ผู้ชื่นชอบงาน DIY (เช่น ผู้กอบกู้ชิ้นส่วนพีซีเก่าๆ) Skanda เป็นผู้ใช้ Android ตัวยงมาตั้งแต่สมัย Eclair และชอบติดตามแนวโน้มการพัฒนาล่าสุดในโลกของการประมวลผลแบบบอร์ดเดี่ยว