Kees Cook อดีตหัวหน้าผู้ดูแลระบบของ kernel.org และผู้นำทีมรักษาความปลอดภัย Ubuntu ซึ่งปัจจุบันทำงานที่ Google เพื่อรักษาความปลอดภัย Android และ ChromeOS แสดงความกังวลเกี่ยวกับกระบวนการปัจจุบันในการแก้ไขข้อบกพร่องในสาขาที่เสถียรของเคอร์เนล ทุกสัปดาห์ การแก้ไขประมาณร้อยรายการจะรวมอยู่ในสาขาที่มีเสถียรภาพ และหลังจากหน้าต่างสำหรับการยอมรับการเปลี่ยนแปลงในรุ่นถัดไปปิดลง จะเข้าใกล้หนึ่งพันรายการ (ผู้ดูแลจะเก็บการแก้ไขไว้จนกว่าหน้าต่างจะปิด และหลังจากการก่อตัวของ " -rc1” พวกเขาเผยแพร่รายการที่สะสมในคราวเดียว) ซึ่งมีมากเกินไปและต้องใช้แรงงานจำนวนมากในการบำรุงรักษาผลิตภัณฑ์ที่ใช้เคอร์เนล Linux
ตามข้อมูลของ Keys กระบวนการทำงานกับข้อผิดพลาดในเคอร์เนลไม่ได้รับความสนใจอย่างเหมาะสมและเคอร์เนลยังขาดนักพัฒนาเพิ่มเติมอย่างน้อย 100 คนสำหรับการประสานงานในพื้นที่นี้ นักพัฒนาเคอร์เนลหลักแก้ไขจุดบกพร่องเป็นประจำ แต่ไม่มีการรับประกันว่าการแก้ไขเหล่านี้จะถูกส่งต่อไปยังเคอร์เนลตัวแปรต่างๆ ที่บุคคลที่สามใช้ ผู้ใช้ผลิตภัณฑ์ต่างๆ ที่ใช้เคอร์เนล Linux ยังไม่มีวิธีควบคุมจุดบกพร่องที่ได้รับการแก้ไขและเคอร์เนลใดที่จะใช้ในอุปกรณ์ของตน ท้ายที่สุด ผู้ผลิตต้องรับผิดชอบต่อความปลอดภัยของผลิตภัณฑ์ของตน แต่ด้วยความเข้มข้นที่สูงมากในการเผยแพร่การแก้ไขในสาขาเคอร์เนลที่เสถียร พวกเขาต้องเผชิญกับทางเลือก - ย้ายการแก้ไขทั้งหมด เลือกพอร์ตการแก้ไขที่สำคัญที่สุด หรือเพิกเฉยต่อการแก้ไขทั้งหมด .
ทางออกที่ดีที่สุดคือการโยกย้ายเฉพาะการแก้ไขและช่องโหว่ที่สำคัญที่สุด แต่การแยกข้อผิดพลาดดังกล่าวออกจากขั้นตอนทั่วไปคือปัญหาหลัก ปัญหาจำนวนมากที่สุดที่ปรากฏขึ้นเป็นผลมาจากการใช้ภาษา C ซึ่งต้องได้รับการดูแลเป็นอย่างดีเมื่อทำงานกับหน่วยความจำและพอยน์เตอร์ ที่แย่กว่านั้นคือ โปรแกรมแก้ไขช่องโหว่ที่อาจเกิดขึ้นจำนวนมากไม่ได้มาพร้อมกับตัวระบุ CVE หรือได้รับการกำหนดตัวระบุ CVE ในช่วงระยะเวลาหนึ่งหลังจากการเผยแพร่โปรแกรมแก้ไข ในสภาพแวดล้อมดังกล่าว เป็นเรื่องยากมากสำหรับผู้ผลิตที่จะแยกการแก้ไขเล็กๆ น้อยๆ ออกจากปัญหาด้านความปลอดภัยที่สำคัญ จากสถิติพบว่ามากกว่า 40% ของช่องโหว่ได้รับการแก้ไขก่อนที่จะกำหนด CVE และโดยเฉลี่ยความล่าช้าระหว่างการเปิดตัวโปรแกรมแก้ไขและการกำหนด CVE คือสามเดือน (เช่น ในตอนแรกการแก้ไขจะถูกรับรู้เป็น เป็นข้อผิดพลาดทั่วไป แต่หลังจากผ่านไปหลายเดือนจะเห็นได้ชัดว่าช่องโหว่ได้รับการแก้ไขแล้ว)
เป็นผลให้หากไม่มีสาขาแยกต่างหากพร้อมการแก้ไขช่องโหว่และไม่ได้รับข้อมูลเกี่ยวกับการเชื่อมต่อความปลอดภัยของปัญหาเฉพาะผู้ผลิตผลิตภัณฑ์ที่ใช้เคอร์เนล Linux จะต้องถ่ายโอนการแก้ไขทั้งหมดอย่างต่อเนื่องจากสาขาที่เสถียรล่าสุด แต่งานนี้ต้องใช้แรงงานจำนวนมากและเผชิญกับการต่อต้านในบริษัทต่างๆ เนื่องจากกลัวว่าจะเกิดการเปลี่ยนแปลงแบบถดถอยซึ่งอาจขัดขวางการทำงานปกติของผลิตภัณฑ์
ขอให้เราระลึกว่าตามข้อมูลของ Linus Torvalds ข้อผิดพลาดทั้งหมดมีความสำคัญ และช่องโหว่ไม่ควรแยกออกจากข้อผิดพลาดประเภทอื่น และจัดสรรให้กับหมวดหมู่ที่มีลำดับความสำคัญสูงกว่าแยกต่างหาก ความคิดเห็นนี้อธิบายได้จากข้อเท็จจริงที่ว่าสำหรับนักพัฒนาทั่วไปที่ไม่เชี่ยวชาญเรื่องความปลอดภัย ความเชื่อมโยงระหว่างการแก้ไขและช่องโหว่ที่อาจเกิดขึ้นนั้นไม่ชัดเจน (สำหรับการแก้ไขจำนวนมาก มีเพียงการตรวจสอบแยกต่างหากเท่านั้นที่ทำให้เข้าใจว่าเกี่ยวข้องกับความปลอดภัยได้ ). ตามคำกล่าวของ Linus ผู้เชี่ยวชาญด้านความปลอดภัยจากทีมที่รับผิดชอบในการดูแลรักษาแพ็คเกจเคอร์เนลในลีนุกซ์ควรมีส่วนร่วมในการระบุช่องโหว่ที่อาจเกิดขึ้นจากแพตช์ทั่วไป
Kees Cook เชื่อว่าทางออกเดียวในการรักษาความปลอดภัยของเคอร์เนลด้วยต้นทุนระยะยาวที่สมเหตุสมผลคือการที่บริษัทต่างๆ จะต้องย้ายวิศวกรที่เกี่ยวข้องกับการย้ายการแก้ไขไปยังเคอร์เนลภายในเครื่องให้เป็นความพยายามร่วมกันและประสานงานเพื่อรักษาการแก้ไขและช่องโหว่ในเคอร์เนลหลัก (อัปสตรีม ). ในรูปแบบปัจจุบัน ผู้ผลิตหลายรายใช้เคอร์เนลเวอร์ชันล่าสุดในผลิตภัณฑ์ของตนและแบ็คพอร์ตการแก้ไขภายในบริษัท เช่น ปรากฎว่าวิศวกรในบริษัทต่างๆ ทำซ้ำงานของกันและกัน เพื่อแก้ไขปัญหาเดียวกัน
ตัวอย่างเช่น หากบริษัท 10 แห่ง ซึ่งแต่ละแห่งมีวิศวกรหนึ่งคนแบ็คพอร์ตการแก้ไขแบบเดียวกัน ได้มอบหมายวิศวกรเหล่านั้นใหม่เพื่อแก้ไขข้อบกพร่องในอัปสตรีม แทนที่จะส่งกลับการแก้ไขเพียงครั้งเดียว พวกเขาสามารถแก้ไขข้อบกพร่องที่แตกต่างกัน 10 รายการเพื่อผลประโยชน์ร่วมกัน หรือเข้าร่วมในการทบทวนข้อเสนอที่เสนอ เปลี่ยนแปลงและป้องกันไม่ให้โค้ด buggy รวมอยู่ในเคอร์เนล ทรัพยากรยังสามารถนำไปใช้ในการสร้างเครื่องมือใหม่สำหรับการทดสอบและวิเคราะห์โค้ดที่จะช่วยให้ตรวจพบข้อผิดพลาดทั่วไปที่เกิดขึ้นซ้ำแล้วซ้ำอีกตั้งแต่เนิ่นๆ
Kees Cook ยังแนะนำให้มากขึ้นโดยใช้การทดสอบอัตโนมัติและการทดสอบแบบคลุมเครือโดยตรงในกระบวนการพัฒนาเคอร์เนล โดยใช้ระบบบูรณาการอย่างต่อเนื่อง และละทิ้งการจัดการการพัฒนาที่ล้าสมัยผ่านทางอีเมล ในปัจจุบัน การทดสอบที่มีประสิทธิผลถูกขัดขวางเนื่องจากข้อเท็จจริงที่ว่ากระบวนการทดสอบหลักถูกแยกออกจากการพัฒนาและเกิดขึ้นหลังจากการเผยแพร่แล้ว คีย์ยังแนะนำให้ใช้ภาษาที่ให้ความปลอดภัยในระดับที่สูงกว่า เช่น Rust เมื่อพัฒนาเพื่อลดจำนวนข้อผิดพลาด
ที่มา: opennet.ru