Kerusakan memori Bluetooth yang ditemukan GrapheneOS dengan ARM MTE
(grapheneos.social)- Dukungan penandaan memori perangkat keras pada Pixel 8·Pixel 8 Pro mengungkap bug kerusakan memori baru di Bluetooth LE yang masuk pada Android 14 QPR2
- Penyebabnya dipastikan sebagai bug upstream use-after-free pada Bluetooth LE, dan GrapheneOS telah membuat patch perbaikan yang akan disertakan dalam rilis baru
- Pengguna yang mereproduksi masalah pada mode Bluetooth LE milik Samsung Galaxy Buds2 Pro telah mengonfirmasi bahwa perbaikannya bekerja, dan stock Pixel OS juga terdampak
- GrapheneOS menilai bahwa karena Bluetooth merupakan permukaan serangan yang besar, solusi sementara dengan mematikan penandaan memori untuk proses tersebut tidak tepat bahkan untuk jangka pendek
- Sebagian kode Bluetooth Android telah dipindahkan ke Rust, tetapi masih dibutuhkan lebih banyak porting kode yang tersisa serta pengujian build HWASan·MTE pada perangkat nyata
Bug Bluetooth LE di Android 14 QPR2 dan perbaikannya
- GrapheneOS menemukan bug kerusakan memori Bluetooth LE di Android 14 QPR2 berkat dukungan penandaan memori perangkat keras pada Pixel 8 dan Pixel 8 Pro
- Masalah ini tidak terjadi pada semua perangkat Bluetooth, dan hanya dapat direproduksi pada perangkat Bluetooth LE tertentu
- GrapheneOS sedang menyelidiki cara memperbaiki fitur yang baru diperkenalkan ini atau menonaktifkannya sementara
- Penyebabnya dipastikan sebagai bug upstream use-after-free pada Bluetooth LE, dan GrapheneOS telah mengembangkan patch
- Prioritasnya adalah segera mendistribusikan rilis GrapheneOS yang memuat perbaikan tersebut
- Akan dilaporkan sebagai bug keamanan Android
- Perbaikan ini juga tampaknya akan menyelesaikan regresi audio BLE
- Pengguna yang mereproduksi masalah dengan memakai Samsung Galaxy Buds2 Pro dalam mode Bluetooth LE telah mengonfirmasi bahwa perbaikannya bekerja
- Masalah yang sama juga memengaruhi stock Pixel OS
- GrapheneOS mendeteksinya melalui dukungan penandaan memori di hardened_malloc dan menambahkan notifikasi crash MTE yang memuat laporan yang bisa disalin
Cara penerapan MTE dan tantangan pada kode Bluetooth Android
- GrapheneOS menilai solusi sementara dengan mematikan penandaan memori pada proses ini tidak tepat bahkan untuk jangka pendek
- Bluetooth merupakan permukaan serangan yang besar, terlepas dari kemungkinan eksploitasi nyata dari bug tersebut
- Android telah memindahkan sebagian besar kode Bluetooth ke Rust, tetapi porting kode yang tersisa masih membutuhkan lebih banyak sumber daya
- Di lingkungan nyata, masih dibutuhkan lebih banyak pengujian build HWASan dan MTE terhadap beragam perangkat Bluetooth
- Perangkat Pixel dibekali MTE sebagai fitur keamanan perangkat keras yang besar, tetapi OS bawaan tidak mengaktifkannya dengan alasan penghematan penggunaan memori·cache sebesar 3.125%
- Perhitungannya didasarkan pada tag 4-bit untuk setiap 16 byte memori yang ditandai
- heap MTE dalam mode async memiliki overhead performa yang nyaris 0%, dan dalam mode asymmetric biayanya lebih rendah daripada mitigasi lama seperti SSP
- GrapheneOS mengaktifkan MTE secara default untuk aplikasi buatan pengguna yang dipasang pengguna dan diketahui kompatibel dengan OS bawaan
- Dapat diaktifkan secara opt-in untuk semua aplikasi yang dipasang pengguna melalui Settings > Security
- Menyediakan notifikasi untuk menyalin laporan crash dan toggle per aplikasi
- Implementasi MTE hardened_malloc milik GrapheneOS menggunakan tag acak standar dan tag free khusus, serta secara dinamis mengecualikan tag sebelumnya dan tag tetangga yang sedang dipakai atau sebelumnya
- Integrasi Chromium telah diperbaiki, dan PartitionAlloc juga akan ditingkatkan
1 komentar
Komentar Hacker News
Aneh rasanya Pixel sudah menyertakan fitur keamanan perangkat keras besar bernama MTE, tetapi OS tidak mengaktifkannya hanya demi menghemat penggunaan memori/cache 3,125%
Saya benar-benar ingin melihat bagaimana tim Pixel membenarkan keputusan ini, dan penasaran dengan alur pikir yang mematikan fitur keamanan sepenting ini demi sedikit peningkatan performa
Namun GrapheneOS memang proyek yang keren, tetapi perangkat yang didukungnya hanya sekitar 11 model, sedangkan perubahan AOSP harus mempertimbangkan ekosistem OEM yang jauh lebih besar
Kami selalu mencari cara membuat Android lebih baik, tetapi mengkritik peluncuran fitur tertentu sambil mengabaikan ekosistem OEM yang lebih besar terlihat berpandangan sempit
Sangat kecil kemungkinan alasan fitur ini tidak diaktifkan adalah memori/cache 3%; sepertinya ada pertimbangan lain
Saat memutuskan apakah fitur ini akan diaktifkan atau tidak, kemungkinan besar faktor ini justru lebih besar
Karena OS lain saat ini juga tidak dirilis dengan MTE aktif, kemungkinan keputusan untuk mengaktifkannya atau tidak jauh lebih bernuansa
Orang-orang di Google-lah yang sejak awal mendorong MTE perangkat keras, dan itu dimulai dari tim yang terlibat dalam ASAN, syzkaller, dan sebagainya
Mereka bukan bagian dari tim Android, tetapi ada bantuan dan dukungan dari sisi Android, dan tentu saja ada kerja sama dengan ARM dan pihak lain
Karena saat itu saya memimpin tim-tim tersebut, saya cukup memahami komprominya; masalahnya bukan hanya memori atau cache
MTE memang dapat dinyalakan dan dimatikan secara dinamis dan dirancang agar biaya performanya hampir mendekati 0, tetapi penggunaan utamanya saat itu adalah pencarian bug berbasis sampling
Jika diaktifkan hanya 1% dari waktu di seluruh populasi perangkat, skalanya sudah cukup besar untuk menemukan bug dengan sangat cepat, dan juga bisa dipakai untuk pengujian internal
Dengan kata lain, tujuannya adalah memungkinkan fitur setara ASAN dinyalakan dan dimatikan saat dibutuhkan
Menggunakannya sebagai mitigasi keamanan yang selalu aktif adalah kemungkinan sekunder, dan ada masalah lain selain overhead memori
Misalnya, tiba-tiba akan muncul banyak crash yang terlihat oleh pengguna, dan konsistensinya juga tidak ada karena sebuah ponsel dengan MTE bisa crash sementara ponsel tanpa MTE tidak
Dari sudut pandang developer pun ini mungkin tidak menyenangkan, karena dalam situasi ketika hampir hanya ada satu ponsel dengan MTE aktif, semua orang harus dipaksa menguji di ponsel itu
Ini memang bisa mencegah eksploit keamanan, dan membuatnya menjadi crash alih-alih berhasil dieksploitasi
Bug yang tidak berbahaya pun bisa tertangkap
Tetapi seperti disebutkan sebelumnya, saya tidak akan berasumsi bahwa fitur ini tidak digunakan; tampaknya lebih tepat menganggapnya tidak selalu aktif di produksi
Orang yang pernah berpengalaman memperkenalkan fitur perangkat keras seperti ini justru akan mengatakan bahwa fakta sistem bisa boot dan berjalan, lalu hanya crash di bawah MTE pada perilaku tertentu, adalah sinyal bagus bahwa fitur itu sudah digunakan
Kalau tidak digunakan, mungkin sudah crash sejuta kali
Tambahan lagi, belum jelas apakah ini mitigasi runtime terbaik
Pixel bawaan mungkin tidak menyediakannya dalam keadaan aktif secara default untuk pengguna akhir, tetapi siapa pun yang mau bisa mengaktifkan Memory Tagging Extensions dari opsi developer
Ini bisa dipertahankan sampai dimatikan, atau diaktifkan hanya untuk satu sesi guna menguji aplikasi tertentu
Mengaktifkan dukungan memory tagging dari opsi developer di Pixel OS bawaan hanya membuatnya tersedia, bukan benar-benar menggunakannya
Dari shell Android Debug Bridge (ADB), heap memory tagging juga harus diaktifkan dengan
setpropJika alokasi tidak diberi tag, sekadar mengaktifkannya tidak ada nilainya
MTE heap ruang pengguna pada OS bawaan memang dapat diaktifkan sepenuhnya melalui Scudo, implementasi allocator default, tetapi saat ini itu bukan implementasi yang secara khusus diperkuat
KASan yang memakai backend MTE juga dapat digunakan dengan
setprop, tetapi saat ini tidak dirancang untuk hardening, dan belum jelas apakah nantinya akan begituKernel kemungkinan besar membutuhkan implementasi MTE terpisah yang bukan bagian dari KASan, dan GrapheneOS juga belum melakukannya, sehingga hardening MTE saat ini adalah fitur ruang pengguna
GrapheneOS memakai implementasi hardware memory tagging sendiri untuk hardened_malloc, dengan properti keamanan yang lebih kuat
Untuk mengaktifkannya secara default di OS bawaan, banyak masalah termasuk isu ini harus diperbaiki atau diakali
Alih-alih memakai MTE asinkron di core utama, mereka menggunakan mode asimetris di semua core
Mode asimetris bersifat asinkron untuk penulisan dan sinkron untuk pembacaan, sehingga benar-benar memblokir tanpa menyisakan celah peluang keberhasilan eksploit
Ini diperiksa pada system call, dan io_uring, yang bisa menjadi jalur bypass lain, dibatasi oleh SELinux di Android sehingga hanya diizinkan untuk 2 proses sistem inti
fastbootd hanya dipakai selama instalasi, dan snapuserd dipakai oleh OS inti setelah penerapan update
GrapheneOS selalu menggunakan heap MTE untuk aplikasi yang telah dipastikan kompatibel dengan OS bawaan
Untuk aplikasi yang dipasang pengguna yang tidak ada di basis data kompatibilitas dan tidak menandai dirinya kompatibel, tersedia toggle MTE per aplikasi
Pengguna juga bisa mengaktifkan agar MTE dipaksakan secara default pada aplikasi yang dipasang pengguna, dan hanya mengecualikan aplikasi yang tidak kompatibel
Agar ini benar-benar bisa digunakan, diperlukan sistem pelaporan crash yang terlihat oleh pengguna, dan mereka mengimplementasikannya agar laporan crash yang berguna bagi developer dapat dengan mudah disalin dan dikirim
Saat mencari Memory Tagging Extensions di Settings, hasilnya muncul, jadi saya kira mungkin disembunyikan di suatu tempat, ternyata itu khusus ponsel Pixel 8: https://news.ycombinator.com/item?id=38125379
GrapheneOS sangat jauh di depan yang lain dari sisi keamanan sampai-sampai memilih selain hardware Pixel jadi terasa meragukan
Namun saya benar-benar menginginkan baterai yang bisa diganti
Entah kenapa sekarang semuanya terasa begitu buruk
Perangkat Android lain bahkan tidak mendekati
Dukungan memory tagging berbasis hardware adalah salah satu dari beberapa keunggulan keamanan besar Pixel
Daftar persyaratan hardware resmi ada di sini: https://grapheneos.org/faq#future-devices
Persyaratan ini sepenuhnya dipenuhi oleh Pixel generasi ke-8
Pixel generasi 6/7 hanya tidak memiliki MTE, BTI, dan PAC, tetapi MTE adalah fitur paling bernilai dalam daftar persyaratan hardware
Patch keamanan yang benar lebih penting, dan di luar Pixel hal itu tidak disediakan dengan cara yang sama
Android memiliki rilis bulanan, kuartalan, dan tahunan
OEM Android lain hanya menyediakan semua perbaikan tingkat keparahan Critical/High dari backport keamanan bulanan, dan sebagian besar tidak menyediakan perbaikan tingkat keparahan Moderate/Low, termasuk kebanyakan perbaikan privasi
Menggunakan OS alternatif untuk menyediakan patch semacam ini dapat sedikit mengurangi masalah, tetapi OS alternatif untuk perangkat tersebut sering kali membalikkan keamanan dalam berbagai cara
Firmware dan banyak kode dukungan perangkat sebenarnya berasal dari OEM
Menjalankan Android 14 QPR2 di atas kernel/driver Android 12 memang mungkin, tetapi peningkatan keamanan untuk bagian besar OS akan hilang
Baterai Pixel memang tidak mudah diganti tanpa merusak perangkat, tetapi didukung secara resmi dan suku cadang resmi juga tersedia: https://www.ifixit.com/Device/Google_Pixel
Kami tidak bisa mendukung perangkat tidak aman yang bahkan tidak memenuhi hal-hal dasar
Daftar persyaratan hardware kami mencakup hal-hal sangat dasar yang tidak disediakan oleh sebagian besar OEM Android, sekaligus fitur lanjutan seperti MTE yang kini kami anggap sebagai persyaratan dasar untuk keamanan yang layak
Kami ingin mendukung perangkat lain juga, tetapi perangkat-perangkat itu harus memenuhi persyaratan ini
Memory tagging adalah fitur dasar yang didukung oleh core Cortex ARMv9 standar
Sangat disayangkan Qualcomm tidak mengimplementasikannya, dan OEM yang memakai SoC yang mendukungnya pun tidak mengaktifkan konfigurasinya
Menyedihkan ketika suatu fitur ada di arsitektur CPU, tetapi tidak bisa digunakan karena SoC atau OEM
Meski begitu, untungnya Pixel 8 direncanakan mendapat dukungan 7 tahun
Apple maupun Samsung sulit dipercaya, dan Google kini menjadi pilihan yang paling baik
Akan bagus kalau ada pengguna GrapheneOS yang bisa menjawab
Namun baru-baru ini saat saya pergi ke Disney World dan Universal Studios di Orlando, Florida bersama istri, meski aplikasi umumnya berjalan dengan Google Play Services yang di-sandbox, ada beberapa masalah menjengkelkan
Aplikasi My Disney Experience cukup sering mengalami error terkait lokasi, dan sesekali muncul pesan bahwa untuk melakukan tugas penting saya harus berada di AS atau Kanada, jadi saya harus memakai ponsel istri sebagai solusi sementara
Di aplikasi Universal, saya tidak bisa login ke akun, sementara di Samsung Galaxy bawaan milik istri berjalan baik, jadi tampaknya ini masalah GrapheneOS
Selain itu, jika Anda membayar kartu kredit dengan Google Wallet, itu tidak didukung karena Google tidak mensertifikasi GrapheneOS
Fitur Wallet lainnya berjalan
Uber berjalan tanpa masalah
Selain itu saya tidak memakai aplikasi proprietary
Jika Anda terutama berniat memakai aplikasi bebas/open source, seharusnya tidak ada masalah
Sebagian besar aplikasi proprietary berjalan dengan Google Play Services yang di-sandbox, tetapi jika ada aplikasi yang sangat penting untuk pekerjaan, Anda bisa menemui masalah menjengkelkan seperti yang saya alami di Universal Studio dan My Disney Experience
Saya memakai kabel USB biasa dan adb dari command line Linux, tetapi metode yang direkomendasikan adalah memakai WebUSB di Chromium dan semestinya lebih mudah bagi orang nonteknis
Namun dalam kasus saya, itu tidak berjalan dengan baik
Karena ada Google Play Services yang di-sandbox, Anda bisa memasang berbagai aplikasi proprietary yang membuat kehidupan modern tertanggungkan, sambil tetap mencegah Google Play mendapat akses tak terbatas ke seluruh ponsel; ini mengambil sisi baik dari keduanya
Jika ingin isolasi lebih jauh, Anda bisa membuat pengguna terpisah dan menjalankan komponen terkait Google Play di akun itu
Saya sempat mencobanya, tetapi secara pribadi merasa repot harus berpindah pengguna setiap kali
Ponsel saya tidak pernah crash, dan aplikasi perbankan juga berjalan
Perangkatnya Pixel 6a
Anda juga bisa membeli perangkat yang sudah terpasang, tetapi hampir siapa pun bisa memakai installer web
Di Android, ChromeOS, dan macOS khususnya mudah; Windows sedikit lebih rumit karena perlu memasang driver
Linux desktop perlu memasang aturan udev, dan beberapa distribusi dengan versi software yang dibekukan memiliki service bermasalah yang mengganggu
Orang nonteknis pun bisa melakukannya, cukup punya browser yang mendukung WebUSB
Tidak perlu software khusus
Untuk pemakaian sehari-hari, jika memakai Google Play yang di-sandbox, rasanya hampir sama dengan Pixel OS bawaan dan kompatibilitas aplikasinya juga hampir serupa
Kemungkinan besar Anda tidak akan mengalami crash yang secara berarti lebih sering
Ada pelaporan crash untuk pengguna yang tidak ada di OS bawaan, jadi Anda mungkin menyadari crash yang sebelumnya tidak akan Anda ketahui
Aplikasi buggy yang memiliki kerusakan memori bisa crash sampai Anda mengaktifkan mode kompatibilitas per aplikasi, terutama jika Anda memilih memaksa MTE untuk semua aplikasi yang dipasang pengguna
Aplikasi perbankan berjalan jika bank mengizinkan OS yang tidak tersertifikasi Google, dan sejauh ini kebanyakan masih mengizinkannya
Namun bank-bank makin sering memblokir OS yang tidak tersertifikasi Google, jadi ini pada dasarnya perlu ditangani sebagai isu regulasi antipersaingan
Sementara itu, kami sedang berusaha meyakinkan bank agar memakai https://grapheneos.org/articles/attestation-compatibility-guide
Fitur keamanan tambahan, pengaturan sandboxing, dan hardened memory allocator yang membuatnya sedikit lebih lambat memang lebih merepotkan dibanding memakai Android bawaan lalu menekan OK untuk semua permintaan akses data
Butuh sedikit waktu juga untuk memahami pengaturan awal, apa yang berbeda pada GrapheneOS, dan cara memakai fitur keamanannya
Selama 4 tahun memakai, tidak ada crash
Setidaknya tidak ada crash seluruh sistem, dan berdasarkan pengalaman saya, crash yang perlu debug berhari-hari tidak terjadi karena hardware Pixel dan software-nya sudah diselaraskan dengan baik
Aplikasi perbankan tergantung aplikasinya
Sebagian berjalan tanpa Play Services, kebanyakan berjalan dengan Play Services yang di-sandbox, dan hanya sangat sedikit yang sama sekali tidak berjalan
Jika Anda menyebutkan bank yang dipakai, pengguna lain bisa mengecek apakah berjalan atau tidak
Cara instalasi yang sulit pun hanya sebatas menghubungkan ponsel lewat USB, menekan tombol power/volume sebentar, lalu menyalin-tempel dua atau tiga perintah terminal
Cara yang mudah hanya menghubungkan ponsel ke komputer dan menekan tombol instalasi sekali klik yang berjalan di browser Chrome
Sejak tak lama setelah Google Pixel 6 keluar, saya hampir terus memakainya sebagai OS harian, dan tidak pernah sekalipun crash
Tidak pernah ada bug atau perlu debug, perbaikan, maupun pemeliharaan
Semua aplikasi yang saya coba berjalan begitu saja seperti di Android bawaan, dan jujur saya hampir tidak merasakan perbedaannya
Kadang saya bahkan lupa bahwa ini bukan OS yang awalnya terpasang di ponsel
Secara pribadi aplikasi perbankan Discover berjalan, tetapi untuk aplikasi lain saya tidak bisa memastikan
Namun karena ada Google Play services dan bootloader dikunci setelah instalasi, kemungkinan besar kebanyakan akan berjalan
Pada 2024, kita membutuhkan sistem operasi yang diverifikasi secara formal pada level yang lebih ketat, beserta aplikasi dan tooling-nya, yang meneruskan semangat seL4
Di era seperti sekarang, merangkai codebase yang over-engineered dan hanya diuji seadanya dengan bahasa yang rapuh dan berbahaya berarti menciptakan permukaan serangan untuk bug menjengkelkan, malware, dan peretasan dalam jumlah besar, bahkan bisa diretas aktor asing hingga pengguna terbunuh
Di atas itu juga harus disediakan pengalaman pengguna yang rapi dan terintegrasi serta fitur yang layak pakai; jika tidak, semua rekayasa itu akan sia-sia
Lihat saja Qubes OS
Apakah ada komputer single-board yang cukup bagus yang mengimplementasikan Arm MTE? Misalnya Raspberry Pi terbaru
RasPi 5 memakai quad A76 dan ekstensi v8.2, sedangkan MTE adalah v8.5
Bagaimana MTE dibandingkan dengan CHERI?
MTE ditujukan untuk menemukan bug keamanan potensial, bukan perlindungan sungguhan
Tagnya hanya 4 bit dan bisa dipalsukan oleh aplikasi, jadi jika penyerang harus menebak tag yang benar, memilih acak pun punya peluang 1/16 untuk benar
Gagasannya adalah dengan menerapkan MTE, akses yang salah kadang bisa terjadi bahkan tanpa penyerang, dan kasus yang sebenarnya tidak menimbulkan akibat buruk pun bisa tertangkap
Bayangkan buffer overflow yang tipikal: word tepat setelah akhir buffer mungkin tidak dipakai untuk tujuan lain, sehingga dalam praktiknya tetap bisa berjalan
MTE mendeteksi akses seperti ini, sehingga bisa diselidiki dan dipatch sebelum menjadi exploit yang dipersenjatai
Namun, melalui tag yang dicadangkan, ia bisa memberikan properti keamanan deterministik yang kuat
Yang tidak diberi tag memiliki tag 0, dan yang diberi tag secara default memiliki tag non-0 karena pengecualian default
Tag lain juga bisa dikecualikan secara statis maupun dinamis lewat instruksi, tetapi untuk penggunaan internal seperti memori yang sudah dibebaskan, kita bisa memanfaatkan fakta bahwa jika tag 0 dipakai maka pointer bertag mana pun tidak dapat mengaksesnya
Pada hardened_malloc, untuk slot alokasi, tag yang berdekatan dan tag yang sebelumnya dipakai dikecualikan secara dinamis
Ini memberikan perlindungan deterministik terhadap overflow linear dan overflow kecil
Untuk use-after-free, pointer yang menunjuk ke alokasi yang sudah dibebaskan tidak dapat mengaksesnya selama masih dibebaskan atau tepat setelah dialokasikan ulang; ia harus menunggu sampai nanti dialokasikan lagi, dan saat itu peluang mendapat tag yang benar adalah 1/15
Ini berpadu dengan baik dengan properti keamanan lain dari hardened_malloc
Untuk alokasi slab dan memori virtual, ada zona karantina FIFO/acak untuk lebih menunda penggunaan ulang dan membuatnya tidak deterministik
Sebelum melewati 128k, lokasi memori tidak pernah digunakan ulang antar kelas ukuran alokasi yang berbeda; tiap kelas berada di area berbeda, dan semua metadata berada di area cadangan lain lagi
Pada kasus umum, MTE saat ini hanya 4 bit sehingga peluang bypass sekitar 1/15
Ini bisa dengan mudah diperluas untuk mendukung penggunaan 8 bit, dan jika tidak memakai PAC masih ada bit bebas lain
Secara teori, pada ruang alamat 39 bit yang umum, untuk ruang alamat 48 bit atau lebih, MTE hingga 16 bit pun bisa didukung
Saat ini ia dikunci pada 4 bit; saya dengar ini dipilih alih-alih 8 bit agar bit tambahan bisa disimpan di memori paritas ECC
Namun, pendeteksiannya tidak seandal CHERI
Tidak ada perlindungan untuk tag dan ruang tag juga kecil (2^4)
Saya menunggu hari ketika hardware arus utama mengejar arsitektur memory tagging seperti Solaris SPARC 2015 atau bahkan sebelumnya, sehingga akhirnya masalah kerusakan memori bisa dikendalikan
Tentu saja, masalah-masalah itu sering dianggap seolah hanya dibuat oleh developer yang tidak kompeten
Ini bukan masalah “developer tidak kompeten”, melainkan masalah semua orang
Kerusakan memori pada dasarnya hampir seperti fitur bahasa C/C++
Sebaiknya jangan menyebarkan keyakinan bahwa itu terjadi karena orang bodoh
Hampir tidak ada orang yang menganggap dirinya bodoh, dan saya pernah melihat coder yang benar-benar hebat pun membuat bug memori yang konyol
Itu memang termasuk dalam ranah bahasa-bahasa tersebut, dan persoalannya bukan “jika”, melainkan “kapan”
Saya suka bahwa ada kalimat yang disisipkan secara halus bahwa ini menunjukkan mengapa Android telah memindahkan sebagian besar kode Bluetooth ke Rust, dan perlu mengalokasikan lebih banyak sumber daya untuk memindahkan sisa kodenya ke Rust
Saya memakai C dan C++ selama bertahun-tahun tetapi belum punya pengalaman Rust, jadi penasaran seberapa banyak refactoring yang diperlukan saat mem-port C ke Rust
Jika pertanyaannya dipecah: 1. Seberapa langsung C bisa diterjemahkan ke Rust? Apakah Rust menuntut penataan ulang struktur atau refactoring?
2. Bagaimana Google mendekatinya? Apakah mereka berusaha “menerjemahkan” sedekat mungkin, atau melihatnya sebagai kesempatan untuk penulisan ulang/refactoring besar-besaran?
Saya juga penasaran apakah suatu hari stack Bluetooth Android bisa digunakan di sistem desktop distribusi Linux standar
Karena banyak referensi siklik, strukturnya membuat modul-modul saling berkomunikasi melalui “bus sinyal” dengan callback, dan rasanya Rust lebih harus dilawan daripada membantu
Bahkan di tempat yang di C++ datanya bisa disimpan inline, saya banyak membutuhkan Box, yaitu pointer heap
Kesimpulannya, untuk tool command-line sederhana atau struktur request-response, porting ke Rust mungkin mudah
Secara lebih umum, jika struktur kode cocok dengan arena allocation, memindahkannya dengan memberi tag lifetime pada referensi bukan masalah besar
Namun jika Anda menulis kode ala programmer C dengan referensi siklik—yang memang harus diakui jelek—Rust akan terasa seperti tanjakan dan bukan tempat yang baik untuk memulai
Pertama-tama struktur kode C++ perlu diubah agar ownership dipindahkan ke parent bersama
Sepertinya itu akan membuatnya lebih baik
Saya akan terus belajar Rust secara bertahap, tetapi tetap bekerja di C++ sampai kodenya lebih selaras dengan Rust
Banyak bagian dari apa yang sedang ditulis harus diarsitektur ulang
Itu tidak bisa dihindari karena cara Rust menjamin memory safety