Tarihçe: Sistem programlamasında, Rust'ın C ve öngörülebilir bellek düzenleri gerektiren diğer dillerle birlikte çalışması gerekmektedir. İlk Rust sürümleri, dolgu ve önbellek kayıplarını en aza indirmek için, alanları rastgele yeniden düzenleme gibi agresif derleyici optimizasyonlarına izin vermekteydi; oysa C, beyan sırasına göre alan yerleşimini zorunlu kılmaktadır. Bu farklılık, FFI sınırları için istikrarı garanti altına almak amacıyla açıkça temsil özellikleri gerektirmektedir.
Sorun: repr(Rust) varsayılan olarak derleyiciye yapı alanlarını yeniden düzenleme, dolgu ekleme ve niş değerleri optimize etme özgürlüğü tanır; bu da ikili temsilin belirsiz olduğu ve derleyici sürümleri arasında değişebileceği anlamına gelir. Öte yandan, repr(C) kararlı, C-uyumlu bir düzen uygular ve belirli alan ofsetleri sağlar. Ağ paketleri veya C kütüphanelerinden gelen ham baytları repr(Rust) yapılarıyla dönüştürmek, Rust'ın bellek modelini ihlal eder çünkü gerçek alan ofsetleri kaynak verilerle uyuşmayabilir ve geçersiz değerlerin yüklenmesine veya hizalanmamış erişimlere neden olabilir.
Çözüm: FFI veya ham bellek eşlemesi için tasarlanan yapıları #[repr(C)] ile açıkça etiketleyin; bu, alan sırasını ve hizalamayı dondurur. Düzen esnekliğinin kabul edilebilir olduğu tamamen Rust kodu için repr(Rust) varsayılan kalmaya devam eder. FFI olmadan serileştirme gerektiğinde, mem::transmute yerine güvenli serileştirme kütüphanelerini tercih edin, çünkü repr(C) bile dolgu baytlarının veya platforma özgü hizalamanın yokluğunu garantilemez.
#[repr(C)] struct PacketHeader { flags: u8, length: u16, // Derleyici, bayraklarla değiştiremez }
Bağlam: Yüksek performanslı bir ağ saldırı tespit sistemi geliştirirken, doğrudan mmap edilmiş paket halkası tamponundan Ethernet çerçeve başlıklarını çözümlemem gerekiyordu. Sistem hem x86_64 sunucularını hem de yerleşik ARM64 cihazlarını hedefledi.
Sorun: İlk uygulama, Ethernet başlığını (hedef MAC, kaynak MAC, etiket tipi) temsil etmek için bir repr(Rust) yapısı kullandı. Bu yapıya ham bayt dilimini dönüştürmeye çalışırken, ARM64 üzerinde aralıklı çöküşler meydana geldi ancak x86_64 üzerinde değil; bu, tanımsız bir davranışı gösteriyordu.
Çözüm 1: Naif dönüşüm repr(Rust) ile. Göstergeleri mem::transmute veya std::slice::from_raw_parts ile dönüştürmeyi düşündüm, yapı tanımının ağ formatıyla eşleştiğine dayanarak. Artılar: Sıfır maliyet, kopyalama yok. Eksiler: repr(Rust) derleyicinin ethtype alanını MAC adreslerinden önce yeniden düzenlemesine izin vererek hizalamayı optimize eder; bu, dönüştürülmüş yapının MAC baytlarını etiket türü olarak ve tersini yorumlamasına neden olur. Bu, hemen tanımsız bir davranıştır ve platforma özgüdür.
Çözüm 2: Açık #[repr(C)] etiketi. #[repr(C)] eklemek, derleyicinin beyan sırasını korumasını zorunlu kılar, bu da IEEE 802.3 standart düzenine tam olarak uyar. Artılar: Öngörülebilir ofsetler, FFI ve ham bellek eşlemesi için güvenli. Eksiler: Altoptimal dolgu nedeniyle potansiyel performans kaybı (derleyici alanları boyutu minimize etmek için yeniden düzenleyemez), bu da biraz daha büyük yapılar ve potansiyel önbellek verimsizliğine yol açabilir.
Çözüm 3: Manuel byte ayrıştırma (bytemuck veya manuel dizinleme). bytemuck kütüphanesini Pod özellikleriyle veya baytları u16::from_be_bytes ile manuel olarak dilimleyerek kullanmak. Artılar: Tamamen güvenli, unsafe blokları yok, hizalamayı doğru yönetir. Eksiler: Endianness için bayt değişimi ve alan alanında kopyalamak için çalışma zamanı maliyeti, kodu karmaşıklaştırır.
Seçilen çözüm: Çözüm 2 (#[repr(C)]) ile #[derive(Copy, Clone)] ve 14 baytlık başlık boyutuna tam olarak uyması için isteğe bağlı dolgu alanları eklemeyi seçtim. Küçük önbellek verimsizliği kabul edilebilir olduğundan, NIC sürücüsü zaten paketleri önbellek hatlarına hizalamıştı ve doğruluk güvenlik denetimi için kritik öneme sahipti.
Sonuç: Ayrıştırıcı, x86_64 ve ARM64 üzerinde stabil hale geldi. Sıkı menşei kontrolü için Miri doğrulamasını geçti. Son olarak, herhangi bir çöküş veya veri bozulması olmadan libpcap FFI katmanı ile başarıyla entegre oldu.
Neden açık dolgu alanlarını bir repr(C) yapısına eklemek bazen C koduyla ABI uyumluluğunu değiştirir ve #[repr(C, packed)] bu riski nasıl değiştirir?
Açık dolgu eklemek (örneğin, _: u16) bir C başlığını eşleştirmek için C derleyicisinin aynı hizalama kurallarını kullandığını varsayar. Ancak, Rust ve C bit alanı paketlemesi veya dizilerin hizalanmasında farklılık gösterebilir. #[repr(C, packed)] tüm dolguları kaldırır ve alanların bayt sınırlarına hizalanmasını zorlar. Artılar: Paketlenmiş C yapılarıyla tam olarak eşleşir. Eksiler: Hizalanmamış alan erişimi Rust'ta tanımsız bir davranış haline gelir; derleyici, hizalanmamış okumaları optimize edemez ve bazı mimarilerde (ARM, RISC-V) bu donanım istisnalarını tetikler. Adaylar genellikle packed'ın güvenlik yükünü tamamen programcıya kaydırdığını gözden kaçırırlar.
Bir bool'un geçerlilik şartı repr(Rust) ve repr(C) arasında nasıl farklılık gösterir ve bu, u8'den bool'a dönüştürmeyi nasıl etkiler?
Rust'ın bool'u katı bir geçerlilik şartına sahiptir: 0x00 (yanlış) veya 0x01 (doğru) olmalıdır. C genellikle sıfır olmayan herhangi bir değeri doğru olarak kabul eder. C'den gelen bir u8'i repr(C) yapısı içindeki bool'a dönüştürürken, eğer C kodu baytı 0x02 olarak ayarladıysa, Rust anında tanımsız bir davranışa neden olur; bu durum repr(C) ile bile geçerlidir. repr(Rust) ve repr(C) bool geçerlilik şartını değiştirmez—Rust her zaman 0 veya 1 gerektirir. Adaylar genellikle repr(C)'nin Rust'ın tür şartlarını gevşettiğini varsayar; bu yalnızca düzeni etkiler, geçerliliği değil. Çözüm, yapıda u8 kullanmak ve güvenli kodda != 0 ile dönüştürmektir.
Bir &[u8] dilimini &[ReprCStruct] referansına yasal olarak dönüştürebilir misiniz ve yalnızca boyut dışında hangi hizalama kısıtlamalarının doğrulanması gerekir?
Dilimleri dönüştürmek doğrudan değil; align_to veya gösterici dönüştürmeleri kullanmak gerekir. Kaçırılan kritik kısıtlama hizalamadır: u8 diliminin hizalaması 1 olabilirken, ReprCStruct 4 veya 8 hizalaması gerektirebilir. Alt hizalanmış bir değere referans oluşturmak anında tanımsız bir davranıştır. Adaylar genellikle size_of'u kontrol eder fakat align_of'u unutur. Çözüm, std::slice::from_raw_parts'ı yalnızca ptr.align_offset(std::mem::align_of::<T>()) == 0 doğrulandıktan sonra kullanmaktır veya hizalanmış bir缓冲 bölgesine kopyalamaktır. Miri bu doğrulama ihlal edildiğinde Tanımsız Davranış olarak işaretleyecektir.