จะไม่มี ‘วันศุกร์สีน้ำเงิน’ อีกต่อไป
(brendangregg.com)- เหตุระบบ Windows ล่มทั่วโลกเมื่อวันที่ 19 กรกฎาคม 2024 เป็นกรณีที่การอัปเดตไดรเวอร์เคอร์เนลของผลิตภัณฑ์รักษาความปลอดภัยนำไปสู่ การอ่านหน่วยความจำผิดพลาด จนเกิดจอฟ้าและวนบูตซ้ำ
- eBPF ทำงานภายในเคอร์เนล แต่ถูกออกแบบให้ตัวตรวจสอบและแซนด์บ็อกซ์ปฏิเสธโค้ดที่เป็นอันตราย เพื่อไม่ให้โปรแกรมเพียงตัวเดียวทำให้ทั้งระบบแครชได้
- Linux มี eBPF อยู่แล้ว และเมื่อ eBPF for Windows ของ Microsoft พร้อมใช้งานในโปรดักชัน ซอฟต์แวร์รักษาความปลอดภัยบน Windows ก็สามารถย้ายไปใช้แนวทางเดียวกันได้
- บริษัทเทคโนโลยีขนาดใหญ่อย่าง Google, Meta, Cisco และสตาร์ทอัปด้านความปลอดภัยที่ใช้ eBPF กำลังขยายผลิตภัณฑ์และระบบตรวจจับความปลอดภัย โดยใช้ประโยชน์จากความเร็ว การมองเห็นเชิงลึก และหลักประกันด้านความปลอดภัย
- องค์กรที่ซื้อซอฟต์แวร์เชิงพาณิชย์ซึ่งมีเคอร์เนลไดรเวอร์หรือเคอร์เนลโมดูล สามารถกำหนดให้ รองรับ eBPF เป็นข้อกำหนดสำหรับเวนเดอร์ได้ตั้งแต่ตอนนี้บน Linux และในเร็ว ๆ นี้บน Windows
ความเสี่ยงของโค้ดเคอร์เนลที่เหตุ Windows ล่มวันที่ 19 กรกฎาคมเผยให้เห็น
- เหตุขัดข้องเมื่อวันที่ 19 กรกฎาคม 2024 เป็นกรณีที่ไม่เคยมีมาก่อน ซึ่งแสดงให้เห็นถึงความเสี่ยงโดยธรรมชาติของการเขียนโปรแกรมระดับเคอร์เนล
- คอมพิวเตอร์ Windows ทั่วโลกเจอ จอฟ้า(blue screen of death) และวนบูตซ้ำ ส่งผลให้โรงพยาบาล สายการบิน ธนาคาร ร้านขายของชำ และสถานีโทรทัศน์เกิดปัญหาขัดข้อง
- สาเหตุคือ การอัปเดตการตั้งค่า(config update) ของผลิตภัณฑ์รักษาความปลอดภัยที่ใช้กันอย่างแพร่หลาย โดยผลิตภัณฑ์ดังกล่าวมีเคอร์เนลไดรเวอร์สำหรับระบบ Windows รวมอยู่ด้วย
- หลังการอัปเดต เคอร์เนลไดรเวอร์พยายามอ่านหน่วยความจำผิดตำแหน่ง และข้อผิดพลาดประเภทนี้สามารถทำให้เคอร์เนลแครชได้
แครชที่ eBPF สามารถป้องกันได้
- eBPF ไม่ใช่ตัวย่ออีกต่อไป แต่เป็น สภาพแวดล้อมการรันในเคอร์เนลที่ปลอดภัย คล้ายกับรันไทม์ JavaScript ที่ปลอดภัยซึ่งฝังอยู่ในเว็บเบราว์เซอร์
- ผู้ใช้ Linux มีแนวโน้มสูงที่จะมี eBPF อยู่ในระบบแล้ว เพราะ eBPF ถูกบรรจุเข้าในเคอร์เนล Linux เมื่อหลายปีก่อน
- โปรแกรม eBPF ถูกจำกัดไว้ไม่ให้ทำให้ทั้งระบบแครชได้
- ตัวตรวจสอบ(verifier) ของซอฟต์แวร์จะตรวจสอบความปลอดภัย
- โปรแกรมทำงานอยู่ภายในแซนด์บ็อกซ์โดยพฤตินัย
- หากตัวตรวจสอบพบโค้ดที่ไม่ปลอดภัย โปรแกรมจะถูกปฏิเสธและไม่ถูกเรียกใช้งาน
- ตัวตรวจสอบในอิมพลีเมนต์ของ Linux ประกอบด้วยโค้ดมากกว่า 20,000 บรรทัด โดยมีการมีส่วนร่วมจากภาคอุตสาหกรรมอย่าง Meta, Isovalent, Google และภาควิชาการอย่าง Rutgers University และ University of Washington
- ความปลอดภัยที่แข็งแกร่งขึ้น การใช้ทรัพยากรต่ำ และการป้องกันแครชคือข้อดีหลักของ eBPF
ความเป็นไปได้ในการใช้งานบน Linux และ Windows
- บริษัทความปลอดภัยที่ทำให้เกิดเหตุขัดข้องครั้งนี้อยู่ใน กระบวนการนำ eBPF มาใช้ บนระบบ Linux อยู่แล้ว
- เมื่อ eBPF support for Windows ของ Microsoft พร้อมใช้งานในโปรดักชัน ซอฟต์แวร์รักษาความปลอดภัยบน Windows ก็สามารถพอร์ตไปใช้ eBPF ได้
- เอเจนต์ความปลอดภัยบน Windows ที่ย้ายไปใช้ eBPF แล้ว จะอยู่ในรูปแบบที่ไม่สามารถทำให้เคอร์เนล Windows แครชได้
การยอมรับในอุตสาหกรรมความปลอดภัยและบริษัทเทคโนโลยีขนาดใหญ่
- สตาร์ทอัปด้านความปลอดภัยที่ใช้ eBPF อย่าง Oligo และ Uptycs เน้นย้ำข้อดีของการย้ายจากแนวทางก่อน eBPF หลังเหตุขัดข้องล่าสุด
- บริษัทเทคโนโลยีขนาดใหญ่ก็กำลังนำ eBPF มาใช้เพื่อความปลอดภัยเช่นกัน
- Cisco เข้าซื้อสตาร์ทอัป eBPF อย่าง Isovalent และประกาศ Cisco Hypershield ซึ่งเป็นแฟบริกสำหรับการบังคับใช้นโยบายความปลอดภัยและการมอนิเตอร์
- Google และ Meta ใช้ความเร็ว การมองเห็นเชิงลึก และหลักประกันด้านความปลอดภัยของ eBPF เพื่อตรวจจับและบล็อกพฤติกรรมไม่พึงประสงค์ในสภาพแวดล้อมขนาดใหญ่
- นอกจากด้านความปลอดภัยแล้ว eBPF ยังใช้กับ เครือข่าย และ การสังเกตการณ์(observability) ด้วย
ข้อจำกัดของ eBPF และมาตรการเสริมด้านปฏิบัติการ
- สิ่งเลวร้ายที่สุดที่โปรแกรม eBPF ทำได้คือใช้ทรัพยากรในระดับที่ไม่พึงประสงค์มากขึ้น เช่น รอบ CPU หรือหน่วยความจำ
- แม้จะไม่ได้ป้องกันโค้ดที่สิ้นเปลืองทรัพยากรได้ทั้งหมด แต่จะสกัดปัญหาร้ายแรงที่นำไปสู่การแครชของระบบ
- eBPF ก็เป็นเทคโนโลยีใหม่ จึงเคยมีบั๊กในโค้ดจัดการ และยังมีกรณี Linux kernel panic ที่บริษัทความปลอดภัยรายเดียวกับที่ปรากฏในข่าวล่าสุดค้นพบ
- หากแก้บั๊กเหล่านี้ใน eBPF การแก้ไขจะมีผลกับเวนเดอร์ eBPF ทุกราย ทำให้ยกระดับความปลอดภัยโดยรวมได้เร็วขึ้น
- ความเสี่ยงในการดีพลอยไม่ได้จบลงด้วย eBPF เพียงอย่างเดียว ยังมีเทคนิคด้านปฏิบัติการที่ใช้ร่วมกันได้
- การทดสอบแบบคานารี
- การทยอยโรลเอาต์เป็นขั้น ๆ
- วิศวกรรมความยืดหยุ่นโดยทั่วไป
การเปลี่ยนแปลงที่ผู้ซื้อสามารถเรียกร้องได้
- จุดสำคัญของแนวทาง eBPF คือเป็นโซลูชันซอฟต์แวร์ที่จะมีให้เป็นพื้นฐานทั้งในเคอร์เนล Linux และ Windows และถูกนำมาใช้กับกรณีใช้งานนี้แล้ว
- หากองค์กรจ่ายเงินซื้อซอฟต์แวร์เชิงพาณิชย์ที่มีเคอร์เนลไดรเวอร์หรือเคอร์เนลโมดูล ก็สามารถทำให้ eBPF เป็นข้อกำหนด ได้
- บน Linux ทำได้แล้ววันนี้ และบน Windows จะทำได้ในเร็ว ๆ นี้
- เวนเดอร์บางรายนำ eBPF มาใช้เชิงรุกแล้ว แต่เวนเดอร์รายอื่นอาจต้องอาศัยความต้องการจากลูกค้าที่จ่ายเงิน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เมื่อดูรายการ “hook” ที่ eBPF สำหรับ Windows มีให้ ดูเหมือนจะห่างจากความเป็นจริงอยู่พอสมควร ตอนนี้มีแค่แพ็กเก็ตขาเข้าและงานเกี่ยวกับ socket เท่านั้น จึงอยู่ในระดับที่ Microsoft คาดหวังให้ใช้ Berkeley Packet Filter ตามตัวอักษรคือเพื่อ กรองแพ็กเก็ต
ซึ่งต่างจากจุดจำนวนมากที่ไดรเวอร์อย่าง CrowdStrike ผูกไว้กับเคอร์เนล NT เช่น การกรอง I/O, การสร้าง/ใช้งานอ็อบเจ็กต์
นอกจากนี้ หากต้องการเฝ้าตรวจขยะจาก third-party อื่น ๆ ที่รันใน kernel space ตัว anti-malware เองก็ต้องอยู่ในเคอร์เนลด้วย ELAM (early-launch anti-malware) จะโหลดไดรเวอร์ anti-malware ก่อน เพื่อให้เฝ้าตรวจพฤติกรรมของไดรเวอร์อื่น ๆ ได้ แต่ก็ยังน่าสงสัยมากว่า eBPF จะทำสิ่งแบบนี้ได้หรือไม่
หาก Microsoft จะใช้ eBPF มาแทนที่ไดรเวอร์ anti-malware ใน kernel space ก็ยังมีทางอีกยาวไกลมาก
https://microsoft.github.io/ebpf-for-windows/ebpf__structs_8...
เปรียบเทียบได้กับสถานการณ์ที่ผู้คนทำธุรกรรมธนาคารผ่านเว็บไซต์ JavaScript บน Google Chrome แต่ใน Microsoft Edge กลับบอกว่า “เราไม่รองรับ JavaScript โปรดดาวน์โหลด .EXE นี้ไปรัน” ประเด็นจึงใกล้เคียงกับคำถามว่า Microsoft จะรองรับ JavaScript หรือ eBPF “เมื่อไหร่” มากกว่าจะรองรับ “หรือไม่”
ไม่ได้อยากโต้แย้งกับคนอย่าง Brendan Gregg แต่หวังว่าผู้ขายในวงการนี้จะ ตรวจสอบอย่างรอบด้าน มากขึ้นทั้งห่วงโซ่ของความขัดข้องทั้งหมด เวลามีข้อเสนอออกมา 3 วันหลังเกิดเหตุว่า “x จะแก้ปัญหาที่เกิดขึ้นเมื่อวันที่ y” ก็ทำให้ระมัดระวังขึ้น
มันอาจถูกก็ได้ แต่หากไม่วิเคราะห์ก็อาจยังมีจุดบอดเหลืออยู่ และอาจมีทางเลือกอีกมากที่เมื่อพิจารณาแล้วควรถูกตัดทิ้งอย่างเหมาะสม
โดยเฉพาะส่วนที่ว่า “ผลลัพธ์เชิงลบที่เลวร้ายที่สุดมีแค่เปลือง CPU” นั้นเห็นด้วยได้ยาก สำหรับบั๊กบางประเภทอาจเป็นเช่นนั้น แต่ก็มีโหมดความล้มเหลวมากมายที่ชุดกฎผิดพลาดสามารถทำให้ระบบกลายเป็น brick อย่างรุนแรงและกู้คืนได้ยาก
ไม่ได้หมายความว่าโมดูลความปลอดภัยบน eBPF อาจไม่ใช่ตัวเลือกที่ถูกต้องสำหรับผู้ขายจำนวนมาก แต่หมายถึงควรทำความเข้าใจว่าเราหลีกเลี่ยงความเสี่ยงอะไรได้บ้าง อะไรหลีกเลี่ยงไม่ได้ และมันจัดการส่วนใดของห่วงโซ่ความขัดข้อง
https://opensource.microsoft.com/blog/2021/05/10/making-ebpf...
https://lwn.net/Articles/857215/
หากมีข้อกังวลจริง ๆ ก็มีช่องทางหารือให้แสดงความคิดเห็น และมีการรวบรวมไว้บน GitHub
https://github.com/microsoft/ebpf-for-windows
อาจมีคำตอบอยู่แล้วก็ได้ และถ้ายังไม่มี ก็สามารถนำไปพูดคุยกันที่นั่นได้
แบบนี้ไม่ถูกต้อง ถ้าระบบมีโครงสร้างที่ต้องมีโค้ดบางส่วนจึงจะรันได้ เมื่อโค้ดนั้นพัง ระบบก็ควรจะรันไม่ได้เลย การเพิกเฉยต่อความล้มเหลวเป็นเรื่องแปลก
เช่น ถ้าโค้ดไดรเวอร์ของอุปกรณ์การแพทย์บางอย่างรับประกัน กลไกล็อกนิรภัย เพื่อไม่ให้เผาคน ผมคงเลือกให้ทั้งระบบหยุดทำงาน มากกว่าปล่อยให้ทำงานเหมือนไม่มีอะไรเกิดขึ้นทั้งที่ระบบนิรภัยถูกปิดอยู่
สุดท้ายไล่ลงไปก็ยังเป็นปัญหาเดิมอยู่ดี
ไม่รู้ว่า Linux ทำจริง ๆ อย่างไร แต่เราก็จินตนาการถึงโลกที่ทำให้ตั้งค่าพฤติกรรมต่ออินพุตที่ไม่ถูกต้องได้
อีกอย่าง คำพูดนั้นก็ไม่ได้จริงเสมอไป กรณีทั่วไปผมเห็นด้วย แต่ในบางบริบทมันต้องเดินหน้าต่อ ตัวอย่างที่นึกออกทันทีคือคอมพิวเตอร์นำวิถีของยานลงจอดบนดาวอังคารแบบอัตโนมัติ ความหน่วงไปกลับกับโลกยาวเกินกว่าจะโยนความรับผิดชอบให้ใครได้
ถ้าปิดตัวก็จะตก แต่ถ้าทำดีที่สุดในสภาพที่เสียหายก็อาจแค่ตกอยู่ดี ดังนั้นทางหลังอาจดีกว่า
ถ้าทั้งระบบปฏิบัติการกลายเป็นอิฐขึ้นมา ต้องให้ช่าง IT มาแก้เอง ซึ่งเป็นปัญหาใหญ่กว่ามาก ถ้าไม่เป็นแบบนั้นก็แค่อัปเดตไดรเวอร์ที่มีข้อบกพร่องก็พอแล้ว
รถยนต์ก็ไม่ได้สตาร์ทไม่ติดเพราะน้ำฉีดกระจกหมด
องค์กรส่วนใหญ่ที่ได้รับผลกระทบเมื่อวันศุกร์น่าจะชอบทางที่ความเสี่ยงต่อการถูกโจมตีด้วยมัลแวร์หรือการใช้งานโดยไม่ได้รับอนุญาตเพิ่มขึ้นเล็กน้อยเป็นเวลา 24 ชั่วโมง มากกว่าการล่มสลายของ IT ทั้งหมดที่เกิดขึ้นจริง
ยิ่งกว่านั้น บั๊กนั้นก็ไม่ได้จำเป็นต้องทำให้เกิดจอฟ้าเสมอไป ระบบอาจทำงานต่อไปในสถานะที่ไม่ถูกกำหนดและมีผลลัพธ์ที่ไร้ขอบเขตก็ได้
ถ้าเป็น eBPF อย่างน้อยก็ตรวจจับข้อผิดพลาดบางส่วนที่เป็นไปได้ และตัดสินใจจัดการความเสี่ยงตามผลลัพธ์นั้นได้
ถ้าจะอัปเดต ผู้เรียกต้องเรียกฟังก์ชันอื่น ดังนั้นความรับผิดชอบจึงอยู่กับผู้เรียก ไม่ใช่กับคนที่สามารถไปแตะเคอร์เนลทางอ้อมได้
ถ้าไม่มีฟังก์ชันที่ตรงกับแฮชที่ระบุ ก็เรียกไม่ได้ และต่อให้มี ก็เรียกนอกเหนือจากวิธีที่ตั้งใจไว้ไม่ได้ จึงได้คุณสมบัติแบบ “ทำงานอย่างสมบูรณ์หรือไม่ทำงานเลย” ตามที่ต้องการ
อีกอย่าง ปฏิกิริยาต่อสถานะที่ผิดพลาดก็ไม่จำเป็นต้องเป็น “เพิกเฉย” เสมอไป อาจปิดการล็อกอินของผู้ใช้แบบจำกัด หรือปิดหน้าจอก็ได้
ถ้ากังวลว่ามัลแวร์จะใช้ช่องนี้ในทางที่ผิด ผมก็สงสัยว่าในสถานการณ์ที่มัลแวร์สามารถแก้เขียนไฟล์บนดิสก์ของแอนติไวรัสได้อยู่แล้ว การเชื่อว่าตัวระบบเองจะจัดการเรื่องนั้นได้เป็นความคิดที่ดีหรือไม่
การรายงานไปยังระบบชั้นบนด้านความปลอดภัย แล้วให้ระบบภายนอกดำเนินการปิดหรือจำกัดการเข้าถึงเครือข่าย อาจปลอดภัยกว่า ยิ่งไปกว่านั้น มาตรการแบบนี้ต้องการแค่สิทธิ์ในการสังเกต ไม่ใช่สิทธิ์ในการแทรกแซงระบบ จึงลดโอกาสที่ระบบแอนติไวรัสเองจะกลายเป็นเส้นทางของมัลแวร์หรือสาเหตุของบั๊กแบบนี้ด้วย
eBPF ยอดเยี่ยมและใช้ได้หลายวัตถุประสงค์ ช่วยปรับปรุงอะไรได้มากมาย แต่คำว่า “คอมพิวเตอร์จะไม่แครชเพราะการอัปเดตซอฟต์แวร์ที่แย่” ดูจะพูดเกินจริง
ต่อให้สมมติว่า BPF เองไม่มีบั๊ก ขอบเขตของเคอร์เนลฮุกก็ยังค่อนข้างกว้าง ฮุกเหล่านั้นเรียกโค้ด eBPF และโค้ดนั้นก็สามารถเรียกกลับเข้าเคอร์เนลได้
https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html
โดยเฉพาะ bpf_probe_read_kernel() ถูกใช้บ่อยมาก แต่ไม่ปลอดภัย มีความพยายามมากพอสมควรเพื่อหลีกเลี่ยง OOPS หรือการแครช แต่ไม่มีทางสมบูรณ์แบบ
ในรายการที่เหลือก็มีหลายอย่างที่ทำให้ระบบพังได้ง่าย แม้จะไม่ได้ทำให้เกิด oops หรือ panic จริง ๆ ก็ตาม
และถ้าเป็นเครื่องมือที่ตรวจจับและบล็อก “พฤติกรรมไม่พึงประสงค์” ใน user space มันก็อาจเริ่มตัดสินว่าทุกอย่างเป็นพฤติกรรมไม่พึงประสงค์จนทำให้ใช้คอมพิวเตอร์ไม่ได้
อีกด้านหนึ่ง eBPF ไม่มีโมเดลความปลอดภัยจริง ๆ ฝั่ง user space การแนบโปรแกรม eBPF จริง ๆ ทำผ่าน bpf() system call ไม่ใช่การดำเนินการด้านสิทธิ์ที่สมเหตุสมผลต่อออบเจ็กต์เคอร์เนลเป้าหมายที่จะไปแนบ และไม่มีอะไรเลยที่กัก eBPF ที่คอนเทนเนอร์ใช้ไว้ภายในคอนเทนเนอร์นั้น bpf_probe_read_kernel() โดยเนื้อแท้แล้วอ่านหน่วยความจำเคอร์เนลได้ทั้งหมด
ดังนั้นข้อดีของ eBPF เมื่อเทียบกับโค้ด C ในเคอร์เนลทั่วไป คือมันคล้ายกับการเขียนโค้ดด้วยภาษาที่ปลอดภัยซึ่งมีพื้นผิว API แบบ unsafe ที่จำกัด สำหรับงานประเภทนี้ถือว่าเป็นการปรับปรุงครั้งใหญ่ แต่ก็ไม่สมบูรณ์แบบเลย
มีคนบอกว่าตัวตรวจสอบเข้มงวดและการใช้งานจริงของ Linux มีมากกว่า 20,000 บรรทัด แต่ตัวตรวจสอบนั้นซับซ้อนอย่างเหลือเชื่อ ผมอยากเห็นฐานที่ใช้ formal methods มากกว่าตรรกะที่เขียนด้วยมือ 20,000 บรรทัด
รู้สึกสงสัยกับคำพูดที่ว่า “โปรแกรม eBPF ผ่านการตรวจสอบความปลอดภัยโดยตัวตรวจสอบซอฟต์แวร์ และโดยพฤตินัยแล้วทำงานอยู่ใน sandbox จึงไม่สามารถทำให้ทั้งระบบแครชได้”
หนึ่งในวัตถุประสงค์ของระบบปฏิบัติการไม่ใช่การคอยเฝ้าระวังซอฟต์แวร์หรือ? ผมรู้ว่านี่เป็นปัญหาที่เกี่ยวกับตัวระบบปฏิบัติการเอง แต่ถ้าเพิ่มชั้นที่คอยเฝ้าระวังผู้เฝ้าระวัง สุดท้ายก็ต้องมีใครมาคอยเฝ้าระวังชั้นนั้นอีกไม่ใช่หรือ?
เราเลือก ลดความซับซ้อน แทนที่จะเชื่ออย่างไร้เดียงสาว่าความซับซ้อนใหม่จะดีกว่าในระยะยาวไม่ได้หรือ?
วิธีเดิมคือโหลด kernel driver, hook system call จำนวนมาก แล้วภาวนาว่าจะไม่ทำพัง ถ้าพลาดก็อาจเกิด panic ได้ แต่ Linux ค่อนข้างแข็งแกร่ง
วิธีของ eBPF ใกล้เคียงกับการขอข้อมูลที่ต้องการด้วย คำสั่งเฉพาะของ eBPF มากกว่า
ภาพรวมวิธีทำงานอยู่ที่นี่: https://ebpf.io/what-is-ebpf/
ฟังดูเหมือนเทคโนโลยีที่เจ๋ง แต่ประเด็นที่ร้ายแรงจริง ๆ คือส่วนที่ว่า “สามารถใช้วิธีลดความเสี่ยงในการปล่อยซอฟต์แวร์ เช่น canary test, การทยอย rollout, และ resilience engineering ได้ด้วย”
การนำ การควบคุมคุณภาพ ซึ่งเป็นมาตรฐานพื้นฐานของอุตสาหกรรมมาใช้ ไม่จำเป็นต้องมีเทคโนโลยีใหม่
เพื่อเป็นการรำลึกถึงเหตุการณ์ครั้งนี้ อาจเริ่มหยุดงานวันศุกร์กันไปเลยก็ได้ ถ้าผู้คนถูกกดดันให้ทำงานน้อยลง และมีเวลาหยุดคิดมากขึ้นว่าสถานการณ์กำลังไหลไปทางไหน และตัวเองจะส่งผลต่อกระแสนั้นได้อย่างไร ความเสียหายก็น่าจะน้อยลง
คำอธิบายที่ว่าตัวตรวจสอบของ implementation บน Linux มีมากกว่า 20,000 บรรทัด และมีทั้งภาคอุตสาหกรรมกับสถาบันการศึกษาช่วยกันพัฒนา กลับไม่ได้ทำให้อุ่นใจเลย นอกจาก attack surface ที่เพิ่มขึ้นแล้ว ใครจะรับประกัน codebase ใหญ่ขนาดนั้นได้?
ตัวตรวจสอบของ WebAssembly ให้ความรู้สึกว่าเรียบง่ายกว่ามาก
ถ้า filter ถูกโหลดตอนบูตและ hook เข้ากับทุกอย่าง บั๊กเพียงตัวเดียวอาจทำให้ระบบถูกล็อกจนถึงระดับที่สั่งการหรือแพตช์ไม่ได้ ตัวอย่างเช่นกรณีโหลด allowlist ว่าง ๆ ซึ่งสุดท้ายอาจกลายเป็นการเปลี่ยน boot loop ให้เป็นการปฏิเสธการให้บริการอีกรูปแบบหนึ่ง
ถ้า Microsoft ใส่องค์ประกอบสำคัญที่จำเป็นต่อการกู้คืนไว้ใน allowlist แบบ hardcoded ก็อาจแก้บั๊กของเครื่องมือแบบนี้ได้ง่ายขึ้น แต่จนกว่าการแก้ไขจะถูกปล่อยออกมา ระบบอาจเปิดอยู่ก็จริงแต่ใช้งานไม่ได้ ทำให้เกิด downtime จริงในทางปฏิบัติ
ในบล็อกเขียนไว้ว่า “eBPF มีภูมิคุ้มกันต่อแครชแบบนี้”
ลองค้นดูแล้วแต่ยังไม่เจอข้อมูลที่ชัดเจน และยังดูเหมือนว่ามันสามารถทำอะไรบางอย่างพังได้อยู่ อยากให้ผู้เชี่ยวชาญ eBPF อธิบายข้ออ้างนี้ให้ฟัง แหล่งข้อมูลที่ดีที่สุดที่เจอคืออันนี้: https://stackoverflow.com/questions/70403212/why-is-ebpf-sai...