Risiko transisi ke `time_t` 64-bit

Risiko transisi ke time_t 64-bit

• Penggunaan tipe time_t 32-bit dapat menyebabkan aplikasi 32-bit mengalami kesalahan pada tahun 2038
• Mengubah time_t menjadi tipe 64-bit diajukan sebagai solusi
• Musl sudah menyelesaikan transisi, glibc mendukungnya sebagai opsi, dan beberapa distribusi seperti Debian juga telah menyelesaikan transisi
• Distribusi berbasis source seperti Gentoo lebih sulit melakukan transisi

Kembali ke Large File Support

• Arsitektur 32-bit menggunakan off_t untuk menentukan offset file dan ino_t untuk menentukan nomor inode, keduanya dalam 32-bit
• Akibatnya, file yang lebih besar dari 2 GiB tidak dapat dibuka, dan file dengan nomor inode yang melebihi rentang 32-bit juga tidak dapat dibuka
• Masalah ini diselesaikan dengan diperkenalkannya Large File Support, dan di glibc hal ini masih bersifat opsional
• Penggunaan LFS diperlukan untuk dukungan time64

ABI mana yang digunakan?

• Ada tiga sub-ABI yang memungkinkan:
  1. ABI asli yang menggunakan tipe 32-bit
  2. LFS yang menggunakan off_t dan ino_t 64-bit, serta time_t 32-bit
  3. time64 yang menggunakan LFS + time_t 64-bit
• Build glibc dapat kompatibel dengan ketiga varian tersebut, tetapi library yang menggunakan tipe-tipe ini dalam API tidak kompatibel satu sama lain

Mengapa perubahan ABI itu buruk?

• Mengganti tipe 32-bit dengan tipe 64-bit akan merusak kompatibilitas
• Dalam kasus struct, struct yang berisi time_t akan mengalami perubahan posisi field sehingga field yang salah bisa dibaca atau ditulis
• Dalam kasus parameter fungsi, posisi parameter yang diteruskan di stack berubah sehingga parameter yang salah bisa dibaca atau ditulis
• Masalah-masalah ini dapat menyebabkan error saat runtime dan persoalan keamanan

Bagaimana membuatnya aman?

• Ada tiga ide:
  1. Mengubah platform tuple (CHOST) untuk membedakan ABI baru
  2. Mengubah libdir untuk ABI baru
  3. Memperkenalkan pembedaan ABI pada level biner agar biner dengan sub-ABI berbeda tidak saling terhubung

Perubahan platform tuple

• Platform tuple mengidentifikasi platform yang ditargetkan oleh toolchain
• Untuk memperkenalkan ABI baru, field vendor dapat diubah atau spesifikasi ABI tambahan dapat ditambahkan ke field libc
• Contoh: i686-gentoo_t64-linux-gnu, i686-pc-linux-gnut64

Perubahan libdir

• libdir adalah nama default direktori instalasi library
• Untuk varian time64, nilai libdir diubah agar library time64 dipasang ke libdir baru
• Ini mencegah executable time64 menautkan library time32
• Fitur preserved-libs milik Portage dapat digunakan untuk mempertahankan library lama

Menjamin kompatibilitas biner

• Biner yang menggunakan ABI berbeda tidak bisa dicampur
• Kelas ELF, pengenal mesin, field flag, dan sebagainya dapat digunakan untuk memeriksa kompatibilitas
• Penambahan section note ELF baru sedang dipertimbangkan untuk membedakan sistem time32 dan time64

Aplikasi prebuilt lama

• Aplikasi prebuilt lama menghadapi masalah kompatibilitas dengan library sistem serta masalah y2k38
• Masalah kompatibilitas dapat diatasi dengan menggunakan tata letak multilib
• Masalah y2k38 dapat diatasi dengan memanipulasi waktu sistem atau menggunakan VM

Ringkasan GN⁺

• Setelah tahun 2038, aplikasi yang menggunakan time_t 32-bit berpotensi mengalami kesalahan
• Transisi ke time_t 64-bit diperlukan, tetapi ini melibatkan perubahan ABI yang menimbulkan masalah kompleks
• Jalur transisi yang aman dapat disediakan melalui perubahan platform tuple, perubahan libdir, dan jaminan kompatibilitas biner
• Aplikasi prebuilt lama perlu menangani masalah kompatibilitas tersendiri dan masalah y2k38

[GN⁺]

Komentar Hacker News

• Gentoo kurang memiliki opsi untuk membangun tanpa memasang paket

  • Di Gentoo, proses build dan instalasi paket terjadi dalam satu langkah
  • Saat ada perubahan ABI, sistem bisa mudah rusak selama pembaruan
  • Masalah time_t 64-bit adalah contoh perubahan ABI yang sudah dikenal luas

• Cara menangani perubahan ABI melalui pengelolaan versi .so

  • File .so menyertakan nomor versi
  • Paket itu sendiri mengelola nomor versi secara internal
  • Untuk mendukung time_t 64-bit, diperlukan komponen tambahan yang dapat mengendalikan ABI turunan

• Cara Mac OS X menangani off_t dan ino_t

  • Pemanggilan dan struktur lama tetap dipertahankan
  • Akhiran 64 ditambahkan ke pemanggilan dan tipe baru
  • Saat build, bisa ditentukan versi OS minimum tempat biner hasil kompilasi akan dijalankan

• Debian mengalami kesulitan saat beralih ke time_t 64-bit

  • Distribusi berbasis source mengalami proses transisi yang lebih sulit

• Pengalaman mengganti time_t di sistem Unix 32-bit dengan unsigned 32-bit

  • Sistem bisa dipakai 68 tahun lebih lama setelah 2038
  • Tanggal sebelum Unix epoch tidak bisa direpresentasikan

• Pengalaman memperkenalkan time_t 64-bit saat melakukan port amd64 di FreeBSD

  • Argumen fungsi 32-bit otomatis dikonversi ke 64-bit
  • Masalah dapat dihindari dengan memakai time_t 64-bit sejak awal
  • Ada beberapa kendala karena tzcode tidak aman untuk 64-bit

• Lelucon di bagian "Bugs" pada halaman manual BSD

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

• Ada pendapat ingin beralih dari distribusi berbasis source ke distribusi non-source seperti Debian

• Perbedaan offset struktur antara time_t 32-bit dan time_t 64-bit

  • Pada tipe 64-bit, b memerlukan alignment 64-bit sehingga padding ditambahkan

• Dulu sempat mengira alias tipe di C memungkinkan perubahan di kemudian hari, tetapi ternyata tidak demikian

• Ada pendapat bahwa masalah ini sebaiknya diselesaikan secepat mungkin

  • OpenBSD menggunakan time_t 64-bit di semua arsitektur