64-बिट `time_t` में संक्रमण के जोखिम

64-बिट time_t में संक्रमण के जोखिम

• 32-बिट time_t टाइप के उपयोग के कारण 2038 में 32-बिट एप्लिकेशन में त्रुटियाँ आने की संभावना है
• time_t को 64-बिट टाइप में बदलना समाधान के रूप में प्रस्तावित है
• Musl ने यह संक्रमण पहले ही पूरा कर लिया है, glibc इसे एक विकल्प के रूप में सपोर्ट करता है, और Debian सहित कई डिस्ट्रीब्यूशन यह बदलाव पूरा कर चुके हैं
• Gentoo जैसे source-based डिस्ट्रीब्यूशन के लिए यह संक्रमण कठिन है

Large File Support पर वापस

• 32-बिट आर्किटेक्चर में फ़ाइल ऑफ़सेट बताने वाला off_t और inode नंबर बताने वाला ino_t 32-बिट के रूप में उपयोग होता है
• इसके कारण 2 GiB से बड़ी फ़ाइलें खोली नहीं जा सकतीं, और वे फ़ाइलें भी नहीं खोली जा सकतीं जिनके inode नंबर 32-बिट सीमा से बाहर हों
• Large File Support की शुरुआत से यह समस्या हल हुई, लेकिन glibc में यह अब भी वैकल्पिक है
• time64 सपोर्ट के लिए LFS का उपयोग आवश्यक है

कौन-सा ABI उपयोग किया जाता है?

• तीन संभावित sub-ABI हैं:
  1. 32-बिट टाइप का उपयोग करने वाला मूल ABI
  2. 64-बिट off_t और ino_t, तथा 32-बिट time_t का उपयोग करने वाला LFS
  3. LFS + 64-बिट time_t का उपयोग करने वाला time64
• glibc बिल्ड इन तीनों वेरिएंट के साथ संगत हो सकता है, लेकिन API में इन टाइप्स का उपयोग करने वाली लाइब्रेरी आपस में संगत नहीं होतीं

ABI बदलना खराब क्यों है?

• 32-बिट टाइप को 64-बिट टाइप से बदलना compatibility तोड़ देता है
• struct के मामले में, time_t शामिल होने पर फ़ील्ड की स्थिति बदल सकती है, जिससे गलत फ़ील्ड पढ़ी या लिखी जा सकती है
• function parameters के मामले में, स्टैक पर पास किए गए parameters की स्थिति बदल सकती है, जिससे गलत parameters पढ़े या लिखे जा सकते हैं
• ये समस्याएँ runtime errors और security issues पैदा कर सकती हैं

इसे सुरक्षित कैसे बनाया जा सकता है?

• तीन विचार हैं:
  1. नए ABI को अलग पहचान देने के लिए platform tuple (CHOST) बदलना
  2. नए ABI के लिए libdir बदलना
  3. अलग-अलग sub-ABI उपयोग करने वाले binaries को लिंक होने से रोकने के लिए binary-level ABI distinction लागू करना

platform tuple बदलना

• platform tuple उस प्लेटफ़ॉर्म की पहचान करता है जिसे toolchain target कर रहा होता है
• नए ABI को लाने के लिए vendor field बदलना या libc field में अतिरिक्त ABI specification जोड़ना
• उदाहरण: i686-gentoo_t64-linux-gnu, i686-pc-linux-gnut64

libdir बदलना

• libdir लाइब्रेरी इंस्टॉल डायरेक्टरी का डिफ़ॉल्ट नाम होता है
• time64 वेरिएंट के लिए libdir मान बदलकर नई libdir में time64 लाइब्रेरी इंस्टॉल की जा सकती है
• इससे यह रोका जा सकता है कि time64 executable, time32 लाइब्रेरी से लिंक न हो
• Portage की preserved-libs सुविधा का उपयोग करके मौजूदा लाइब्रेरी को सुरक्षित रखा जा सकता है

binary compatibility सुनिश्चित करना

• अलग-अलग ABI उपयोग करने वाले binaries को मिलाया नहीं जा सकता
• compatibility की जाँच के लिए ELF class, machine identifier, flag fields आदि का उपयोग किया जा सकता है
• time32 और time64 सिस्टम में अंतर करने के लिए नया ELF note section जोड़ने पर विचार किया जा रहा है

पुराने pre-built एप्लिकेशन

• पुराने pre-built एप्लिकेशन को system libraries के साथ compatibility issues और y2k38 समस्या का सामना करना पड़ता है
• multilib layout का उपयोग करके compatibility issues हल किए जा सकते हैं
• y2k38 समस्या को system time में बदलाव करके या VM का उपयोग करके संभाला जा सकता है

GN⁺ का सार

• 2038 के बाद 32-बिट time_t उपयोग करने वाले एप्लिकेशन में त्रुटियाँ आने की संभावना है
• 64-बिट time_t में संक्रमण आवश्यक है, लेकिन इससे ABI परिवर्तन जुड़ता है और जटिल समस्याएँ पैदा होती हैं
• platform tuple बदलकर, libdir बदलकर, और binary compatibility सुनिश्चित करके एक सुरक्षित migration path दिया जा सकता है
• पुराने pre-built एप्लिकेशन के लिए अलग compatibility issues और y2k38 समस्या का समाधान करना होगा

[GN⁺]

Hacker News राय

• Gentoo में पैकेज इंस्टॉल किए बिना build करने के विकल्प कम हैं

  • Gentoo में पैकेज build और install एक ही चरण में होते हैं
  • ABI बदलने पर update के दौरान सिस्टम आसानी से टूट सकता है
  • 64-bit time_t समस्या व्यापक रूप से ज्ञात ABI बदलाव का एक उदाहरण है

• .so versioning के ज़रिए ABI बदलावों को संभालने का तरीका

  • .so फ़ाइलों में version number शामिल होता है
  • पैकेज खुद अंदरूनी तौर पर version number मैनेज करता है
  • 64-bit time_t को support करने के लिए inherited ABI को नियंत्रित कर सकने वाले अतिरिक्त components की ज़रूरत होती है

• Mac OS X में off_t और ino_t को संभालने का तरीका

  • मौजूदा calls और structs वैसे ही रखे गए
  • नए calls और types में 64 suffix जोड़ा गया
  • build के समय यह तय किया जा सकता है कि compiled binary किस न्यूनतम OS version पर चलेगी

• Debian को 64-bit time_t में transition करने में कठिनाई हुई

  • source-based distributions को इससे भी कठिन transition process से गुज़रना पड़ता है

• 32-bit Unix systems में time_t को unsigned 32-bit से बदलने का अनुभव

  • इससे 2038 के बाद 68 साल और उपयोग संभव हुआ
  • Unix epoch से पहले की तारीखों को व्यक्त नहीं किया जा सकता

• FreeBSD में amd64 port के दौरान 64-bit time_t अपनाने का अनुभव

  • 32-bit function arguments अपने-आप 64-bit में convert हो गए
  • शुरुआत से 64-bit time_t इस्तेमाल करके समस्या से बचा गया
  • tzcode 64-bit safe नहीं था, इसलिए कुछ समस्याएँ आईं

• BSD manual page के "Bugs" section में एक मज़ाक

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

• source-based distributions की जगह Debian जैसी non-source-based distribution पर जाना चाहने की राय

• 32-bit time_t और 64-bit time_t में struct offset का अंतर

  • 64-bit type में b को 64-bit alignment चाहिए, इसलिए padding जुड़ती है

• यह सोचा गया था कि C में type aliases बाद में बदले जा सकेंगे, लेकिन व्यवहार में ऐसा नहीं है

• इस समस्या को जल्दी सुलझा लेना बेहतर है

  • OpenBSD सभी architectures पर 64-bit time_t का उपयोग करता है