64 bit `time_t` geçişinin riskleri

64 bit time_t'a geçişin riskleri

• 32 bit time_t türünün kullanılması nedeniyle 2038 yılında 32 bit uygulamaların hata üretme olasılığı bulunuyor
• Çözüm olarak time_t'nin 64 bit bir türe dönüştürülmesi öneriliyor
• Musl geçişi zaten tamamladı, glibc bunu bir seçenek olarak destekliyor, Debian dahil çeşitli dağıtımlar da geçişi tamamladı
• Gentoo gibi kaynak tabanlı dağıtımlarda geçiş daha zor

Large File Support'a dönüş

• 32 bit mimariler, dosya ofsetini belirleyen off_t ve inode numarasını belirleyen ino_t türlerini 32 bit olarak kullanıyor
• Bu nedenle 2 GiB'tan büyük dosyalar açılamıyor ve inode numarası 32 bit aralığını aşan dosyalar da açılamıyor
• Large File Support'un kullanıma sunulmasıyla bu sorun çözüldü; glibc'de ise bu hâlâ isteğe bağlı
• time64 desteği için LFS kullanılması gerekiyor

Hangi ABI kullanılıyor?

• Olası üç alt ABI bulunuyor:
  1. 32 bit türleri kullanan özgün ABI
  2. 64 bit off_t ve ino_t, 32 bit time_t kullanan LFS
  3. LFS + 64 bit time_t kullanan time64
• glibc derlemeleri bu üç varyantla da uyumlu olabilir, ancak API'sinde bu türleri kullanan kütüphaneler uyumlu değildir

ABI değişikliği neden kötü?

• 32 bit türleri 64 bit türlerle değiştirmek uyumluluğu bozar
• Yapılar söz konusu olduğunda, time_t içeren yapılarda alan konumları değişir ve yanlış alanların okunmasına ya da yazılmasına yol açabilir
• Fonksiyon parametrelerinde ise yığına aktarılan parametrelerin konumu değişir ve yanlış parametrelerin okunmasına ya da yazılmasına neden olabilir
• Bu sorunlar çalışma zamanı hatalarına ve güvenlik problemlerine yol açabilir

Bu nasıl güvenli hâle getirilebilir?

• Üç fikir öne çıkıyor:
  1. Yeni ABI'yi ayırt etmek için platform üçlüsünü (CHOST) değiştirmek
  2. Yeni ABI için libdir'i değiştirmek
  3. Farklı alt ABI kullanan ikililerin bağlanmasını önlemek için ikili düzeyde ABI ayrımı getirmek

Platform üçlüsünü değiştirmek

• Platform üçlüsü, araç zincirinin hedeflediği platformu tanımlar
• Yeni bir ABI sunmak için vendor alanı değiştirilebilir veya libc alanına ek ABI belirtimi eklenebilir
• Örnek: i686-gentoo_t64-linux-gnu, i686-pc-linux-gnut64

libdir değiştirmek

• libdir, kütüphane kurulum dizininin varsayılan adıdır
• time64 varyantı için libdir değeri değiştirilerek time64 kütüphaneleri yeni bir libdir altına kurulabilir
• Bu sayede time64 çalıştırılabilir dosyalarının time32 kütüphanelerine bağlanması önlenir
• Portage'ın preserved-libs özelliği kullanılarak mevcut kütüphaneler korunabilir

İkili uyumluluğun sağlanması

• Farklı ABI kullanan ikililer karıştırılamaz
• ELF sınıfı, makine tanımlayıcısı, bayrak alanı vb. kullanılarak uyumluluk denetlenebilir
• time32 ve time64 sistemlerini ayırt etmek için yeni bir ELF note bölümü eklenmesi değerlendiriliyor

Eski önceden derlenmiş uygulamalar

• Eski önceden derlenmiş uygulamalar, sistem kütüphaneleriyle uyumluluk sorunları ve y2k38 problemiyle karşı karşıya
• Multilib düzeni kullanılarak uyumluluk sorunları çözülebilir
• y2k38 problemi ise sistem saatini değiştirerek veya VM kullanarak aşılabilir

GN⁺ özeti

• 2038 sonrasında 32 bit time_t kullanan uygulamaların hata üretme olasılığı bulunuyor
• 64 bit time_t'a geçiş gerekiyor, ancak bu ABI değişikliği içerdiği için karmaşık sorunlar doğuruyor
• Platform üçlüsünü değiştirme, libdir değiştirme ve ikili uyumluluğu garanti altına alma yoluyla güvenli bir geçiş yolu sağlanabilir
• Eski önceden derlenmiş uygulamalar için ayrı uyumluluk sorunları ve y2k38 probleminin de çözülmesi gerekiyor

[GN⁺]

Hacker News görüşleri

• Gentoo'da paketleri kurmadan derlemek için yeterli seçenek yok

  • Gentoo'da paket derleme ve kurulum tek adımda gerçekleşiyor
  • ABI değişikliklerinde güncelleme sırasında sistem kolayca bozulabiliyor
  • 64 bit time_t sorunu, yaygın olarak bilinen bir ABI değişikliği örneği

• ABI değişikliklerini .so sürüm yönetimiyle ele alma yöntemi

  • .so dosyaları sürüm numarası içeriyor
  • Paketin kendisi dahili olarak sürüm numarasını yönetiyor
  • 64 bit time_t desteği için devralınmış ABI'yi kontrol edebilen ek bileşenler gerekiyor

• Mac OS X'te off_t ve ino_t'nin ele alınış biçimi

  • Mevcut çağrılar ve yapılar aynı kaldı
  • Yeni çağrılara ve tiplere 64 son eki eklendi
  • Derleme sırasında, derlenen ikilinin çalışacağı en düşük OS sürümü belirtilebiliyor

• Debian, 64 bit time_t'ye geçişte zorluk yaşadı

  • Kaynak tabanlı dağıtımlar daha da zor bir geçiş süreci yaşıyor

• 32 bit Unix sistemlerde time_t'yi unsigned 32 bit ile değiştirme deneyimi

  • 2038'den sonra 68 yıl daha kullanılabilmesini sağladı
  • Unix epoch öncesindeki tarihleri temsil edemiyor

• FreeBSD'de amd64 portu yapılırken 64 bit time_t'yi kullanıma alma deneyimi

  • 32 bit fonksiyon argümanları otomatik olarak 64 bite dönüştürüldü
  • En baştan 64 bit time_t kullanılarak sorunlardan kaçınıldı
  • tzcode 64 bit açısından güvenli olmadığından bazı sorunlar yaşandı

• BSD kılavuz sayfalarındaki "Bugs" bölümünde yer alan şaka

  • "You can tune a file system, but you can't tune a fish."

• Kaynak tabanlı dağıtımlar yerine Debian gibi kaynak tabanlı olmayan bir dağıtıma geçmek istediğini söyleyen bir görüş

• 32 bit time_t ile 64 bit time_t arasındaki struct ofset farkı

  • 64 bit tiplerde b için 64 bit hizalama gerektiğinden padding ekleniyor

• C'de type alias kullanımının bir tipin daha sonra değiştirilebilmesine imkân verdiği düşünülüyordu, ancak pratikte durum böyle değil

• Sorunu hızlı çözmenin daha iyi olduğu görüşü

  • OpenBSD tüm mimarilerde 64 bit time_t kullanıyor