Kees memasak Saya membuat catatan blog di mana telah menimbulkan kebimbangan mengenai proses pembetulan pepijat berterusan di cawangan stabil kernel Linux dan itulah sebutkan minggu demi minggu kira-kira seratus pembetulan disertakan pada cawangan stabil, yang terlalu banyak dan memerlukan banyak usaha untuk mengekalkan produk berasaskan kernel Linux.
Menurut Kees, proses pengendalian ralat kernel dipintas dan kernel kekurangan sekurang-kurangnya 100 pembangun tambahan untuk bekerja secara teratur di kawasan ini. Selain menyebutkan bahawa pembangun kernel utama kerap memperbaiki bug, tetapi tidak ada jaminan bahawa pembaikan ini akan diteruskan ke varian kernel pihak ketiga.
Dengan melakukannya, dia menyebutkan bahawa pengguna berbagai produk berbasis kernel Linux juga tidak memiliki cara untuk mengawal bug mana yang diperbaiki dan kernel mana yang digunakan pada perangkat mereka. Pada akhirnya, vendor bertanggungjawab untuk keselamatan produk mereka, tetapi berhadapan dengan kadar tambalan yang sangat tinggi di cawangan kernel yang stabil, mereka berhadapan dengan pilihan untuk memindahkan semua tambalan, memindahkan terpilih yang terpenting, atau mengabaikan semua tambalan. .
Pembangun kernel hulu dapat memperbaiki bug, tetapi mereka tidak dapat mengawal apa yang dipilih oleh vendor hilir untuk dimasukkan ke dalam produk mereka. Pengguna akhir dapat memilih produk mereka, tetapi mereka umumnya tidak dapat mengawal bug mana yang diperbaiki atau kernel mana yang digunakan (masalah itu sendiri). Pada akhirnya, vendor bertanggungjawab untuk menjaga keselamatan produk mereka.
Kees memasak menunjukkan bahawa penyelesaian yang optimum adalah dengan memindahkan hanya perbaikan dan kelemahan yang paling penting, tetapi masalah utama adalah memisahkan kesalahan ini dari aliran umum, kerana kebanyakan masalah yang timbul adalah akibat penggunaan bahasa C, yang memerlukan banyak perhatian ketika bekerja dengan memori dan petunjuk.
Untuk memperburuk keadaan, banyak kemungkinan perbaikan kerentanan tidak ditandai dengan pengenal CVE atau tidak menerima pengecam CVE beberapa saat setelah patch dilepaskan.
Dalam persekitaran seperti itu, sangat sukar bagi pengeluar untuk memisahkan pembaikan kecil dari masalah keselamatan utama. Menurut statistik, lebih dari 40% kerentanan dikeluarkan sebelum penugasan CVE, dan rata-rata kelewatan antara pembebasan memperbaiki dan penugasan CVE adalah tiga bulan (iaitu, pada awalnya, menganggap penyelesaian sebagai kesalahan biasa,
Akibatnya, tidak mempunyai cabang yang terpisah dengan perbaikan untuk kelemahan dan tidak menerima maklumat mengenai hubungan dengan keselamatan masalah ini atau itu, pengeluar produk berasaskan kernel Linux harus terus memindahkan semua pembaikan cawangan stabil baru. Tetapi kerja ini memerlukan tenaga kerja dan menghadapi tentangan di syarikat kerana ketakutan akan perubahan regresif yang boleh mengganggu operasi normal produk.
Kunci Masak percaya bahawa satu-satunya penyelesaian untuk memastikan kernel tetap selamat dengan kos yang berpatutan dalam jangka masa panjang adalah dengan menukar jurutera patch untuk membina kernel gilaSaya bekerjasama secara teratur untuk mengekalkan tambalan dan kerentanan pada kernel hulu. Seperti yang ada sekarang, banyak vendor tidak menggunakan versi kernel terbaru dalam produk mereka dan perbaikan backport sendiri, yang bermaksud bahawa jurutera dari syarikat yang berlainan ternyata meniru karya masing-masing, menyelesaikan masalah yang sama.
Sebagai contoh, jika 10 syarikat, masing-masing dengan jurutera yang menyokong pembaikan yang sama, mengarahkan jurutera ini untuk memperbaiki bug ke hulu, bukannya memindahkan satu pembetulan, mereka dapat memperbaiki 10 bug yang berbeza untuk faedah keseluruhan atau bersama-sama meninjau bug. Perubahan yang dicadangkan . Dan elakkan memasukkan kod kereta di kernel. Sumber daya juga dapat digunakan untuk membuat analisis kod baru dan alat pengujian yang secara otomatis akan mengesan pada tahap awal kelas kesalahan khas yang muncul berulang-ulang kali.
Kunci Masak juga mencadangkan untuk lebih aktif menggunakan ujian automatik dan kabur secara langsung dalam proses pengembangan kernel, menggunakan sistem integrasi berterusan dan meninggalkan pengurusan pembangunan kuno melalui e-mel.
Fuente: https://security.googleblog.com