Rilis dan update kernel stabil

Model rilis stabil kernel Linux dimulai pada tahun 2005, saat ditentukan bahwa model pengembangan kernel yang ada (rilis baru setiap 2-3 bulan) tidak memenuhi kebutuhan sebagian besar pengguna. Pengguna menginginkan perbaikan bug yang dilakukan selama 2-3 bulan tersebut, dan distribusi Linux merasa kesulitan untuk terus mengupdate kernel tanpa masukan dari komunitas kernel. Secara umum, upaya untuk menjaga setiap kernel tetap aman dan dengan perbaikan bug terbaru adalah upaya besar dan membingungkan oleh banyak individu yang berbeda.

Rilis kernel stabil didasarkan langsung pada rilis Linus Torvalds, dan dirilis setiap minggu atau lebih, bergantung pada berbagai faktor eksternal (musim, patch yang tersedia, beban kerja pengelola, dll.). Penomoran rilis stabil dimulai dengan nomor rilis kernel, dan nomor tambahan ditambahkan ke bagian akhirnya. Misalnya, kernel 4.4 dirilis oleh Linus, lalu rilis kernel stabil berdasarkan kernel ini diberi nomor 4.4.1, 4.4.2, 4.4.3, dan seterusnya. Urutan ini biasanya disingkat dengan angka 4.4.y saat mengacu pada hierarki rilis kernel yang stabil. Setiap hierarki rilis kernel stabil dikelola oleh satu developer kernel, yang bertanggung jawab untuk memilih patch yang diperlukan untuk rilis dan mengelola proses peninjauan/rilis.

Kernel stabil dipertahankan selama siklus pengembangan saat ini. Setelah Linus merilis kernel baru, hierarki rilis kernel stabil sebelumnya akan dihentikan dan pengguna harus beralih ke kernel yang dirilis lebih baru.

Kernel stabil jangka panjang

Setelah satu tahun proses rilis stabil baru ini, diketahui bahwa banyak pengguna Linux yang berbeda menginginkan kernel yang didukung lebih lama dari beberapa bulan. Sebagai respons, rilis kernel Dukungan Jangka Panjang (LTS) dibuat, dengan kernel LTS pertama (2.6.16) dirilis pada tahun 2006. Sejak itu, kernel LTS baru telah dipilih setahun sekali dan komunitas kernel mempertahankan kernel tersebut selama minimal 2 tahun.

Pada saat penulisan ini, kernel LTS adalah rilis 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y, dan 5.10.y. Kernel baru dirilis setiap minggu. Karena kebutuhan beberapa pengguna dan distribusi, beberapa kernel lama tambahan dikelola oleh developer kernel dengan siklus rilis yang lebih lambat. Informasi tentang semua kernel stabil jangka panjang, siapa yang bertanggung jawab atas kernel tersebut, dan berapa lama kernel tersebut dipertahankan, dapat ditemukan di halaman rilis kernel.org.

Rilis kernel LTS rata-rata menerima 6-8 patch per hari, sedangkan rilis kernel stabil normal berisi 10-15 patch per hari. Jumlah patch berfluktuasi per rilis berdasarkan waktu saat ini dari rilis kernel pengembangan yang sesuai, dan variabel eksternal lainnya. Makin lama kernel LTS, makin sedikit patch yang berlaku karena banyak perbaikan bug terbaru yang tidak relevan dengan kernel lama. Namun, semakin lama kernel, semakin sulit untuk melakukan backport perubahan yang perlu diterapkan, karena perubahan dalam codebase. Jadi, meskipun mungkin ada lebih sedikit patch yang diterapkan secara keseluruhan, upaya yang diperlukan untuk mempertahankan kernel LTS lebih besar daripada mempertahankan kernel stabil normal.

Aturan patch kernel stabil

Aturan untuk hal yang dapat ditambahkan ke rilis kernel stabil tetap hampir identik sejak diperkenalkan dan diringkas di bawah:

  • Harus jelas benar dan telah diuji.
  • Tidak boleh lebih besar dari 100 baris.
  • Hanya boleh memperbaiki satu hal.
  • Harus memperbaiki sesuatu yang telah dilaporkan sebagai masalah.
  • Dapat berupa ID perangkat baru atau keanehan untuk hardware, tetapi tidak menambahkan fungsi utama baru.
  • Harus sudah digabungkan ke dalam hierarki Linus Torvalds.

Aturan terakhir, "Harus sudah digabungkan ke dalam hierarki Linus Torvalds", mencegah komunitas kernel kehilangan perbaikan. Komunitas tidak pernah ingin perbaikan dimasukkan ke dalam rilis kernel stabil yang belum ada di hierarki Linus Torvalds, sehingga setiap orang yang mengupgrade tidak akan pernah melihat regresi. Hal ini mencegah banyak masalah yang dapat terjadi pada project lain yang mempertahankan cabang pengembangan dan stabil.

Update kernel

Komunitas kernel Linux telah berjanji kepada basis penggunanya bahwa tidak ada upgrade yang akan merusak apa pun yang berfungsi dalam rilis sebelumnya. Janji tersebut masih berlaku hingga saat ini. Regresi memang terjadi, tetapi itu adalah bug dengan prioritas tertinggi dan diperbaiki dengan cepat, atau perubahan yang menyebabkan regresi dengan cepat dikembalikan dari hierarki kernel Linux.

Janji ini berlaku untuk update kernel stabil inkremental, serta update besar yang lebih besar yang terjadi setiap tiga bulan. Namun, komunitas kernel hanya dapat membuat janji ini untuk kode yang digabungkan ke dalam hierarki kernel Linux. Setiap kode yang digabungkan ke kernel perangkat yang tidak ada dalam rilis kernel.org tidak diketahui dan interaksi dengannya tidak pernah dapat direncanakan, atau bahkan dipertimbangkan.

Perangkat berbasis Linux yang memiliki set patch besar dapat mengalami masalah besar saat diupdate ke kernel yang lebih baru, karena banyaknya perubahan di antara setiap rilis (10-14 ribu perubahan per rilis). Patchset SoC terutama dikenal memiliki masalah terkait update ke kernel yang lebih baru karena ukurannya yang besar dan modifikasi berat pada kode kernel khusus arsitektur, dan terkadang inti. Akibatnya, sebagian besar vendor SoC mulai menstandarkan penggunaan rilis LTS untuk perangkat mereka, sehingga perangkat tersebut dapat menerima update bug dan keamanan langsung dari komunitas kernel Linux.

Keamanan

Saat melakukan rilis kernel, komunitas kernel Linux hampir tidak pernah mendeklarasikan perubahan tertentu sebagai perbaikan keamanan. Hal ini disebabkan oleh masalah dasar kesulitan dalam menentukan apakah perbaikan bug adalah perbaikan keamanan atau tidak pada saat pembuatan. Selain itu, banyak perbaikan bug yang hanya ditentukan terkait keamanan setelah banyak waktu berlalu, sehingga komunitas kernel sangat merekomendasikan untuk selalu mengambil semua perbaikan bug yang dirilis.

Saat masalah keamanan dilaporkan ke komunitas kernel, masalah tersebut akan diperbaiki segera mungkin dan diluncurkan secara publik ke hierarki pengembangan dan rilis stabil. Seperti yang dijelaskan di atas, perubahan ini hampir tidak pernah dijelaskan sebagai "perbaikan keamanan", tetapi terlihat seperti perbaikan bug lainnya untuk kernel. Hal ini dilakukan untuk memungkinkan pihak yang terpengaruh mengupdate sistem mereka sebelum pelapor masalah mengumumkannya.

Untuk mengetahui detail tentang cara melaporkan bug keamanan kepada komunitas kernel agar bug tersebut dapat diselesaikan dan diperbaiki sesegera mungkin, lihat Bug keamanan di Panduan pengguna dan administrator kernel Linux di www.kernel.org.

Karena bug keamanan tidak diumumkan kepada publik oleh tim kernel, nomor CVE untuk masalah terkait kernel Linux biasanya dirilis dalam waktu berminggu-minggu, berbulan-bulan, dan terkadang bertahun-tahun setelah perbaikan digabungkan ke dalam cabang stabil dan pengembangan.

Menjaga sistem tetap aman

Saat men-deploy perangkat yang menggunakan Linux, sebaiknya semua update kernel LTS diambil oleh produsen dan dikirimkan kepada penggunanya setelah pengujian yang tepat menunjukkan bahwa update berfungsi dengan baik. Kode ini memiliki beberapa keunggulan:

  • Rilis telah ditinjau oleh developer kernel secara keseluruhan, bukan secara terpisah.
  • Sulit untuk menentukan patch mana yang memperbaiki masalah "keamanan" dan mana yang tidak. Hampir setiap rilis LTS berisi setidaknya satu perbaikan keamanan yang diketahui, dan banyak lagi yang "tidak diketahui".
  • Jika pengujian menunjukkan masalah, komunitas developer kernel akan bereaksi dengan cepat untuk menyelesaikan masalah tersebut.
  • Mencoba memfilter hanya perubahan yang Anda jalankan akan menghasilkan hierarki kernel yang tidak dapat digabungkan dengan benar dengan rilis upstream mendatang.