Jaderné noviny – 15. 8. 2013: Y2038 na obzoru

2. 9. 2013 | Luboš Doležel | Jaderné noviny | 5144×

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.

Obsah

• 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í verze jádra: 3.11-rc5

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.

Citáty týdne: Jean-Baptiste Quéru, Systém souborů π, James Bottomley, Dave Jones

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.

-- Jean-Baptiste Quéru

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 π!

-- Systém souborů π

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).

-- James Bottomley

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

Siemon: Fronty v linuxové síťové vrstvě

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.

Úvahy o roku 2038

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.

       

Komentáře

[Josef Kufner]

Navrhuju zavést pie:// URI schéma, které bude adresovat polohu dat v π.

[pc2005]

ad Pí: No nevím, nepřipadá mě to jako dobrý nápad .

[ertwertwe]

autor pifs to samozrejme myslel jako vtip a proof of concept. cituji web: "proc skladovat stare normalni data, kdyz muzeme skladovat hafo metadat"

[jehovista]

No pak bysme si asi museli ukladat polohu v tom pi. A u netrivialniho souboru bych rekl, ze zapis te pozice bude delsi, nez samotny soubor.

[Sten]

Nebude. π je disjunktní a tedy statisticky bude zápis pozice průměrně přesně stejně dlouhý jako samotný soubor

[jehovista]

To recitujes poucku, nebo se to da i dokazat tak, aby to pochopil prumerny ctenar abicka?

[Sten]

π má statisticky náhodné rozložení číslic. To znamená, že v něm lze nalézt jakoukoliv sekvenci a že se stoupajícím počtem hledaných sekvencí bude průměrné místo nálezu hledané sekvence v půlce (jde o půlku nekonečně dlouhého čísla ). 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é.

[ebik]

Věří se, že pí má rovnoměrně rozložené číslice. Nikdo to nedokázal. Nedokázal ani, že pí je disjunktní číslo pro alespoň nějakou soustavu a opravdu obsahuje všechny konečné sekvence zapsané v té soustavě. Samozřejmě není ani důkaz, že tomu tak není.

[walkeer_CZ]

no, vzkledem k tomu, ze pi je transcendentni, tak je to mozna docela opravena vira, nebo jsem mimo?

[xyz]

Samo osebe to nestačí. Napríklad číslo \sum_{n=1}^\infty 10^{-n!} je transcendentné a pritom má má v zápise v desiatkovej sústave len jednotky (na "faktoriálových pozíciách") a nuly (všade inde).

[Sten]

To nestačí, ale všechny známé číslice jsou (alespoň zatím) statisticky náhodné

[jehovista]

Na jake hladine vyznamnosti? XD

[Michal Kubeček]

Ono i v případě, že je rozložení číslic opravdu náhodné, tak to není žádná výhra, protože by to sice na jedné straně znamenalo, že pro každou sekvenci pravděpodobnost, že se vyskytne v prvních n číslech zápisu, konverguje k nule, ale na druhé straně také to, že pro libovolné n existuje sekvence, pro niž platí, že zápis pozice jejího prvního výskytu bude aspoň n-krát delší než sekvence sama.

[Jendа]

Tato hodnota přeteče 19. června 2038

Na mém systému je to už o něco dřív. Že on mě Intel zase ošidil o setinu bitu?!

[Michy]

Ať dělám, co dělám, vychází mi přetečení na 19.1.2038.

date -d "@$((2*1024*1024*1024-1))"
Út led 19 04:14:07 CET 2038

Že by záměna anglického Jan/Jun?

[Sten]

Má to být 19. ledna 2038 (či 18. ledna pro ty, kteří žijí na západ od Labradoru)

[SGF]

A hergot, labradora má soused a my máme byt západně od něj...

[David Watzke]

Dík, opraveno

[Conscript89]

Ale v titulku clanku je porad srpen :)

[xkucf03]

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.

[Michal Kubeček]

Osobně mne spíš překvapuje, že mnohem dříve nebyly komplikace s problémem roku 1901…

[Lol Phirae]

Tak tohle je z roku 2010, a skutečně to několik lidí reportovalo (asi je stejně jako mě nebaví furt obnovovat certifikáty.)

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]

[jc]

IMHO se tady projevuje jedna z nevyhod soucasneho vyvoje linux kernelu. Kdyby byl nejaky "opravdu vyvojovy" strom jako puvodne, nemuseli by se bat rozbit ABI. Uzivatele / vyvojari software by pak vedeli, co je/bude treba k tomu, aby to fungovalo i s novou hlavni verzi.

[trekker.dk]

Rozbít ABI nebylo povolené nikdy.

[mankind_boost]

Základním pravidlem vývoje Linuxu je NIKDY NEROZBÍT KOMPATIBILITU USERSPACE. Kvůli tomu je v Linuxu naprosto neskutečné množství různých hacků a obežliček.

[Aleš Kapica]

Dokonce tolik, že se někdy něo rozbije, aniž by o tom vůbec někdo něco tušil..

[Sten]

Jak by mohl být nějaký „opravdový“ vývojový strom pro věci jako KDE či GNOME? Navíc ani samotný kernel už nemá „opravdový“ vývojový strom, používá distribuovaný Git. „Opravdový“ vývojový strom lze používat akorát u „hobby systémů“ jako OpenBSD.

[R]

Problem toho "skutocne vyvojoveho" stromu bol ten, ze skutocny vyvoj sa dial iba tam a stabilne verzie boli silne zastarane. Pritom boli vo vyvojovych jadrach nebezpecne bugy (sposobujuce poskodenie filesystemu a pod.).

Sucasny vyvojovy model (s gitom) je podstatne lepsi - nove veci sa k pouzivatelom dostanu podstatne rychlejsie. To je kvoli driverom doslova nutnost.

[VD]

Jendou z vlastností π je to, že je to normální číslo, což znamená, že jeho číslice jsou rovnoměrně rozprostřena

V č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.

[Luboš Doležel (Doli)]

Opraveno.

[x14]

opraveno?

JEDNOU z předpokládaných vlastností π je to, že je to normální číslo, což znamená, že jeho číslice jsou rovnoměrně ROZPROSTŘENY 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... atd...

[x14]

převidatelný -> převídatelný, provedné -> provedené

a to už je snad všechno

[Petr]

"navrhl je ponechat po dobu 100 let, aby se Linus nenaštval" - za 100 let se Linus už opravdu nebude schopen naštvat

[Roslav]

"Linus večne živý." a "S GNU/Linux na večné časy a nikdy inak!"

[bohyn]

Doufam ze Linux vydrzi dyl nez na vecny casy :)

[Honz]

Je v Ječný...