Para Absolutis Keamanan Memori

• Menyingkirkan Rust hanya karena adanya unsafe dan menganggap hanya Fil-C yang aman mengabaikan cakupan penerapan perangkat lunak nyata dan kompromi teknis
• Fil-C mengubah akses memori yang salah di C/C++ menjadi panic, tetapi disertai biaya berupa ketidakcocokan ABI, penurunan kinerja hingga beberapa kali lipat dalam situasi tertentu, dan adopsi GC
• Pada sekitar 5 juta baris kode Rust di Android, ditemukan 1 potensi kerentanan keamanan memori yang diperbaiki sebelum rilis, diperkirakan setara 0,2 kasus per 1 juta baris, lebih dari 1.000 kali lebih rendah dibanding data historis C/C++ yang sekitar 1.000 kasus
• Tidak perlu memilih hanya salah satu antara teknologi yang mencegah 99,9% masalah di semua program dan teknologi yang mencegah 100% masalah di 90% program; untuk perangkat lunak yang sulit menerima batasan Fil-C, alternatif seperti Rust lebih cocok
• Keamanan memori perlu mempertimbangkan kinerja, ABI, GC, dan pencegahan data race secara bersama; jika Rust dikritik karena dianggap belum cukup, maka setidaknya standar yang sama harus diterapkan pada C/C++ biasa dan Zig non-Fil-C

---

Model tanggung jawab Rust dan bahasa sistem tradisional

• Pembahasan keamanan memori dalam bahasa pemrograman sistem non-GC selama ini terutama berfokus pada perbedaan model tanggung jawab Rust dan C/C++/Zig
  • Rust berupaya mencegah kompilasi program yang dapat menimbulkan masalah keamanan memori, dengan menerima biaya berupa penolakan terhadap sebagian program yang sebenarnya mungkin aman
  • unsafe adalah jalur keluar yang memungkinkan dereferensi pointer mentah dan lain-lain, sehingga sebagian jaminan bisa dilewati
  • Bahasa keluarga C menyerahkan sebagian besar jaminan keamanan memori kepada programmer
• Ada perbedaan tingkat dukungan antarbahasa, seperti RAII dan smart pointer di C++, atau defer di Zig, tetapi semuanya pada prinsipnya tidak memblokir akses memori yang salah itu sendiri

Opsi tambahan dari Fil-C

• Fil-C menawarkan pendekatan baru untuk menjalankan kode C dan C++ secara aman dari sisi memori
  • Jika terjadi akses memori yang salah seperti akses di luar batas atau use-after-free, sistem akan memicu panic
  • Fil-C menggabungkan GC dengan InvisiCaps yang melacak memori yang dapat diakses pointer
• Di Zig juga diusulkan mode kompilasi baru yang terinspirasi dari Fil-C
• Jika sebagian proyek C/C++ populer menyediakan rilis yang dikompilasi dengan Fil-C, pilihan untuk mengurangi kerentanan keamanan memori bisa bertambah

Standar yang menganggap Rust tidak aman

• Pengembang Fil-C di Twitter telah menilai Rust sebagai bahasa yang tidak aman dari sisi memori karena unsafe memungkinkan sebagian jaminan dilewati
• Pengembang Zig Andrew Kelley juga menyebut mode yang terinspirasi Fil-C itu dalam judul isu terkait sebagai mode kompilasi yang “benar-benar aman dari sisi memori, tidak seperti Rust”
• Sebagian diskusi menuntut bahwa jika pengguna Rust benar-benar mementingkan keamanan memori, mereka harus meninggalkan Rust dan mempromosikan Fil-C yang lebih aman
• Standar ini membandingkan Rust dan Fil-C sambil mengabaikan biaya praktis Fil-C, dan menunjukkan sikap yang mirip dengan kritik bahwa komunitas Rust kadang bersikap fanatik

Batasan penerapan Fil-C

• Fil-C bukan pengganti drop-in tanpa biaya
  • ABI-nya tidak kompatibel dengan program yang dikompilasi tanpa Fil-C
  • Dalam beberapa situasi bisa beberapa kali lebih lambat
  • Fil-C memperkenalkan GC
• Untuk program seperti utilitas sederhana, yang penurunan kinerjanya sulit dirasakan atau tidak membutuhkan dynamic linking, batasan ini mungkin tidak menentukan
• Sebaliknya, banyak proyek populer yang tidak bisa menerima GC dan ketidakcocokan ABI, dan program yang sulit menerapkan Fil-C dalam bentuknya saat ini sering kali cocok dengan Rust

Data kerentanan pada kode Rust nyata

• Data untuk menilai keamanan Rust secara praktis memang belum banyak, tetapi belum banyak ditemukan kerentanan keamanan memori yang dapat dieksploitasi dalam perangkat lunak Rust
• Pada lebih dari 5 juta baris kode Rust di Android, ditemukan 1 potensi kerentanan keamanan memori dan diperbaiki sebelum rilis
  • Kepadatan kerentanan yang diperkirakan adalah 0,2 kasus per 1 juta baris
  • Data historis C/C++ di Android adalah sekitar 1.000 kasus per 1 juta baris
  • Kepadatan pada kode Rust terlacak lebih dari 1.000 kali lebih rendah dibanding C/C++
• Angkanya bisa berbeda antarproyek, tetapi ini menjadi dasar bahwa di lingkungan nyata Rust sangat menurunkan risiko masuknya masalah keamanan memori

Mengapa tidak perlu memilih hanya satu

• Pilihan hipotetis antara teknologi yang mencegah 99,9% masalah di semua program dan teknologi yang mencegah 100% masalah di 90% program menunjukkan bahwa cakupan penerapan dan tingkat pencegahan sama-sama penting
• Rasio nyatanya mungkin tidak diketahui, tetapi tidak perlu memilih hanya salah satu dari dua pendekatan ini
  • Proyek C/C++/Zig yang dapat menerima komprominya bisa menyediakan biner Fil-C
  • Perangkat lunak yang tidak bisa memakai Fil-C dapat ditulis dalam bahasa yang sepenuhnya atau hampir sepenuhnya menghilangkan risiko kerentanan keamanan memori

Mengapa tetap memilih Rust meski GC bisa dipakai

• Tetap memilih Rust adalah hal yang masuk akal meski ada opsi berbasis GC seperti Go atau Fil-C
• Program yang bisa ditulis dalam bahasa berbasis GC sering kali tidak memerlukan unsafe, sedangkan program yang memerlukan unsafe sering kali tidak bisa menggunakan GC
• Bisa saja seseorang menilai jaminan dan fitur bahasa lain seperti pencegahan data race lebih penting daripada risiko keamanan memori yang kecil
• Fil-C mengubah kerentanan keamanan memori di C/C++ yang sudah ada menjadi crash
  • Ini lebih baik daripada kerentanan keamanan, tetapi jika kepadatan historis sekitar 1.000 kasus per 1 juta baris tetap sama, masih akan ada banyak crash yang harus diperbaiki
  • Di masa lalu, juga ada kerentanan keamanan yang memanfaatkan kemampuan penyerang untuk membuat program crash

Standar keamanan memori yang konsisten

• Jika bahkan 0,2 kasus per 1 juta baris pada Rust pun tidak bisa diterima, maka kritik yang sama atau lebih ketat harus diterapkan pada C/C++ biasa dan Zig non-Fil-C
• Sikap yang membiarkan alternatif yang kurang aman daripada Rust tetapi tetap menyingkirkan Rust hanya karena unsafe menunjukkan absolutisme keamanan memori yang tidak diterapkan secara konsisten

[GN⁺]

Pendapat di Lobste.rs

• Pernyataan Andrew Kelly yang tampaknya dianggap tidak menyenangkan oleh OP adalah bahwa Zig dapat mengompilasi seluruh dependensi C/C++ menjadi executable yang sepenuhnya aman memori tanpa jalan keluar, dengan biaya performa sekitar 1–6x tergantung frekuensi pelacakan pointer
  Penulis menganggap ini sebagai serangan terhadap Rust dan di akhir tulisan menyerang Zig, tetapi Fil-C dan mode build baru Zig adalah kontribusi positif bagi ekosistem serta menawarkan titik desain dan kompromi yang berbeda dari Rust
  Saya menafsirkannya bahwa jika mengikuti pemrograman berorientasi data yang disukai tim Zig, biaya performa bisa ditekan mendekati 1x

  • Penulis menanggapi judul “memperkenalkan mode kompilasi yang terinspirasi Fil-C, yang tidak seperti Rust benar-benar aman memori” dan unggahan Twitter dari pengembang Fil-C
    Tidak berlebihan juga jika itu dibaca sebagai provokasi yang tidak perlu, dan Andrew kemudian mengubah judulnya menjadi lebih tidak memancing

• Berbeda dari biasanya, ketika ejekan ringan “bahasa kalian tidak aman memori” diarahkan balik, skala reaksi para pengembang Rust cukup besar
  Saya juga sangat menyukai Rust, tetapi perlu menerimanya secara adil

  • Pernyataan “Rust cukup aman memori, tetapi Fil-C lebih aman dalam aspek itu” tidak terlalu kontroversial dan tampak benar
    Lebih jauh lagi, C yang diverifikasi secara formal dari seL4 bahkan lebih aman
  • Karena saya mementingkan program yang benar dan sebisa mungkin tidak ingin menulis kode yang tidak demikian, secara paradoks saya lebih memilih Rust daripada Zig
    Zig punya keunggulan mudah keluar dengan benar saat alokasi memori gagal dan kompilasinya juga cepat
    Saya tidak tahu apakah Fil-C lebih aman memori daripada Rust, tetapi untuk penggunaan saya, garbage collector dan ketidakcocokan dengan C ABI adalah hambatan yang menentukan
    Jika dibuat single-thread, kita bisa menghindari race condition, dan jika memasukkan garbage collector, kita bisa memperoleh keamanan memori; tetapi saya suka Rust karena menyediakan keduanya tanpa dua kompromi itu

• Karena sangat mementingkan keamanan memori, Fil-C dan implementasi Fil-C ABI di Zig adalah pilihan yang wajar
  Proyek Rust yang memiliki dependensi C melemahkan jaminan keamanannya, dan memakai Rust murni saja memang mungkin tetapi merepotkan
  Rust juga seharusnya mengimplementasikan Fil-C ABI agar dapat membangun dependensi C secara aman dan menautkannya dengan Rust, dan saya tidak paham mengapa ini kontroversial

  • Rust sudah memiliki interpreter Miri yang memeriksa apakah kode Rust yang unsafe tetap menjaga jaminan Rust yang safe
    Jika mengimplementasikan fitur serupa, saya berharap itu dipakai hanya pada build debug sebagai alat bantu untuk memperbaiki kode FFI
    Pendekatan dengan garbage collector dan pemeriksaan semua operasi saat runtime tidak cocok untuk semua penggunaan

• Sebelum menganggap Fil-C sekadar untuk utilitas sederhana, perlu menonton presentasi Fil-C di konferensi Software Should Work
  Pembicara melakukan presentasi menggunakan laptop Linux yang seluruh user space-nya, bahkan OpenOffice Impress, disusun dengan Fil-C
  Memang mungkin tidak cocok untuk sebagian program C/C++, tetapi tampaknya bukan teknologi mainan seperti yang dianggap penulis

• Karena berasal dari Python, keamanan memori adalah prasyarat dasar, dan ada tiga alasan saya memilih Rust
  Pertama, dengan sistem tipe yang kuat kita bisa memperoleh ketepatan pada waktu kompilasi, dan keamanan memori yang didapat melalui #![forbid(unsafe_code)] serta audit dependensi memakai cargo-geiger adalah ekspresi yang paling kurang menarik dari hal itu
  Kedua, Rust menyediakan ekosistem yang memudahkan menulis kode dengan aman sekali lalu membagikannya ke berbagai bahasa dan lingkungan eksekusi
  Ketiga, ada syntactic sugar yang memudahkan penulisan kode tingkat tinggi, seperti try!(x) pada masa itu
  Zig dan Fil-C tampaknya tidak memenuhi kemampuan membuat compiler menangkap kesalahan logika dengan mengenkode invariant ke dalam sistem tipe melalui pola typestate, newtype, dan sebagainya
  Ketidakcocokan ABI Fil-C juga menjadi masalah saat menulis modul kompilasi yang aman untuk runtime yang sudah ada, seperti CPython pada shared web hosting

  • Di Zig pun pola typestate dan enkoding tipe untuk berbagai constraint dimungkinkan, dan dalam beberapa hal comptime lebih ekspresif daripada Rust
    Ada kompromi berupa waktu kompilasi, verbositas, dan fakta bahwa sebagian besar ekosistem tidak mencoba sampai tingkat ini, tetapi ini benar-benar mungkin dan cukup menarik

• Saya penasaran mengapa teknologi seperti Fil-C tidak muncul 20 tahun lalu

  • Di ranah mainframe, masalah keamanan dari berbagi dan memberi tag pada pointer serta kapabilitas berbasis kewenangan sudah diperingatkan selama puluhan tahun
    Namun tidak ada yang mau membayar biayanya dalam bentuk CPU atau memori, yakni biaya sebenarnya
  • Beberapa bulan lalu saya mengajukan pertanyaan serupa kepada Filip dan mendapat jawaban seperti ini
    Pada 2004–2018, idenya sudah ada tetapi gagasan C yang aman memori dianggap bodoh; pada 2018–2023, ia berubah pikiran tetapi belum menemukan cara mencapai kompatibilitas ekstrem
    Fil-C awal pada 2023–2024 memiliki kompatibilitas dan performa yang jauh lebih rendah, dan pada akhir 2024 terobosan InvisiCaps menghasilkan kompatibilitas tinggi dan performa yang layak seperti sekarang
    Pemicu perubahan pikirannya sekitar 2018 adalah pengamatan bahwa varian C yang dipakai di GPU merupakan bentuk sederhana dari C yang aman memori
  • Dua puluh tahun lalu komputer lebih lambat dan jauh lebih sensitif terhadap biaya keamanan

• Jika menafsirkan dengan paling baik pernyataan “kalau kubu Rust benar-benar mementingkan keamanan memori, mereka harus mendukung Fil-C yang lebih aman dan meninggalkan Rust”, maksudnya adalah: karena sekarang ada Fil-C, mari hentikan upaya menulis ulang dunia dengan Rust, kembali ke C/C++, dan pertahankan ekosistem library terpadu seperti dulu
  Walaupun library Rust bisa dipakai dari C/C++, ada pengembang yang tidak menginginkan hal itu, jadi logikanya jika pengguna Rust mengakui solusi yang lebih baik dan menyerah, perpecahan akan hilang
  Namun Fil-C memiliki kompromi yang tidak dimiliki Rust, yaitu garbage collector dan dukungan hanya untuk x86-64 Linux
  Selain keamanan memori, Cargo dan tidak adanya namespace global adalah alasan penting untuk memakai Rust, dan menyedihkan bahwa perpecahan antar kubu bahasa terkait dengan perang budaya yang lebih luas
  Saya hanya ingin membuat library yang akan dengan senang hati dipakai siapa pun

  • Saya bertanya-tanya apakah C dan C++ saja pun sudah merupakan ekosistem yang terfragmentasi
    Di antara pengembang C mungkin ada yang tidak menginginkan library C++, dan kini Zig serta Odin juga muncul, jadi meski Rust hilang, fragmentasi tetap ada
    Saya penasaran apakah Rust menciptakan jenis fragmentasi yang secara khusus berbeda
  • Saya juga menginginkan dunia tempat semua orang memakai library dengan puas, dan sedang mengembangkan transpiler tingkat tinggi Rust→Zig yang mempertahankan generic sebagai comptime
    Karena Rust mengenkode lebih banyak constraint, ia ideal sebagai bahasa sumber