GrapheneOS’un ARM MTE ile keşfettiği Bluetooth bellek bozulması
(grapheneos.social)- Pixel 8 ve Pixel 8 Pro’nun donanımsal bellek etiketleme desteği, Android 14 QPR2’de Bluetooth LE’ye yeni giren bir bellek bozulması hatasını ortaya çıkardı
- Nedenin Bluetooth LE’deki upstream use-after-free hatası olduğu doğrulandı; GrapheneOS bir düzeltme yaması hazırladı ve bunu yeni sürüme dahil etmeyi planlıyor
- Sorunu Samsung Galaxy Buds2 Pro’nun Bluetooth LE modunda yeniden üreten bir kullanıcı, düzeltmenin çalıştığını doğruladı; stock Pixel OS de etkileniyor
- GrapheneOS, Bluetooth’un büyük bir saldırı yüzeyi olması nedeniyle, ilgili süreçte bellek etiketlemeyi kapatan bir geçici çözümün kısa vadede bile uygun olmadığını düşünüyor
- Android Bluetooth kodunun bir kısmı Rust’a taşındı, ancak kalan kodun taşınması ve HWASan/MTE derlemelerinin gerçek cihazlarda test edilmesi için daha fazlası gerekiyor
Android 14 QPR2’deki Bluetooth LE hatası ve düzeltmesi
- GrapheneOS, Pixel 8 ve Pixel 8 Pro’nun donanımsal bellek etiketleme desteği sayesinde Android 14 QPR2’deki Bluetooth LE bellek bozulması hatasını keşfetti
- Bu, tüm Bluetooth cihazlarında yaşanan bir sorun değil; yalnızca belirli Bluetooth LE cihazlarında yeniden üretilebiliyor
- GrapheneOS, yeni eklenen özelliği düzeltmenin veya geçici olarak devre dışı bırakmanın yollarını araştırıyor
- Nedenin Bluetooth LE’deki upstream use-after-free hatası olduğu doğrulandı ve GrapheneOS bir yama geliştirdi
- Öncelik, bu düzeltmeyi içeren GrapheneOS sürümünü hızlıca dağıtmak
- Android güvenlik hatası olarak bildirilecek
- Bu düzeltmenin BLE ses regresyonunu da çözmesi bekleniyor
- Samsung Galaxy Buds2 Pro’yu Bluetooth LE modunda kullanarak sorunu yeniden üreten bir kullanıcı, düzeltmenin çalıştığını doğruladı
- Aynı sorun stock Pixel OS’i de etkiliyor
- GrapheneOS bunu hardened_malloc’ın bellek etiketleme desteğiyle tespit etti ve kopyalanabilir rapor içeren MTE çökme bildirimi ekledi
MTE’nin uygulanma biçimi ve Android Bluetooth kodundaki zorluklar
- GrapheneOS, bu süreçte bellek etiketlemeyi kapatan geçici çözümün kısa vadede bile uygun olmadığını düşünüyor
- Bluetooth, bu hatanın pratikte istismar edilebilir olup olmamasından bağımsız olarak büyük bir saldırı yüzeyi
- Android, Bluetooth kodunun önemli bir bölümünü Rust’a taşıdı; ancak kalan kodun taşınması için de daha fazla kaynağa ihtiyaç var
- Gerçek ortamda, çeşitli Bluetooth cihazlarıyla HWASan ve MTE derlemelerinin daha fazla test edilmesi gerekiyor
- Pixel cihazlar, önemli bir donanım güvenlik özelliği olan MTE’ye sahip; ancak varsayılan işletim sistemi, %3,125 bellek ve önbellek kullanımı tasarrufu gerekçesiyle bunu etkinleştirmiyor
- Hesaplama, etiketli bellekte her 16 bayt için 4 bitlik etiket temel alınarak yapılıyor
- heap MTE, async mode’da performans ek yükü neredeyse %0’a yakın; asymmetric mode’da ise maliyeti SSP gibi mevcut hafifletme yöntemlerinden daha düşük
- GrapheneOS, varsayılan işletim sistemiyle uyumlu olduğu bilinen kullanıcı tarafından yüklenmiş uygulamalarda MTE’yi varsayılan olarak etkinleştiriyor
- Settings > Security üzerinden, kullanıcı tarafından yüklenen tüm uygulamalar için opt-in olarak açılabiliyor
- Çökme raporunu kopyalamaya yarayan bildirim ve uygulama bazında anahtar sunuyor
- GrapheneOS’un hardened_malloc MTE uygulaması standart rastgele etiketleri ve özel free etiketini kullanıyor; önceki etiketi ve mevcut ya da önceki bitişik etiketleri dinamik olarak hariç tutuyor
- Chromium entegrasyonu düzeltildi; PartitionAlloc’un da iyileştirilmesi planlanıyor
1 yorum
Hacker News yorumları
Pixel'lerin MTE adlı büyük bir donanım güvenlik özelliğiyle gelmesine rağmen OS tarafında bellek/önbellek kullanımında %3,125 tasarruf etmek için bunu açmaması tuhaf
Pixel ekibinin bu kararı nasıl gerekçelendirdiğini gerçekten görmek isterdim; bu kadar önemli bir güvenlik özelliğini çok küçük bir performans kazancı için kapatma düşünce sürecini de merak ediyorum
Yine de GrapheneOS harika bir proje olsa da desteklediği cihaz sayısı yaklaşık 11 ile sınırlı; AOSP değişiklikleri ise çok daha büyük bir OEM ekosistemini hesaba katmak zorunda
Android'i daha iyi hale getirmenin yollarını her zaman arıyoruz, ancak belirli bir özelliğin sunumunu eleştirirken daha büyük OEM ekosistemini görmezden gelmek dar bir bakış gibi görünüyor
Bu özelliğin açılmamış olmasının nedeninin bellek/önbellekteki %3 tasarruf olması son derece düşük bir olasılık; muhtemelen başka değerlendirmeler vardı
Özelliğin açılıp açılmayacağına karar verirken muhtemelen daha büyük etken bu taraftır
Diğer OS'lerin de şu anda MTE etkin halde piyasaya sürülmediği söyleniyor; dolayısıyla açıp açmama kararı daha nüanslı bir değerlendirme olabilir
Google tarafındaki insanlar başta donanım MTE için bastırdı ve bu iş ASAN, syzkaller vb. ile ilgilenen ekipten çıktı
Android ekibine bağlı değildi ama Android tarafından yardım ve destek vardı; ARM gibi taraflarla işbirliği de elbette vardı
O dönemde bu ekipleri yöneten kişi olarak ödünleri iyi biliyorum; mesele yalnızca bellek ya da önbellek sorunu değil
MTE'nin dinamik olarak açılıp kapatılabildiği ve performans maliyetinin neredeyse 0'a yakın olacak şekilde tasarlandığı doğru, ancak o zamanki ana kullanım alanı örnekleme tabanlı hata bulmaydı
Tüm cihaz filosunda zamanın yalnızca %1'inde açık olsa bile ölçek yeterince büyükse hataları çok hızlı bulabilir, ayrıca iç testlerde de kullanılabilir
Yani amaç, istenildiğinde ASAN'a denk bir işlevi açıp kapatabilmekti
Sürekli açık bir güvenlik hafifletmesi olarak kullanmak ikincil bir olasılıktı ve bellek ek yükünün dışında da sorunları var
Örneğin kullanıcıya görünen çökmeler birden çok artıyor; MTE olan telefonlarda çöküp olmayan telefonlarda çökmeyebilir, bu da tutarlılık sorununa yol açar
Geliştirici açısından da MTE etkin telefon neredeyse tek bir modelken herkesi o telefonla test yapmaya zorlamak pek hoş karşılanmaz
Güvenlik açıklarından yararlanmayı engelleyebilir ve istismar yerine çökme olmasını sağlayabilir
Zararsız hataları da yakalayabilir
Ancak yukarıda söylediğim gibi, kullanılmadığını varsaymazdım; üretimde her zaman açık tutulmadığını düşünmek daha doğru görünüyor
Böyle bir donanım özelliğini devreye alma deneyimi olan biri, sistemin boot edip çalışması ve yalnızca belirli bir davranışta MTE altında çökmesi gerçeğinin bile aslında zaten kullanıldığına dair iyi bir işaret olduğunu söylerdi
Kullanılmıyor olsaydı muhtemelen milyon kez çökerdi
Ek olarak, çalışma zamanı hafifletmesi olarak en iyisi olup olmadığı da net değil
Varsayılan Pixel, son kullanıcıya varsayılan etkin durumda sunmuyor olabilir; ancak isteyen herkes geliştirici seçeneklerinden Memory Tagging Extensions'ı açabilir
Kapatana kadar açık kalmasını sağlayabilir ya da belirli bir uygulamayı test etmek için yalnızca tek bir oturumda açabilir
Varsayılan Pixel OS'te geliştirici seçeneklerinden bellek etiketleme desteğini açmak, onu yalnızca kullanılabilir hale getirir; fiilen kullanmaz
Android Debug Bridge (ADB) shell'de
setpropile heap bellek etiketlemeyi de açmak gerekirAyırmalara etiket eklenmiyorsa yalnızca açık olması hiçbir değer taşımaz
Varsayılan ayırıcı uygulaması Scudo üzerinden varsayılan OS'te kullanıcı alanı heap MTE tamamen açılabilir, ancak şu anda özel olarak güçlendirilmiş bir uygulama değil
MTE arka ucunu kullanan KASan da
setpropile kullanılabilir, ancak şu anda güçlendirme amacıyla tasarlanmış değil ve gelecekte böyle olup olmayacağı da net değilÇekirdekte KASan'ın bir parçası olmayan ayrı bir MTE uygulamasına ihtiyaç duyulması muhtemel; GrapheneOS da bunu henüz yapmadığı için mevcut MTE güçlendirmesi kullanıcı alanı özelliği
GrapheneOS, hardened_malloc için kendi donanım bellek etiketleme uygulamasını kullanıyor ve güvenlik özellikleri daha güçlü
Varsayılan OS'te varsayılan olarak etkinleştirmek için bu sorun dahil birçok problemi düzeltmek veya etrafından dolaşmak gerekiyordu
Ana çekirdeklerde asenkron MTE kullanmak yerine tüm çekirdeklerde asimetrik modu kullanıyor
Asimetrik mod yazma işlemlerinde asenkron, okuma işlemlerinde senkron olduğu için istismarın başarılı olabileceği bir fırsat penceresi bırakmadan düzgün şekilde engelliyor
Sistem çağrılarında denetleniyor; başka bir aşma yolu olabilecek io_uring ise SELinux kısıtlamalarıyla Android'de yalnızca 2 çekirdek sistem sürecine izinli
fastbootd yalnızca kurulum sırasında kullanılıyor, snapuserd ise güncelleme uygulandıktan sonra çekirdek OS tarafından kullanılıyor
GrapheneOS, varsayılan OS ile uyumlu olduğu doğrulanmış uygulamalarda her zaman heap MTE kullanıyor
Kullanıcının yüklediği uygulamalardan uyumluluk veritabanında olmayan ve kendini uyumlu olarak işaretlememiş olanlar için uygulama bazında MTE anahtarı sunuyor
Kullanıcılar, kullanıcı tarafından yüklenen uygulamalara varsayılan olarak MTE'yi zorunlu kılmayı da açabilir veya yalnızca uyumsuz uygulamaları hariç tutabilir
Bunu gerçekten kullanılabilir hale getirmek için kullanıcıya görünen bir çökme raporlama sistemi gerekiyordu; geliştiriciye yararlı çökme raporlarının kolayca kopyalanıp gönderilebilmesini sağlayacak şekilde uyguladık
Ayarlarda Memory Tagging Extensions diye aratınca var görünüyor; bir yerlerde gizli sandım, meğer Pixel 8 telefonlara özelmiş: https://news.ycombinator.com/item?id=38125379
GrapheneOS, güvenlik açısından diğerlerinden o kadar ileride ki Pixel donanımı dışında bir şey seçmek sorgulanır hale geliyor
Ama gerçekten değiştirilebilir pil istiyorum
Bugünlerde neden her şeyin bu kadar kötü olduğunu bilmiyorum
Diğer Android cihazlar yanına bile yaklaşamıyor
Donanımsal bellek etiketleme desteği, Pixel’in birçok büyük güvenlik avantajından biri
Resmî donanım gereksinimleri listesi burada: https://grapheneos.org/faq#future-devices
Bu gereksinimler 8. nesil Pixel’lerde tamamen karşılanıyor
6./7. nesil Pixel’lerde yalnızca MTE, BTI ve PAC eksik; bunlar içinde MTE, donanım gereksinimleri listesindeki en değerli özellik
Düzgün güvenlik yamaları daha önemli ve Pixel dışında aynı şekilde sunulmuyor
Android’in aylık, üç aylık ve yıllık sürümleri var
Diğer Android OEM’leri, aylık güvenlik backport’larında yalnızca Critical/High önem dereceli düzeltmelerin tamamını sağlıyor; çoğu gizlilik düzeltmesini de içeren Moderate/Low önem dereceli düzeltmelerin çoğunu ise sağlamıyor
Alternatif bir OS kullanarak bu yamaları sağlamak bunu bir ölçüde hafifletir, ancak o cihazlara yönelik alternatif OS’ler çoğu zaman güvenliği çeşitli şekillerde geri alıyor
Firmware ve cihaz destek kodlarının büyük kısmı aslında OEM’den geliyor
Android 12 çekirdeği/sürücüleri üzerinde Android 14 QPR2 çalıştırmak mümkün, ancak OS’nin büyük bölümlerindeki güvenlik iyileştirmeleri eksik kalıyor
Pixel pillerini cihazı hasara uğratmadan değiştirmek pek kolay değil, ama resmî olarak destekleniyor ve resmî parçalar da var: https://www.ifixit.com/Device/Google_Pixel
Temel gereksinimleri bile karşılamayan güvensiz cihazları destekleyemeyiz
Donanım gereksinimleri listemizde, çoğu Android OEM’inin sunmadığı çok temel şeylerin yanı sıra artık düzgün güvenliğin temel gereksinimi olarak gördüğümüz MTE gibi gelişmiş özellikler de yer alıyor
Başka cihazları da desteklemek isteriz, ama bu cihazların bu gereksinimleri karşılaması gerekiyor
Bellek etiketleme, standart Cortex ARMv9 çekirdeklerinin desteklediği temel bir özellik
Qualcomm’un bunu uygulamaması ve bunu destekleyen SoC’leri kullanan OEM’lerin de yapılandırmaması üzücü
CPU mimarisinde özellik varken SoC ya da OEM yüzünden kullanılamaması üzücü bir durum
Yine de Pixel 8’in 7 yıl desteklenecek olması sevindirici
Apple’a da, Samsung’a da güvenmek zor; Google en azından en iyi seçenek haline geldi
GrapheneOS kullanan biri yanıtlayabilirse iyi olur
Ancak yakın zamanda eşimle Orlando, Florida'daki Disney World ve Universal Studios'a gittiğimizde, sandbox'lanmış Google Play Services ile uygulamalar genel olarak çalışsa da can sıkıcı sorunlar vardı
My Disney Experience uygulamasında konumla ilgili epey hata vardı ve ara sıra önemli bir işlem yapmak için ABD veya Kanada'da olmanız gerektiğini söyleyerek eşimin telefonunu geçici çözüm olarak kullanmamı gerektirdi
Universal uygulamasında hesaba giriş yapamadım; eşimin standart Samsung Galaxy'sinde sorunsuz çalıştığı için GrapheneOS kaynaklı bir sorun gibi görünüyordu
Ayrıca Google Wallet ile kredi kartı ödemesi yapıyorsanız, Google GrapheneOS'u sertifikalandırmadığı için desteklenmiyor
Wallet'ın diğer özellikleri çalışıyor
Uber sorunsuz çalışıyor
Bunun dışında kapalı kaynak uygulama kullanmıyorum
Ağırlıklı olarak özgür/açık kaynak uygulamalar kullanmayı düşünüyorsanız sorun yaşamazsınız
Kapalı kaynak uygulamaların çoğu sandbox'lanmış Google Play Services ile çalışıyor, ancak bunların arasında iş açısından çok kritik bir uygulama varsa Universal Studio ve My Disney Experience'ta yaşadığım gibi can sıkıcı sorunlarla karşılaşabilirsiniz
Normal bir USB kablo ve Linux komut satırında adb kullandım, ancak önerilen yöntem Chromium'un WebUSB'sini kullanmak ve teknik olmayan kişiler için daha kolay olmalı
Yine de bende pek iyi çalışmadı
Sandbox'lanmış Google Play Services olduğu için modern hayata katlanmayı sağlayan türlü kapalı kaynak uygulamaları kurabiliyor, buna rağmen Google Play'in telefonun tamamına sınırsız erişememesi sayesinde iki dünyanın da iyi yanlarını almış oluyor
Daha fazla yalıtım isterseniz ayrı bir kullanıcı oluşturup Google Play ile ilgili öğeleri o hesapta çalıştırabilirsiniz
Kısa süre denedim ama kişisel olarak her seferinde kullanıcı değiştirmek zahmetli geldi
Telefon hiç çökmedi ve banka uygulamaları da çalışıyor
Cihaz Pixel 6a
Kurulu bir cihaz da satın alabilirsiniz, ancak neredeyse herkes web yükleyiciyi kullanabilir
Android, ChromeOS ve macOS'ta özellikle kolay; Windows sürücü kurulumu gerektirdiği için biraz daha uğraştırıcı
Masaüstü Linux'ta udev kurallarının kurulması gerekiyor ve yazılım sürümleri sabitlenen bazı dağıtımlarda engel çıkaran hatalı servisler var
Teknik olmayan kişiler de yapabilir; WebUSB destekleyen bir tarayıcı yeterli
Özel bir yazılım gerekmiyor
Günlük kullanımda sandbox'lanmış Google Play kullanırsanız temel Pixel OS ile neredeyse aynı ve uygulama uyumluluğu da neredeyse benzer
Anlamlı derecede daha fazla çökme yaşamanız pek olası değil
Temel OS'ta bulunmayan kullanıcıya yönelik çökme raporlaması olduğu için normalde fark etmeyeceğiniz çökmeleri fark edebilirsiniz
Bellek bozulması olan hatalı uygulamalar, uygulama bazlı uyumluluk modunu açana kadar çökebilir; özellikle de kullanıcı tarafından yüklenen tüm uygulamalarda MTE'yi zorunlu kılmayı seçerseniz bu daha olası
Banka uygulamaları, banka Google sertifikalı olmayan OS'lara izin veriyorsa çalışır; şimdilik çoğu hâlâ izin veriyor
Ancak bankalar giderek Google sertifikalı olmayan OS'ları engellediği için bu esasen rekabet karşıtı bir düzenleme meselesi olarak ele alınmalı
Bu arada bankaları https://grapheneos.org/articles/attestation-compatibility-guide kullanmaya ikna etmeye çalışıyoruz
Ek güvenlik özellikleri, sandboxing ayarları ve hardened memory allocator nedeniyle biraz yavaş olması, sadece stok Android kullanıp veri erişim isteklerinin hepsine OK demekten daha zahmetli
İlk kurulum ve GrapheneOS'un neyi farklı yaptığı, güvenlik özelliklerinin nasıl kullanılacağı da biraz zaman istiyor
4 yıl boyunca hiç çökme yaşamadım
En azından sistem genelinde çökme olmadı; günlerce debug gerektiren çökmeler, Pixel donanımı ve yazılımı birbirine iyi uyumlu olduğu için deneyimime göre yaşanmıyor
Banka uygulamaları uygulamaya göre değişiyor
Bazıları Play Services olmadan da çalışıyor, çoğu sandbox'lanmış Play Services ile çalışıyor ve çok azı hiç çalışmıyor
Hangi bankayı kullandığınızı söylerseniz diğer kullanıcılar çalışıp çalışmadığını doğrulayabilir
Zor kurulum yöntemi bile telefonu USB ile bağlayıp güç/ses düğmelerine biraz bastıktan sonra terminalde iki üç komutu kopyalayıp yapıştırmaktan ibaret
Kolay yöntem ise telefonu bilgisayara bağlayıp Chrome tarayıcıda çalışan tek tıkla kurulum düğmesine basmak
Google Pixel 6 çıkar çıkmazdan beri neredeyse sürekli günlük OS olarak kullanıyorum ve tek bir kez bile çökmedi
Hata çıktığı ya da debug, düzeltme, bakım gerektiği de olmadı
Denediğim tüm uygulamalar stok Android'deki gibi doğrudan çalıştı ve açıkçası farkı neredeyse hissetmiyorum
Bazen bunun telefonda başlangıçta yüklü gelen OS olmadığını bile unutuyorum
Kişisel olarak Discover banka uygulaması çalışıyor, ancak diğerlerinden emin değilim
Yine de Google Play services olduğu ve kurulumdan sonra bootloader kilitlendiği için muhtemelen çoğu çalışır
2024'te seL4 ruhunu sürdüren ama daha katı düzeyde biçimsel olarak doğrulanmış işletim sistemlerine, uygulamalara ve araçlara ihtiyacımız var
Günümüzde hafifçe test edilmiş, aşırı tasarlanmış codebase'leri kırılgan ve tehlikeli dillerle birbirine eklemek; yabancı aktörlerin hack'leyip kullanıcıların ölmesine yol açabileceği, ayrıca çok sayıda can sıkıcı bug ve kötü amaçlı yazılım/hack saldırı yüzeyi yaratan bir şey
Bunun üstüne temiz ve bütünleşik bir kullanıcı deneyimi ile işe yarar özellikler de sunulmalı; aksi halde tüm mühendislik boşa gider
Qubes OS'a bakın
İyi sayılabilecek tek kart bilgisayarlardan Arm MTE uygulayan var mı? Yeni Raspberry Pi gibi mesela
RasPi 5 dört çekirdekli A76 ve v8.2 uzantılarını kullanıyor; MTE ise v8.5
MTE, CHERI ile karşılaştırıldığında nasıl?
MTE potansiyel güvenlik hatalarını bulmaya yöneliktir, gerçek bir koruma değildir
Etiket yalnızca 4 bit ve uygulama tarafından sahte üretilebilir; dolayısıyla saldırganın doğru etiketi tutturması gerekiyorsa rastgele seçse bile 1/16 olasılıkla tutturur
MTE uygulandığında, saldırgan olmasa bile ara sıra hatalı erişimlerin gerçekleşebileceği ve bunların gerçekte kötü bir sonuç üretmediği durumları yakalayabilme fikrine dayanır
Tipik bir buffer overflow düşünürsek, tamponun hemen sonrasındaki sözcükler başka amaçla kullanılmadığı için pratikte çalışıyor olabilir
MTE bu tür erişimleri algılar ve silahlandırılmış bir exploit hâline gelmeden önce incelenip yamalanmasını sağlar
Bununla birlikte ayrılmış etiketler üzerinden güçlü, deterministik güvenlik özellikleri sağlayabilir
Etiketlenmemiş olan 0 etiketlidir; etiketlenmiş olan ise varsayılan dışlama nedeniyle temelde 0 olmayan bir etikete sahiptir
Diğer etiketler de komutlarla statik veya dinamik olarak dışlanabilir; fakat serbest bırakılmış bellek gibi iç kullanımlar için 0 etiketini kullanarak, etiketli hiçbir işaretçinin buna erişemeyeceği gerçeğinden yararlanılabilir
hardened_malloc’ta, ayırma slotları için bitişik etiketler ve daha önce kullanılmış etiketler dinamik olarak dışlanır
Bu da doğrusal taşmalara ve küçük taşmalara karşı deterministik koruma sağlar
use-after-free durumunda, serbest bırakılmış ayırmayı gösteren işaretçi, serbest durumdayken veya hemen yeniden ayrıldıktan sonra erişemez; bir sonraki yeniden tahsise kadar beklemesi gerekir ve o zaman doğru etikete sahip olma olasılığı 1/15’tir
Bu, hardened_malloc’ın diğer güvenlik özellikleriyle iyi birleşir
slab ayırma ve sanal bellek için FIFO/rastgele karantina bölgeleri kullanarak yeniden kullanımı daha da geciktirir ve deterministik olmaktan çıkarır
128k’yı aşana kadar farklı ayırma boyutu sınıfları arasında bellek konumları asla yeniden kullanılmaz; her sınıf farklı bir bölgededir ve tüm metadata da bambaşka bir ayrılmış bölgededir
Genel durumda MTE şu anda yalnızca 4 bit olduğu için atlatma olasılığı yaklaşık 1/15’tir
8 bit kullanım desteğiyle kolayca genişletilebilir; PAC kullanılmıyorsa başka boş bitler de vardır
Teorik olarak, genel 39 bit adres alanında 48 bit ve üzeri adres alanları için 16 bite kadar MTE bile desteklenebilir
Şu anda 4 bit’e sabitlenmiş durumda; ECC parity belleğinde ek bitlerin saklanabilmesi için 8 bit yerine bunun seçildiğini duydum
Ancak bunu CHERI kadar güvenilir biçimde algılamaz
Etiketler için koruma yoktur ve etiket alanı da küçüktür (2^4)
Ana akım donanımların 2015 Solaris SPARC’ın ya da daha öncesinin bellek etiketleme mimarilerini yakalayıp sonunda bellek bozulması sorununu kontrol altına alacağı günü bekliyorum
Elbette bu sorunlar çoğu zaman yalnızca beceriksiz geliştiricilerin yaptığı şeyler diye geçiştiriliyor
Bu bir “beceriksiz geliştirici” sorunu değil, herkesin sorunu
Bellek bozulması fiilen C/C++’ın bir dil özelliğine yakın
Bunun aptal insanlardan kaynaklandığı inancını yaymamak daha iyi
Kendini aptal sanan pek az kişi vardır; gerçekten çok iyi kodcuların da komik bellek bug’ları yaptığını gördüm
Bu, o dillerin alanına dahil bir şey ve mesele “olursa” değil, “ne zaman” meselesi
Android’in Bluetooth kodunun büyük bir bölümünü Rust’a taşıdığını ve kalan kodu da Rust’a taşımak için daha fazla kaynak ayırması gerektiğini gösteren cümlenin araya ustaca yerleştirilmiş olmasını sevdim
C ve C++’ı yıllarca kullandım ama Rust deneyimim yok; C’den Rust’a port ederken ne kadar refactoring gerektiğini merak ediyorum
Soruyu bölersek: 1. C, Rust’a ne kadar doğrudan çevrilebilir? Rust yapının yeniden düzenlenmesini veya refactoring gerektirir mi?
2. Google buna nasıl yaklaşıyor? Mümkün olduğunca yakın bir “çeviri” mi yapmaya çalışıyor, yoksa bunu büyük ölçekli yeniden yazım/refactoring fırsatı olarak mı görüyor, merak ediyorum
Android Bluetooth stack’inin bir gün standart Linux dağıtımı masaüstü sistemlerinde kullanılabilir hâle gelip gelmeyeceğini de merak ediyorum
Çok fazla döngüsel referans vardı; modüller callback’leri olan bir “sinyal bus” üzerinden birbirleriyle iletişim kuruyordu ve Rust yardımcı olmaktan çok, onunla mücadele etmem gerekiyormuş gibi hissettirdi
C++’ta veriyi inline saklayabildiğim yerlerde bile heap işaretçisi olan Box’a çok ihtiyaç duydum
Sonuç olarak, basit bir komut satırı aracı ya da istek-yanıt yapısıysa Rust’a port etmek muhtemelen kolaydır
Daha genel olarak kod yapısı arena allocation ile iyi uyuşuyorsa, referanslara lifetime etiketleri ekleyerek taşımak büyük bir sorun değil
Ama C programcısı tarzında döngüsel referansları olan, kabul etmek gerekirse çirkin kod yazdıysanız Rust yokuş yukarı çıkmak gibi hissettirir ve başlamak için iyi bir yer değildir
Önce C++ kod yapısını değiştirip sahipliği ortak bir parent’a taşımanız gerekir
O zaman daha iyi olacak gibi
Rust’ı yinelemeli olarak daha fazla öğrenip, kod Rust ile daha iyi eşleşene kadar C++’ta çalışmaya devam etmeyi düşünüyorum
Yazdığınız şeyin önemli bir kısmını yeniden mimarilendirmeniz gerekecek
Rust’ın bellek güvenliğini garanti etme biçimi nedeniyle bundan kaçış yok