2.9.2013 01:16
Josef Kufner | skóre: 70
Rozbalit Rozbalit vše Re: Jaderné noviny – 15. 8. 2013: Y2038 na obzoru
Portál AbcLinuxu, 7. května 2025 20:18
Aktuální verze jádra: 3.11-rc5. Citáty týdne: Jean-Baptiste Quéru, Systém souborů π, James Bottomley, Dave Jones. Siemon: Fronty v linuxové síťové vrstvě. Úvahy o roku 2038.
Aktuální vývojová verze jádra je 3.11-rc5 vydaná 11. srpna. Linus k ní řekl: S numerologií nám to bohužel nevychází, vydání konečné verze 3.11 právě dnes by byla krásná náhoda (Windows 3.11 byly vydány právě před 20 lety), ale nebude tomu tak. Místo toho máme 3.11-rc5. Kromě obvyklých oprav tento patch obsahuje změnu oprávnění linkat(), o které jsme psali minule.
Stabilní aktualizace: verze 3.10.6, 3.4.57 a 3.0.90 vyšly 11. srpna.
Verze 3.10.7, 3.4.58 a 3.0.91 se aktuálně revidují; jejch vydání lze očekávat 15. srpna nebo později.
Všechny firmy dříve či později skončí v nenávistné pozornosti světa open source, ne vždy oprávněně. Za posledních několik let jsem už několikrát cítil, jak se proti mě pozornost takto obrací, takže vím až moc dobře, jaké to je být nenáviděný lidmi, kterým se snažíš pomoci.
Jendou z předpokládaných vlastností π je to, že je to normální číslo, což znamená, že jeho číslice jsou rovnoměrně rozprostřena s tím důsledkem, že jde o disjunktní sekvenci, takže všechny možné konečně posloupnosti čísel jsou v něm někde přítomny. Pokud se na π podíváme v šestnáctkové soustavě (hexadecimálně), pak je jasné, že pokud je předchozí tvrzení pravdivé, pak v π musí existovat všechny konečné soubory. První záznam o tomto zjištění je z roku 2001.
Odtud už je jen malý krůček k myšlence, že pokud π obsahuje všechny možné soubory, tak proč mrháme exabajty úložného prostoru k uložení těchto souborů, když je můžeme jednoduše dohledat v π!
Vypadá to, že jsme se dostali do stádia, kdy „bezpečnost“ je jakýmsi kouzelným slůvkem, jak se dá vyhnout jakémukoliv řádnému postupu (začíná se to používat podobně jako fráze „válka proti terorismu“, pomocí které se obchází řádný postup vyžadovaný americkou ústavou).
Děsí mě, že na seznamu adres s přístupem k databázi coverity je skoro stejně tolik lidí jako Lockheed Martin, Raytheon Missile nebo různé vládní orgány různých zemí, jako lidí, co v minulosti někdy něčím do jádra přispěli. (Je to ještě více pokřivené, pokud započítáte další nepřispívající firmy jako výrobce antivirů.)
Vzniklo tu celé odvětví postavené na kupování/prodeji zranitelností a naší reakcí je vlastně jen „no jo, nějak to vyřešíme, až se objeví exploit“.
-- Dave Jones
Dan Siemon poslal detailní přehled, jak síťová vrstva Linuxu řadí pakety do fronty. Od Linuxu 3.6.0 (2012-09-30) má Linux novou funkci zvanou Malé fronty TCP, které se snaží tento problém řešit pro TCP. Malé fronty TCP přidávají omezení na počet bajtů, které mohou čekat ve frontě QDiscu a ovladače. To má zajímavý vedlejší účinek v podobě dřívějšího dopadu na aplikace, což aplikacím umožňuje efektivnější prioritizaci zápisů do soketu.
Mnoho čtenářů si jistě pamatuje na problém roku 2000, který byl zapříčiněn rozšířeným používáním dvou dekadických číslic pro uložení letopočtu. Tento problém byl zajisté hodně zveličovaný, ale šílenství okolo jeho opravy nebylo úplně zbytečné; řada systémů by se zajisté chovala špatně, kdyby všichni ti programátoři v COBOLu v důchodu nenapochodovali zpátky do práce, aby to opravili. Problém částečně spočíval i v tom, že vlastníci dotčených systémů s opravou otáleli, i když byl problém snadno převidatelný a už dlouho dopředu se o něm vědělo. Člověk by doufal, že se ve světě open source obdobně předvídatelný problém nebude opakovat.
To se ale máme příležitost dozvědět, protože právě jeden takový problém se rýsuje na horizontu. Klasické vyjádření unixového času je pomocí znaménkového 32bitového čísla, jež obsahuje počet sekund od 1. ledna 1970. Tato hodnota přeteče 19. ledna 2038, tedy za méně než 25 let. Člověk by si řekl, že opravu nemusíme uspěchat a měl by možná i pravdu. Ale vzhledem k dlouhé životnosti mnoha instalovaných systémů, včetně obtížně aktualizovatelných embedded systémů, nám možná zbývá méně času, než bychom tipovali.
Je proto zajímavé poukázat na to, že 12. srpna vývojář OpenBSD Philip Guenther zařadil do OpenBSD patch, který mění většinu hodnot obsahujících čas na 64 bitů. S 64 bity máme více než dost místa pro ukládání časových hodnot daleko za dohlednou budoucnost, i kdyby se použily hodnoty s vysokým rozlišením (v nanosekundách). Jakmile se vyřeší nedostatky, pak bude OpenBSD mít problém 2038 snad za sebou; dalo by se říci, že v tomto ohledu Linux předehnali. A snad by to i byla pravda, kdyby nebyly dobré důvody, proč se na Linuxu k tomuto problému přistupuje opatrně.
Patch v OpenBSD mění typy jako time_t a clock_t na 64bitové hodnoty. Takové změny se hned projevují na dalších místech; například standardní typy jako struct timeval a struct timespec obsahují pole time_t, takže i tyto struktury se změní. struct stat předávané systémovému volání stat() také obsahuje řadu hodnot time_t. Jinými slovy změny provedené v OpenBSD představují jednu obrovskou, nekompatibilní změnu v ABI. To má za následek to, že jádra OpenBSD s touto změnou obecně nebudou moci spouštět binárky vytvořené před zavedením změn; každý, kdo aktualizuje, by tak tedy měl činit s velkou dávkou opatrnosti.
OpenBSD si to může dovolit, protože je to ucelený systém s jaderným a uživatelským prostorem sestavovaným z jediného repozitáře. O uživatele s binárkami odjinud si nedělají obavy; očekává se, že zaktualizují celý systém a překompilují binárky. Proto se vývojáři OpenBSD tak neostýchají rozbít jaderné ABI jako vývojáři Linuxu. Philip rovnou zvětšil i ino_t (používané k vyjádření čísel inodů), i když se to k problému roku 2038 nevztahuje. Dokud uživatelé testující tento kód budou dodržovat doporučení a použijí úplný snapshot, vše bude nadále fungovat. Uživatelé aktualizující již nainstalovaný systém budou muset být opatrnější.
Ve světě Linuxu není možné přetáhnout uživatelský prostor do jádra, takže nejde podobně provádět změny v ABI. To notně komplikuje řešení celého problému – což je další důvod, proč se to musí řešit s předstihem. Ne všech systémů se ale problém dotýká. Obecně platí, že uživatelé 64bitových systémů nebudou v roce 2038 mít problémy, protože 64bitové hodnoty už jsou na těchto systémech použity. 32bitové x32 ABI bylo rovněž navrženo s 64bitovými hodnotami pro čas. Proto už o řadu uživatelů Linuxu bylo postaráno.
Uživatelé čistě 32bitového ABI ale problémy mít budou. Je tu samozřejmě možnost, že za 25 let už žádné 32bitové systémy nebudou, ale musíme se poučit z historie. I s omezeními adresace (32bitový procesor s funkcí PAE bude jen stěží pracovat s 16 GB paměti, které budou možná jen tak tak stačit na „hello world“ v roce 2038) může 32bitový systém stále dělat užitečné věci. V roce 2038 může stále běžet mnoho 32bitových embedded systémů, které byly nasazeny dlouho předtím. V roce 2038 určitě budou běžet 32bitové systémy, kterou budou muset správně fungovat.
Během krátké debaty, jež proběhla v červnu, Thomas Gleixner popsal možné řešení:
Pokud opravdu chceme přežít rok 2038, tak se musíme kompletně zbavit vyjádření času v jádře na bázi timespec a přejít na novou skalární 64bitovou hodnotu v nanosekundách. [...]
Ale i pokud toto opravíme, budeme se muset zamyslet nad rozhraními pro uživatelský prostor, která používají timespec/timeval. To bude zajímavější.
Jinými slovy, když už se musí dělat nové ABI, tak dává smysl se zbavit hodnot jako timespec (které dělí čas na dvě pole, sekundy a nanosekundy) a použít prostý počet nanosekund. Software by tak mohl v klidu přejít na nová systémová volání. Thomas navrhl ponechat původní systémová volání beze změny po dobu pěti let, takže by původní operace byly přímo implementovány jádrem; to by umožnilo nezměněnému kódu nadále fungovat bez dopadu na výkon. Poté by byl původní kód nahrazen obalením nových systémových volání, což může trochu zpomalit emulovaná volání a popohnat vývojáře k tomu, aby zaktualizovali svůj kód. Pak, asi po deseti letech, by stará systémová volání byla označena za zastaralá.
Odstranění těchto systémových volání by ale mohla být docela výzva; i Thomas navrhl je ponechat po dobu 100 let, aby se Linus nenaštval. Pokud mají systémová volání být zachována až do roku 2038 (a i potom), bude se muset vymyslet, jak mají vlastně fungovat. John Stultz měl zajímavý návrh: udělat z time_t bezznaménkovou hodnotu, čímž přicházíme o možnost vyjadřovat hodnoty před rokem 1970, ale dá nám to trochu času navíc. Má to ale své vlastní problémy, některý software by se jistě porouchal, ale beze změny se všechen software používající 32bitové hodnoty time_t v roce 2038 rozbije. Proto může tato úprava stát za zvážení.
I bez ohledu na staré aplikace bude řešení problému roku 2038 na 32bitovém Linuxu značnou výzvou. Omezení ABI tuto práci ještě více komplikují. Vzhledem k tomu, že některé části každé migrace nejde zkrátka uspěchat, a tomu, že již nasazené systémy poběží po mnoho let, dává smysl se problémem zabývat už teď. Pak si snad všichni budeme moci užít důchodového věku a neřešit dlouho předvídaný nepořádek s time_t.
2.9.2013 01:16
Josef Kufner | skóre: 70
.
). Možných kombinací obsahů souborů je nekonečně mnoho a mají rovnoměrné rozložení, tj. jsou také statisticky náhodné (pokud by nebyly, sbohem steganografie). Takže zapsat offset na náhodnou pozici v π zabere průměrně stejné množství dat jako ta samotná data, která tak ukládáme.
Mimochodem jde o stejný problém, proč komprimační algoritmy nemohou fungovat na všechny soubory a naopak u některých souborů způsobí zvětšení (opět to statisticky konverguje k tomu, že komprimovaná data budou stejně velká jako originální data, prostě ta entropie musí zůstat; důkaz viz †). Na malém množství podobných dat komprimační algoritmy fungují. Jenže fungují díky tomu, že hledají nadbytečná (neetropní) data, která ale určitě nejsou statisticky náhodná. U π, které je statisticky náhodné, budete mít i u těchto souborů stejnou pravděpodobnost, že zápis offsetu do π bude větší než samotná data, jako pravděpodobnost, že bude menší. Statisticky to opět bude konvergovat k tomu, že offsety budou stejně velká jako samotná data. Průměrně tedy místo neušetříte, ale ani neztratíte.
† důkaz, že komprimovaná data statisticky konvergují na stejnou délku jako původní data (on se totiž týká i toho π):
Do k bitů lze uložit 2ᵏ hodnot. Mějme tedy 2ᵏ různých souborů (poznámka: souborem rozumím libovolnou sekvenci dat) a zkusme je zkomprimovat. Komprimací rozumíme zachování nebo zmenšení velikosti souboru. Menších souborů je ale jen 2ᵏ⁻¹, tedy některé soubory zůstanou stejně velké. Teď budeme komprimovat 2ᵏ⁻¹ různých souborů obsahujících k-1 bitů a tak dále. Nakonec zkusíme komprimovat soubory s nula bity. Takový je právě jeden a nejde zmenšit. Tím pádem ale nejde zmenšit ani soubory o jednom bitu, protože by ty zmenšené nebylo možné odlišit od souboru s nula bity. A tak dále až po k. Tedy po úspěšné kompresi budou všechny soubory stejně velké.
2.9.2013 05:43
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Tato hodnota přeteče 19. června 2038Na mém systému je to už o něco dřív. Že on mě Intel zase ošidil o setinu bitu?!
2.9.2013 10:50
Michy | skóre: 11
| Praha
date -d "@$((2*1024*1024*1024-1))" Út led 19 04:14:07 CET 2038Že by záměna anglického Jan/Jun?
2.9.2013 14:31
David Watzke | skóre: 74
| blog: Blog...
| Praha
3.9.2013 10:19
Conscript89
| Brno
On se hlavně ten problém objeví už ve chvíli, kdy bude někdo chtít vyjádřit čas za touto hranicí – ne až po tom, co tuto hranici překročí reálný čas. Jde o různé předplatné, pronájmy nebo události naplánované do budoucna… jasně většinou se to týká aplikačního softwaru a tam se můžou používat jiné datové typy. Ale obecně mi přijde zavádějící psát, že problém roku 2038 se nás týká až za 25 let.
Changes between 0.9.8n and 1.0.0 [29 Mar 2010] New function OPENSSL_gmtime_adj() to add a specific number of days and seconds to a tm structure directly, instead of going through OS specific date routines. This avoids any issues with OS routines such as the year 2038 bug. New *_adj() functions for ASN1 time structures and X509_time_adj_ex() to cover the extended range. The existing X509_time_adj() is still usable and will no longer have any date issues. [Steve Henson]
Jendou z vlastností π je to, že je to normální číslo, což znamená, že jeho číslice jsou rovnoměrně rozprostřenaV článku i jiných zdrojích je, že jde jen o domněnku! Ale popisu toho fs je, že se se vyhledávají jednotlivé byty, takže to ani není potřeba.
2.9.2013 13:47
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
10.9.2013 20:21