ไม่มี Blue Friday อีกต่อไป

 (brendangregg.com)
1 คะแนน โดย GN⁺ 2024-07-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • ในอนาคต คอมพิวเตอร์จะไม่ล่มจากการอัปเดตซอฟต์แวร์ที่มีโค้ดเคอร์เนลรวมอยู่ด้วยอีกต่อไป โดยต่อจากนี้การอัปเดตลักษณะนี้จะผลักโค้ด eBPF แทน

  • เมื่อวันที่ 19 กรกฎาคม 2024 ได้เกิดเหตุหยุดชะงักครั้งใหญ่ที่สุดครั้งหนึ่งในประวัติศาสตร์เทคโนโลยีสารสนเทศ

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

  • บนระบบ Linux มีการนำ eBPF มาใช้แล้ว จึงสามารถป้องกันการล่มแบบนี้ได้

    • eBPF มอบสภาพแวดล้อมการรันบนเคอร์เนลที่ปลอดภัย
    • โปรแกรม eBPF จะถูกตรวจสอบความปลอดภัยผ่าน software verifier และโค้ดที่ไม่ปลอดภัยจะไม่ถูกรัน
    • eBPF ให้ทั้งความปลอดภัยสูงและการใช้ทรัพยากรต่ำ

  • สตาร์ทอัพด้านความปลอดภัยที่ใช้ eBPF และบริษัทเทคโนโลยีรายใหญ่ก็กำลังนำ eBPF มาใช้เช่นกัน

    • Cisco เข้าซื้อ Isovalent ซึ่งเป็นสตาร์ทอัพ eBPF และประกาศผลิตภัณฑ์ความปลอดภัย eBPF ตัวใหม่
    • Google และ Meta ใช้ eBPF อยู่แล้วเพื่อตรวจจับและบล็อกพฤติกรรมที่เป็นอันตราย

  • สิ่งที่แย่ที่สุดที่โปรแกรม eBPF ทำได้คือใช้ทรัพยากรมากเกินไป

    • eBPF ป้องกันระบบล่มได้ แต่ไม่สามารถหยุดการเขียนโค้ดที่ไม่มีประสิทธิภาพได้
    • โค้ดจัดการ eBPF เองก็อาจมีบั๊กได้ แต่เมื่อแก้บั๊กเหล่านี้ ความปลอดภัยของผู้ให้บริการ eBPF ทุกรายก็จะดีขึ้น

  • ยังมีวิธีอื่นในการลดความเสี่ยงระหว่างการปล่อยซอฟต์แวร์

    • เช่น canary test, การ rollout แบบค่อยเป็นค่อยไป และ resilience engineering
    • แนวทาง eBPF เป็นโซลูชันซอฟต์แวร์ที่ใช้งานได้โดยตรงในเคอร์เนลของ Linux และ Windows

  • บริษัทที่ใช้ซอฟต์แวร์เชิงพาณิชย์ซึ่งมีเคอร์เนลไดรเวอร์หรือโมดูลรวมอยู่ สามารถเรียกร้องให้ใช้ eBPF ได้

    • บน Linux ทำได้อยู่แล้ว และบน Windows ก็จะทำได้ในไม่ช้า
    • ผู้ขายบางรายได้นำ eBPF มาใช้แล้ว และจำเป็นต้องเพิ่มการรับรู้ของลูกค้า

สรุปของ GN⁺

  • บทความนี้เน้นย้ำความสำคัญของ eBPF ในการแก้ปัญหาระบบล่มจากการอัปเดตโค้ดเคอร์เนล
  • eBPF มอบสภาพแวดล้อมการรันบนเคอร์เนลที่ปลอดภัย และสามารถป้องกันระบบล่มได้
  • บริษัทเทคโนโลยีรายใหญ่ก็นำ eBPF มาใช้แล้ว และมันมีข้อดีทั้งด้านความปลอดภัยและการใช้ทรัพยากร
  • eBPF ช่วยลดความเสี่ยงในการปล่อยซอฟต์แวร์ได้ และจำเป็นต้องเพิ่มการรับรู้ของลูกค้า

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-23
ความคิดเห็นจาก Hacker News

  • ถ้าการรองรับ eBPF ของ Microsoft บน Windows พร้อมใช้งานจริงระดับโปรดักชัน ซอฟต์แวร์ความปลอดภัยบน Windows ก็อาจพอร์ตไปใช้ eBPF ได้

    • ในความเป็นจริงไม่ค่อยเป็นไปได้
    • "hooks" ของ eBPF บน Windows ใช้สำหรับการกรองแพ็กเก็ตเท่านั้น
    • ต่างจากไดรเวอร์อื่นที่เชื่อมกับเคอร์เนล NT, eBPF มีข้อจำกัดมากกว่า
    • eBPF จะใช้เวลาอีกนานกว่าจะมาแทนที่ไดรเวอร์แอนตี้มัลแวร์ใน kernel space ได้

  • ไม่เห็นด้วยกับคำกล่าวที่ว่าสิ่งเลวร้ายที่สุดที่โปรแกรม eBPF ทำได้คือใช้ CPU cycle และหน่วยความจำมากขึ้น

    • โปรแกรม eBPF อาจสร้างความเสียหายได้ไม่จำกัด
    • การย้ายโค้ดจากเคอร์เนลไปไว้ใน BPF อาจช่วยบรรเทาช่องโหว่บางประเภทได้
    • แต่นั่นไม่ได้หมายความว่าโดยทั่วไปแล้วโปรแกรม eBPF จะปลอดภัย

  • ไม่อยากโต้เถียงกับ Brendan Gregg แต่หวังว่าผู้ขายจะใช้แนวทางที่ครอบคลุมในการตรวจสอบสายโซ่ความล้มเหลวทั้งหมด

    • สำหรับบั๊กบางประเภท การสิ้นเปลือง CPU cycle อาจเป็นผลเสียเพียงอย่างเดียว
    • มีกลไกความล้มเหลวหลายแบบที่ชุดกฎที่ไม่ดีอาจทำให้ระบบพังได้
    • โมดูลความปลอดภัยที่อิง eBPF อาจเหมาะกับผู้ขายหลายราย แต่สิ่งสำคัญคือต้องเข้าใจความเสี่ยง

  • เมื่อโค้ดพัง ระบบก็ควรไม่สามารถทำงานต่อได้

    • ถ้ากลไกล็อกด้านความปลอดภัยของอุปกรณ์การแพทย์ไม่ทำงาน การให้ทั้งระบบหยุดทำงานจะดีกว่า

  • ถ้าสมมติว่า eBPF ช่วยแก้ปัญหาเฉพาะบางอย่างบน Windows ได้ Microsoft ก็ไม่ควรคง backward compatibility เอาไว้

    • backward compatibility เป็นประเด็นสำคัญมากในโลกของ Windows
    • การจัดการโค้ดและแนวทางเก่า ๆ ของ NT จะเป็นประโยชน์มากกว่า

  • โปรแกรม eBPF ถูกตรวจสอบความปลอดภัยโดยตัวตรวจสอบซอฟต์แวร์และรันใน sandbox จึงไม่สามารถทำให้ทั้งระบบแครชได้

    • หนึ่งในเป้าหมายของระบบปฏิบัติการคือการคอยกำกับดูแลซอฟต์แวร์
    • การลดความซับซ้อนเป็นสิ่งที่ดีกว่า

  • ไม่จำเป็นต้องมีเทคโนโลยีใหม่

    • ควรใช้วิธีการควบคุมคุณภาพพื้นฐาน

  • ควรกำหนดให้วันศุกร์เป็นวันหยุด เพื่อให้ผู้คนมีเวลาคิดมากขึ้น

  • ถ้า eBPF มีบั๊ก ก็อาจทำให้ Windows kernel แครชได้

  • หากโหลดฟิลเตอร์ตอนบูตและผูกเข้ากับทุกอย่าง ก็อาจล็อกระบบได้

    • ถ้า Microsoft ใส่ whitelist ที่ฮาร์ดโค้ดไว้ซึ่งรวมรายการจำเป็นสำหรับการกู้คืน ก็อาจช่วยให้แก้บั๊กได้ง่ายขึ้น