ช่องโหว่ใน eBPF ช่วยให้สามารถป้องกันการโจมตีจาก Spectre ได้pass

เมื่อวานนี้เราเผยแพร่ที่นี่ในบล็อกข่าวเกี่ยวกับ Aya ห้องสมุดสำหรับสร้างไดรเวอร์ eBPF ใน Rust และมีวัตถุประสงค์เพื่อสร้างไดรเวอร์ที่ปลอดภัยยิ่งขึ้นหรือ โครงการ Prossimo เพื่อให้แน่ใจว่าหน่วยความจำ ของเคอร์เนล Linux ที่มี Rust (สองโปรเจ็กต์ที่ยอดเยี่ยมที่จะให้อะไรหลายๆ

และนั่นก็คือ ในเวลาสั้นๆ ก็มีการรายงานจุดอ่อนต่างๆ ซึ่งใน ใช้ประโยชน์จากข้อบกพร่องใน eBPF และเป็นปัญหาที่นักพัฒนาเคอร์เนลไม่หยุดทำงานและบางที Rust อาจเป็นวิธีแก้ปัญหา

เหตุที่ลงเอยในหัวข้อนี้คือ ล่าสุดได้ออกข่าวว่าได้ระบุตัว ช่องโหว่ "อื่นๆ" ในเคอร์เนล Linux (CVE-2021-33624) สำหรับ การป้องกันบายพาสจากช่องโหว่ระดับ Spectre เนื่องจากสิ่งนี้ทำให้สามารถใช้ระบบย่อย eBPF เพื่อให้สามารถกำหนดเนื้อหาของหน่วยความจำอันเป็นผลมาจากการสร้างเงื่อนไขสำหรับการคาดเดาของการดำเนินการบางอย่าง

เป็นที่กล่าวขวัญกันว่าช่องโหว่ เกิดจากความล้มเหลวในตัวตรวจสอบซึ่งใช้ในการตรวจหาข้อผิดพลาดและกิจกรรมที่ไม่ถูกต้องในโปรแกรม BPF. ตัวตรวจสอบแสดงเส้นทางการเรียกใช้โค้ดที่เป็นไปได้ แต่ละเว้นตัวเลือกการแตกแขนงใดๆ ที่ไม่ถูกต้องจากมุมมองของความหมายของสถาปัตยกรรมชุดคำสั่ง

เมื่อรันโปรแกรม BPF อ็อพชันการแตกสาขาที่ผู้ตรวจสอบไม่คำนึงถึง อาจถูกคาดการณ์อย่างไม่ถูกต้องโดยตัวประมวลผล และดำเนินการในโหมดการเก็งกำไร

ในระบบที่ได้รับผลกระทบ โปรแกรม BPF ที่ไม่มีสิทธิพิเศษสามารถใช้ประโยชน์จากช่องโหว่นี้เพื่อกรองเนื้อหาของหน่วยความจำเคอร์เนลที่กำหนดเอง (และด้วยเหตุนี้หน่วยความจำกายภาพทั้งหมด) ผ่านช่องทางด้านข้าง

เช่น เมื่อวิเคราะห์การดำเนินการ "โหลด" ผู้ตรวจสอบจะถือว่าคำสั่งใช้ register ด้วยที่อยู่ที่มีค่าอยู่ในขอบเขตที่กำหนดเสมอ แต่ผู้โจมตีสามารถสร้างเงื่อนไขได้ ตามที่ โปรเซสเซอร์จะพยายามเก็งกำไรเพื่อทำการค้า ด้วยที่อยู่ที่ไม่ตรงตามเงื่อนไขการตรวจสอบ

การโจมตีของ Spectre ต้องมีสคริปต์เฉพาะในรหัสพิเศษนำไปสู่การดำเนินการตามคำสั่งแบบเก็งกำไร ด้วยการจัดการโปรแกรม BPF ที่ส่งผ่านสำหรับการดำเนินการ เป็นไปได้ที่จะสร้างคำสั่งดังกล่าวใน eBPF และกรองเนื้อหาของหน่วยความจำเคอร์เนลและพื้นที่โดยพลการของหน่วยความจำกายภาพผ่านช่องทางด้านข้าง

นอกจากนี้ คุณสามารถทำเครื่องหมายบันทึกเกี่ยวกับผลกระทบต่อประสิทธิภาพ ของทรัพย์สิน เพื่อป้องกันช่องโหว่ประเภท Spectre

บันทึกนี้สรุปผลลัพธ์ การเพิ่มประสิทธิภาพดีบักเกอร์ rr (บันทึกและเล่นซ้ำ) เมื่อ Mozilla สร้างขึ้นเพื่อแก้ไขข้อผิดพลาดที่ยากต่อการเกิดซ้ำใน Firefox การแคชการเรียกระบบที่ใช้เพื่อตรวจสอบการมีอยู่ของไดเร็กทอรีลดการดำเนินการ "rr source" สำหรับโครงการทดสอบจาก 3 นาที 19 วินาทีเป็น 36 วินาที

ผู้เขียนการเพิ่มประสิทธิภาพตัดสินใจตรวจสอบ จะเปลี่ยนไปขนาดไหน ประสิทธิภาพหลังจากปิดการป้องกัน Spectre. หลังจากบูตระบบด้วยพารามิเตอร์ "mitigations = off" เวลาดำเนินการของ "rr source" ที่ไม่มีการเพิ่มประสิทธิภาพคือ 2 นาที 5 วินาที (เร็วกว่า 1.6 เท่า) และด้วยการปรับให้เหมาะสม 33 วินาที (เร็วกว่า 9%)

อยากรู้อยากเห็น การปิดใช้งานการป้องกัน Spectre ไม่เพียงแต่ลดเวลาทำงาน ของรหัสระดับเคอร์เนลใน 1.4 ครั้ง (จาก 2 นาที 9 ถึง 1 นาที 32 วินาที) นอกจากนี้ยังลดเวลาดำเนินการในพื้นที่ผู้ใช้ลงครึ่งหนึ่ง (ตั้งแต่ 1 นาที 9 ถึง 33 วินาที) น่าจะเป็นเพราะประสิทธิภาพของแคช CPU ลดลงและ TLB จะถูกรีเซ็ตเมื่อเปิดใช้งานการป้องกัน Spectre

ปัญหาปรากฏขึ้นตั้งแต่ปล่อยเคอร์เนล 4.15 และ ได้รับการแก้ไขแล้วในรูปแบบแพทช์ซึ่งในขณะนี้ยังไม่ถึงการแจกแจงทั้งหมด ดังนั้นจึงแนะนำให้ผู้ใช้ทราบว่าขณะนี้พวกเขากำลังทำการอัปเดตที่เกี่ยวข้องทันทีที่ได้รับการแจ้งเตือน

Si คุณต้องการทราบข้อมูลเพิ่มเติมคุณสามารถตรวจสอบรายละเอียด ในลิงค์ต่อไปนี้.


แสดงความคิดเห็นของคุณ

อีเมล์ของคุณจะไม่ถูกเผยแพร่ ช่องที่ต้องการถูกทำเครื่องหมายด้วย *

*

*

  1. รับผิดชอบข้อมูล: AB Internet Networks 2008 SL
  2. วัตถุประสงค์ของข้อมูล: ควบคุมสแปมการจัดการความคิดเห็น
  3. ถูกต้องตามกฎหมาย: ความยินยอมของคุณ
  4. การสื่อสารข้อมูล: ข้อมูลจะไม่ถูกสื่อสารไปยังบุคคลที่สามยกเว้นตามข้อผูกพันทางกฎหมาย
  5. การจัดเก็บข้อมูล: ฐานข้อมูลที่โฮสต์โดย Occentus Networks (EU)
  6. สิทธิ์: คุณสามารถ จำกัด กู้คืนและลบข้อมูลของคุณได้ตลอดเวลา