เคอร์เนลที่ปนเปื้อนใน Linux คืออะไร?

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

สิ่งนี้หมายความว่า? มันส่งผลกระทบต่อความสามารถในการใช้ระบบของฉันหรือไม่และจะมีผลกับตัวเลือกการสนับสนุนของฉันอย่างไร

เมื่อเคอร์เนลปนเปื้อนก็หมายความว่ามันอยู่ในสภาพที่ไม่ได้รับการสนับสนุนจากชุมชน นักพัฒนาเคอร์เนลส่วนใหญ่จะไม่สนใจรายงานข้อผิดพลาดที่เกี่ยวข้องกับเมล็ดที่เสียและสมาชิกชุมชนอาจขอให้คุณแก้ไขเงื่อนไขการเสียก่อนที่พวกเขาจะสามารถดำเนินการวินิจฉัยปัญหาที่เกี่ยวข้องกับเคอร์เนลได้ นอกจากนี้ฟังก์ชันการดีบักบางอย่างและการเรียก API อาจถูกปิดใช้งานเมื่อเคอร์เนลเสีย

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

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

เคอร์เนลอาจเสียเนื่องจากสาเหตุหลายประการรวมถึง (แต่ไม่ จำกัด เพียง) ต่อไปนี้:

• การใช้โมดูลเคอร์เนลที่เป็นกรรมสิทธิ์ (หรือไม่รองรับ GPL) ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดของเมล็ดปนเปื้อนและมักเกิดจากการโหลดไดรเวอร์วิดีโอ NVIDIA หรือ AMD ที่เป็นกรรมสิทธิ์
• การใช้ไดรเวอร์stagingซึ่งเป็นส่วนหนึ่งของซอร์สโค้ดเคอร์เนล แต่ยังไม่ผ่านการทดสอบอย่างสมบูรณ์
• การใช้โมดูลout-of-treeที่ไม่ได้รวมอยู่ในซอร์สโค้ดเคอร์เนล Linux
• การบังคับให้โหลดหรือยกเลิกการโหลดโมดูลเคอร์เนล (เช่นการบังคับให้ใส่โมดูลที่ไม่ได้สร้างขึ้นสำหรับเคอร์เนลเวอร์ชันปัจจุบัน)
• การใช้เคอร์เนล SMP (มัลติโปรเซสเซอร์) บน CPU ที่ไม่ได้รับการสนับสนุนตัวประมวลผลบางตัวซึ่งส่วนใหญ่เป็นโปรเซสเซอร์ AMD Athlon รุ่นเก่า
• การเอาชนะACPI DSDT บางครั้งจำเป็นต้องแก้ไขข้อบกพร่องการจัดการพลังงาน (ดูรายละเอียดที่นี่ )
• เงื่อนไขข้อผิดพลาดที่สำคัญบางอย่างเช่นข้อยกเว้นการตรวจสอบเครื่องและเคอร์เนล oopses
• ข้อบกพร่องร้ายแรงบางอย่างในเฟิร์มแวร์ระบบ (BIOS, UEFI) ซึ่งเคอร์เนลต้องแก้ไข

แต่ละเงื่อนไขเหล่านี้ถูกแสดงด้วยแฟล็กเฉพาะในเคอร์เนล ผู้จำหน่าย Linux บางรายเช่น SUSE เพิ่มแฟลก taint เพิ่มเติมเพื่อระบุเงื่อนไขเช่นการโหลดโมดูลที่ผู้ขายไม่สนับสนุน

ข้อมูลเพิ่มเติมสามารถดูได้ในเอกสาร kernel ธงมัวหมองที่ระบุไว้มี (พร้อม _ a แสตนอินสำหรับ 'ว่าง')

• G | P : G หากโมดูลทั้งหมดที่โหลดมี GPL หรือใบอนุญาตที่เข้ากันได้มิฉะนั้นจะมีการโหลดโมดูลที่เป็นกรรมสิทธิ์ โมดูลที่ไม่มี MODULE_LICENSE หรือ MODULE_LICENSE ที่ insmod ไม่รู้จักเนื่องจาก GPL ที่ใช้งานร่วมกันได้นั้นถือว่าเป็นกรรมสิทธิ์
• F | _ : หากโมดูลใดถูกโหลดโดย "insmod -f" มิฉะนั้นถ้าโมดูลทั้งหมดถูกโหลดตามปกติ
• S | _ : หาก oops เกิดขึ้นในเคอร์เนล SMP ที่ทำงานบนฮาร์ดแวร์ที่ไม่ได้รับการรับรองว่าปลอดภัยในการเรียกใช้มัลติโปรเซสเซอร์ ปัจจุบันนี้เกิดขึ้นเฉพาะกับ Athlons ที่ไม่สามารถใช้ SMP ได้
• R | _ : หากโมดูลถูกยกเลิกการโหลดโดยrmmod -fมิฉะนั้นหากโมดูลทั้งหมดถูกยกเลิกการโหลดตามปกติ
• M | _ : หากตัวประมวลผลใด ๆ ได้รายงานข้อยกเว้นการตรวจสอบเครื่องมิฉะนั้นจะไม่มีข้อยกเว้นการตรวจสอบเครื่องเกิดขึ้น
• B | _ : หากฟังก์ชั่นการปล่อยเพจพบการอ้างอิงหน้าเว็บที่ไม่ดีหรือการตั้งค่าหน้ากระดาษที่ไม่คาดคิด
• U | _ : หากผู้ใช้หรือแอปพลิเคชันผู้ใช้ร้องขอเป็นพิเศษให้ตั้งค่าสถานะการปนเปื้อน
• D | _ : หากเคอร์เนลเสียชีวิตเมื่อเร็ว ๆ นี้นั่นคือมีOOPSหรือ BUG
• A | _ : หากตาราง ACPI ถูกเขียนทับ
• W | _ : หากคำเตือนออกมาก่อนหน้าโดยเคอร์เนล (แม้ว่าคำเตือนบางอย่างอาจตั้งค่าสถานะมัวหมองเฉพาะเจาะจงมากขึ้น)
• C | _ : หากโหลดไดรฟ์ทดสอบแล้ว
• I | _ : หากเคอร์เนลกำลังแก้ไขข้อบกพร่องที่รุนแรงในแพลตฟอร์มเฟิร์มแวร์ (BIOS หรือคล้ายกัน)
• O | _ : หากโหลดโมดูลที่สร้างขึ้นภายนอก ("out-of-tree")
• E | _ : หากโมดูลที่ไม่ได้ลงชื่อได้รับการโหลดในเคอร์เนลที่สนับสนุนลายเซ็นโมดูล
• L | _ : หาก soft lockup เกิดขึ้นก่อนหน้านี้ในระบบ
• K | _ : หากเคอร์เนลได้รับการแก้ไขสด