Jaderné noviny - 12. 3. 2008

12. 5. 2008 | Jirka Bourek | Jaderné noviny | 2970×

Aktuální verze jádra: 2.6.25-rc5. Citáty týdne: Andrew Morton, Richard Stallman. Lepší alokátor DMA paměti. Jak použít terabyte RAM. GCC 4.3.0 odhaluje chybu v jádře.

Obsah

• Aktuální verze jádra: 2.6.25-rc5
• Citáty týdne: Andrew Morton, Richard Stallman
• Lepší alokátor DMA paměti
• Jak použít terabyte RAM
• GCC 4.3.0 odhaluje chybu v jádře

Aktuální verze jádra: 2.6.25-rc5

Aktuální vývojové jádro je 2.6.25-rc5, vydané 9. března. Linus řekl: Velikost -rc patchů se konečně začíná zmenšovat, ale stále máme příliš mnoho vyčnívajících hlášení o regresích. Zkrácený changelog najdete v oznámení, více detailů v kompletním changelogu.

Proud patchů do gitového repozitáře hlavní řady neustává; většinou jsou to opravy, ale od vydání 2.6.25-rc5 Linus také začlenil ovladače jmb38x pro hostitelské řadiče JMicron MemoryStick, zobrazovače Varitronix VL-PS-COG-T350MCQB-01, řadiče PATA Compact Flash na RouterBoard 500 a odstranil x86 quicklist.

Současná verze -mm stromu je 2.6.25-rc5-mm1. Nedávné změny v -mm zahrnují množství změn paměťové politiky, přepracování kódu předávajícího signály, jednoduchou sledovací infrastrukturu a spoustu pročišťovacích patchů.

Během minulého týdne nebyly vydány žádné stabilní verze.

Citáty týdne: Andrew Morton, Richard Stallman

Věci se teď odehrávají mnohem plynuleji než v 2.6.24-rcX a 2.6.23-rcX. Tři problémy při sjednocování jsou zanedbatelné, chyb při překladu je mnohem méně a problému při běhu, jak se zdá, také. Držím palce.

-- Andrew Morton

To není příliš důležité, protože Linux není GNU balíček. Kdyby to byl GNU balíček, napsal bych jeho správcům a navrhl jim, ať používají Bzr.

-- Richard Stallman

Lepší alokátor DMA paměti

Jak každý autor ovladačů k zařízením ví, hardware může být pěkně nepříjemný. V prvních dnech Linuxu periférie připojené přes ISA sběrnici způsobovaly hodně nepříjemností kvůli tomu, že nebyly schopné adresovat více než 24 bitů. To prakticky znamená, že ISA zařízení nemůže provádět DMA operace s pamětí nad 16 MB. PCI sběrnice toto omezení odstranila, ale po nějakou dobu bylo docela mnoho "PCI" zařízení, které byly jenom minimálně modifikované verze původní periférie pro ISA; spousta z nich zachovávala limit 16 MB.

Aby mohl uspokojit potřeby těchto zařízení, Linux dlouho udržoval DMA paměťovou oblast [DMA memory zone]. Ovladače, které potřebují alokovat paměť z této oblasti, specifikují ve svém požadavku GFP_DMA. Kód pro správu paměti se obzvláště stará o to, aby paměť v této oblasti byla dostupná a požadavky na DMA mohly být uspokojeny. Tímto způsobem systém může poskytnout rozumnou jistotu, že bude k dispozici paměť pro provedení DMA takovým způsobem, který vyhoví zvláštním potřebám takto postižených zařízení.

Jediný problém je, že zařízení, která mají 24bitový limit adresování, se už dnes téměř nevyskytují, takže DMA oblast bývá většinou nevyužita. Na druhou stranu jsou zařízení, která mají jiné druhy omezení. Mnoho periférií zvládne pouze 32bitové adresování, takže jejich DMA buffery musejí být ve spodních 4 GB paměti. Je ale také podmnožina, která má podivnější omezení - například 30 nebo 31 bitové adresování. Jaderná DMA knihovna poskytuje ovladačům způsob, jak oznámit svůj druh zahanbujícího omezení, ale kód pro správu paměti ve skutečnosti nijak nepomáhá DMA vrstvě při vytváření alokací, které těmto omezením vyhovují. Proto ovladače pro takováto zařízení musejí použít DMA oblast (která nemusí být na všech architekturách k dispozici) nebo doufat, že normální oblast paměti bude dostačovat.

Andi Kleen se rozhodl vyřešit tuto situaci novým alokátorem DMA paměti. Jeho řešením bylo vyjmout kus paměti z kompetencí svého jaderného kolegy a spravovat ho zcela jiným způsobem, čímž by se vytvořila rezervní zásoba pro DMA alokace. Výsledek je poněkud mimo normální algoritmy správy paměti v Linuxu, ale na úkol, na který se zaměřuje, může být přizpůsoben lépe.

Nový "mask" alokátor si při bootu rezervuje nastavitelnou oblast nízké paměti. Alokace z této oblasti se provádějí oddělenými voláními, kde jádrem API jsou:

struct page *alloc_pages_mask(gfp_t gfp, unsigned size, u64 mask);
void __free_pages_mask(struct page *page, unsigned size);

void *get_pages_mask(gfp_t gfp, unsigned size, u64 mask);
void free_pages_mask(void *mem, unsigned size);

alloc_pages_mask() vypadá podobně jako dlouho používaná funkce alloc_pages(), ale jsou tu důležité rozdíly. Parametr size udává požadovanou velikost alokace místo hodnoty "order" používané ve funkci alloc_pages() a mask popisuje rozsah adres použitelných pro tuto alokaci. Ačkoliv mask vypadá jako bitová maska, je to spíše hodnota adresy, kterou by alokovaná paměť měla mít; "díry" by v masce neměly smysl.

Volání alloc_pages_mask() se nejprve pokusí alokovat požadovanou paměť pomocí běžného alokátoru, který je v Linuxu k dispozici, protože předpokládá, že rezervovaná DMA paměť je obzvlášť omezený zdroj. Pokud tato alokace selže například proto, že není k dispozici fyzicky souvislá oblast dostatečné velikosti, alokátor ukousne z rezervované DMA paměti. Nicméně pokud alokace uspěje, alokovaná paměť musí být otestována oproti maximální povolené adrese - vzpomeňme, že běžný alokátor nemá žádnou podporu pro alokaci pod zvolenou adresou. Takže pokud je vrácená paměť mimo rozsah, musí být okamžitě uvolněna a místo toho se použije rezervovaná zásoba.

Tato rezervovaná oblast není spravována jako zbytek paměti. Místo seznamu kamarádů [buddy lists], které udržuje slab alokátor, má DMA alokátor jednoduchou bitovou mapu, která popisuje, které stránky jsou k dispozici. Obvykle bude procházet skrz celou rezervu a alokovat nejbližší dostupnou oblast dostatečné velikosti. Pokud ale tato oblast bude nad limitem adresy, alokátor se vrátí zpět k nižší části rezervované oblasti a alokuje paměť odtud. Díky tomu, že DMA alokace mají tendenci trvat jen krátkodobě, dá se očekávat, že použitelný blok bude k dispozici buď hned, nebo v blízké budoucnosti.

Další rozdíl je v tom, že na rozdíl od slab alokátoru DMA alokátor nezaokrouhluje velikost alokace na nejbližší vyšší mocninu dvou. DMA alokace mohou být relativně velké, takže zaokrouhlení by mohlo vést k významné interní fragmentaci a plýtvání pamětí.

O úroveň výš Andi přidal novou formu paměťové oblasti [mempool], která používá DMA alokátor:

mempool_t *mempool_create_pool_pmask(int min_nr, int size, u64 mask);

Tato oblast se bude chovat jako normální mempool s tím rozdílem, že všechny alokace budou pod limitem předávány jako mask. Tyto oblasti jsou využívány blokovou vrstvou, kde alokace pro DMA musí uspět.

Dalo by se říct, že rezervovat velký kus dolní paměti pro tento účel znamená redukovat celkové množství paměti dostupné systému - obzvlášť když si DMA alokátor stejně vyzobává paměť v normální oblasti, pokud to jde. Nicméně cena není tak velká, jak by se zdálo. Tyto patche odstraňují starou DMA oblast, která byla doteď prakticky spravována jako rezervovaná (a často nepoužitá) oblast paměti. Některé 64bitové architektury si navíc odkládají významný úsek (okolo 64 MB) dolní paměti pro swiotlb, což jsou v podstatě přeskakující zásobníky [bounce buffers], které se používají k impedančnímu přizpůsobení mezi buffery v horní paměti (>4 GB) a zařízeními, které nezvládnou více než 32bitovou adresu. S Andiho sadou patchů se swiotlb také alokuje z DMA oblasti a nepotřebuje svou vlastní. Celkové množství paměti vyhrazené pro zvláštní účely se tedy příliš nemění; ve skutečnosti by se dokonce mohlo zmenšit.

Pokud bude tento patch začleněn, pro většinu autorů ovladačů se tím mnoho nezmění. DMA vrstva již ovladačům umožňuje specifikovat masku adresy pomocí dma_set_mask(); s DMA alokátorem bude tato maska lépe dodržována. Jedna změna, která by mohla několik ovladačů ovlivnit, je ještě méně významná - GFP_DMA příznak alokace paměti časem zmizí. Každý ovladač, který tento příznak dosud používá, by měl místo toho nastavit správnou masku.

Zaslání těchto patchů zatím nevyvolalo žádnou větší diskuzi. Mlčení samozřejmě neznamená souhlas, ale zdá se, že proti této změně se nechystá žádný větší odpor.

Jak použít terabyte RAM

Ještě jsme se nedostali do stavu, kdy jsou systémy - dokonce i high-endové stroje - dodávány s terabytem nainstalované paměti. Nicméně produkty jako ty od Violin Memory dávají jasně najevo, že ten den se blíží; již teď se dá koupit stroj s 500 GB paměti. Takže se zdá, že by stálo zato položit otázku: když už někdo utratil nezanedbatelnou sumu, aby si koupil takový stroj, co bude dělat s tou pamětí - obzvlášť teď, když vývojáři Firefoxu začali vážně pracovat na odstranění memory leaků?

Možná je čas na nějaké divoké nápady. A není lepší zdroj pro takové nápady než Daniel Phillips, jehož Ramback patch tento týden rozdmýchal nemalou diskuzi. Jádrem jeho nápadu je, že celá paměť se změní na ramdisk, ke kterému je připojeno nonvolatilní zařízení. Za normálních okolností veškeré I/O operace programů zahrnují pouze ramdisk a díky tomu jsou vcelku rychlé (Každé malé znásobení výkonnosti 25× opravdu pomáhá.) Na pozadí se potom jádro stará o synchronizaci dat z ramdisku na permanentní úložiště. Synchronizační proces je ale více zaměřen na propustnost I/O operací, než na poskytnutí záruk na to, kdy přesně se konkrétní blok dat dostane na plotny disku.

Ramback se díky tomu liší od normálního blokového I/O cachování, které více způsoby provádí jádro. Místo toho uchovává celé zařízení v paměti, takže při běhu v ustáleném stavu by aplikace nikdy neměly narazit na zpoždění I/O disku. Když aplikace zavolá fsync(), k očekávaném výsledku (blokování, dokud data nejsou fyzicky zapsána na disk) nedojde. Souborové systémy se pečlivě starají o to, aby seřadily operace tak, aby se minimalizovalo riziko ztráty dat při pádu; Ramback to všechno ignoruje a zapisuje data na fyzické disky v takovém pořadí, jaké považuje za nejlepší. Jak to Daniel řekl, "nejzákladnějším principem" designu Rambacku je, že od zálohujícího ukládání se neočekává, že by během normálního fungování reprezentovalo konzistentní stav souborového systému. Jenom ramdisk potřebuje udržovat konzistentní stav a dal jsem si pozor na to, aby to bylo zajištěno. Vy potřebujete jenom věřit své baterii, Linuxu a hardwaru, na kterém běží. Kterému z nich nevěříte?

Ramback zahrnuje nouzový režim, který se pokusí ve spěchu synchronizovat data na disk v případě, že by UPS oznámila, že bylo ztraceno napájení. Nezdá se však, že by to všichni považovali za dostatečné. V následující diskuzi si nikdo nestěžoval na zisky výkonu, které by Ramback mohl poskytnout. Objevila se ale spousta obav o integritu dat; zdá se, že mnoho lidí nevěří svým bateriím, hardwaru a Linuxu. To vedlo diskuzi do slepé uličky, kdy mnoho vývojářů prohlásilo, že Ramback by byl pro nasazení příliš riskantní a Daniel se jejich obavami odmítl zabývat s tím, že je to FUD.

FUD nebo ne, tyto obavy bude Ramback pravděpodobně překonávat těžko. Mezitím Daniel hledá lidi, kteří by mu pomohli kód otestovat, což ale samo o sobě přináší další problémy:

Ovladač je připraven, aby ho dostatečně odvážný vývojář mohl otestovat. Mnoha způsoby může dojít k deadlocku a livelocku a abyste ho mohli odstranit, budete muset rebootovat. Nicméně by mělo být možné vymámit z něj dostatečně spolehlivý běh pro benchmarky a až se ustálí, tak bude pekelně úžasný.

Zatím jsou zprávy od dostatečně kurážných testerů řekněme ojedinělé. Jonathan Corbet, autor tohoto článku, se obává, že toto dílo může potkat stejný osud jako mnoho ostatních Danielových patchů: přestože možná obsahuje brilantní nápady a skvělé programování, nepřežije setkání s ošklivým skutečným světem. Nicméně potřebujeme lidi, kteří přemýšlejí o tom, jak budou počítačové systémy fungovat v budoucích letech; doufejme, že Daniel nepřestane.

GCC 4.3.0 odhaluje chybu v jádře

Změna v nedávném vydání GCC spojená s chybou v jádře vytvořila nepříjemnou situaci s možnými bezpečnostními důsledky. GCC změnilo některé předpoklady o příznacích v x86 procesoru v souladu s ABI standardem, což ale může vést k poškození paměti u programů přeložených GCC 4.3.0. Nikdo nepřišel se způsobem, jak nedostatku zneužít - alespoň zatím, ale zjevně se jedná o problém, který je potřeba řešit.

Problém se točí okolo x86 směrového příznaku [direction flag] DF, který určuje, jestli operace s blokem paměti pracují v paměti popředu nebo pozpátku. Hlavní použití tohoto příznaku je podpora pro kopírování překrývajících se oblastí paměti, kde je práce v paměti pozpátku nutná proto, aby data, která mají být zkopírována, nebyla předtím přepsána. Programátor Debianu Aurélien Jarno oznámil problém do linux-kernel 5. března, kdy na něj přišel, když překládal Steel Bank Common Lisp (SBCL) novým překladačem.

Nejnovější vydání GCC verze 4.3.0 předpokládá, že DF je při vstupu do každé funkce vynulován (tj. paměťové operace postupují v dopředném směru), jak to specifikuje ABI (které můžete, což je poněkud úsměvné, najít na sco.com [PDF]). To se bohužel v Linuxu střetává s obsluhami signálů, které jsou volány - nesprávně - s takovém stavem příznaku, jaký byl, když se signál objevil. Důsledkem toho jeden stavový bit procesu v uživatelském prostoru, který zrovna běžel, prosákne do obsluhy signálu.

To je chyba, která má sama o sobě zdánlivě minimální dopad. Před verzí 4.3 by GCC vygenerovalo instrukci cld (vynuluj direction flag) před provedením jakékoliv inline operace s pamětí nebo řetězcem, takže takové operace by začaly ze známého stavu. Ve verzi 4.3 GCC spoléhá na ABI, že direction flag je před vstupem do funkce vynulován, což znamená, že jádro to musí zajistit před zavoláním obsluhy signálu. V současnosti to nedělá, ale malý patch to opravuje.

Okno zranitelnosti je malé, ale v SBCL bylo pozorováno. Sled událostí, který vede k poškození paměti, je následující:

• program v uživatelském prostoru provede operaci (například memmove()), která nastaví DF
• ve stejném procesu se objeví signál
• jádro vyvolá obslužnou rutinu
• obslužná rutina udělá memmove(), u kterého si myslí, že proběhne v dopředném směru
• paměť je zkopírována v obráceném pořadí, což vede k poškození

Není patrné, jak by se z této chyby mohlo stát porušení bezpečnosti, ale bylo by chybou předpokládat, že nemůže. Jiné chyby v jádře jako například ta, která umožnila nedávný vmsplice() exploit, také vypadaly jako poškození paměti, ale nakonec se ukázalo, že byly horší. U této záležitosti s DF se může ukázat, že z bezpečnostního hlediska je neškodná, ale nemělo by se na to spoléhat.

Nyní je otázka: co s tím. Je zjevné, že jádro by nemělo dovolit prosáknutí stavu DF do obsluhy signálů bez ohledu na to, co dělá GCC. Je zajímavé všimnout si, že toto chování je úplně stejné (DF není při vstupu do obsluhy signálu vynulováno) v BSD jádrech, což některé vedlo k tvrzení, že nesprávné je ABI a GCC by se mělo vrátit ke svému původnímu chování. Solaris jádra nulují DF před zavoláním obsluhy signálu. Tento problém existoval 15 let; GCC doteď vždy vygenerovalo kód, který fungoval správně na jádrech, která se ABI neřídila.

Část problému tkví v tom, že je značné množství nainstalovaných jader, která jsou náchylná k tomuto problému, ale jenom pokud je nainstalováno GCC 4.3. Tato verze GCC zatím není velmi rozšířená, takže názor je takový, že GCC by se mělo vrátit k svému původnímu chování teď, než se dostane do distribucí. Až se rozšíří opravená jádra, "správné" chování může být obnoveno. Lidé od GCC to tak ale nevidí, takže je nejisté, co se stane.

Je pravda, že distributoři mohou ovládat, jaké jádro a jakou verzi GCC distribuují, to ale nejsou jediné cesty, jak mohou být nainstalovány buď GCC nebo programy překládané pomocí GCC. Je to v podstatě přinejmenším tikající časovaná bomba pro náhodné poškození paměti. Řešení takových hlášení o chybě může být obtížné a časově náročné. Zatímco nové chování GCC je správné a chyba je v jádře, bylo by velmi užitečné změnu stáhnout nebo ji možná zapínat pomocí argumentu na příkazové řádce pro ty, kdo si jsou jistí, že jejich binárky poběží na opatchovaných jádrech. Některé diskuze na gcc-devel konferenci naznačují, že GCC 4.3.0.1 nebo 4.3.1 se blíží.

       

Komentáře

[trekker.dk]

který vyhoví zvláštním potřebám takto postižených zařízením.

Před verzemi 4.3 by GCC vygenerovalo instrukci

- Mělo být "Před verzí..."

Sled událostí, který vede k poškození paměti je následující:

- chybí čárka před "je následující"

[Filip Jirsák]

To je chyba, který sama o sobě má zdánlivě minimální dopad.

Má být „chyba, která“…

[Prcek]

jak oznámit svůj druh zahanbujícícho omezení

[Peterix]

Odkaz pod citatem rms vede uplne jinam, nez by mel.

[Robert Krátký]

Opraveno, díky oběma.

[Jiri]

Kdyz uz existuje jaderny patch, proc by se melo nejak menit gcc?

[Tom.š Ze.le.in]

Třeba protože ten problém má víc OS? Protože není shoda v tom kdo by se měl přizpůsobit?

[trekker.dk]

Protože bude chvíli trvat, než se to dostane do distribucí...

[Michal Ludvig]

Jenze bude chvili trvat nez se do distribuci dostane i to GCC o kterem je rec, takze taky moc nechapu kde je problem. Stara GCC se soucasnymi i opatchovanymi kernely funguji, nove GCC funguje s opatchovanym novym kernelem. Jediny problem je nove GCC se starym kernelem, ale to asi nebude prilis typicka situace ke ktere by casto dochazelo. Distribuce to budou mit osetrene takze problem se tyka jen lidi kteri si sami upgraduji a kompiluji GCC i kernel a tech bude zanedbatelne mnozstvi. A pocitam ze vetsina jich bude z tabora Gentoo

[St]

Jaderné noviny - 12. 3. 2008 - neni 12.5.2008 :) ?

[Robert Krátký]

Je. Je mi líto skluzu, který překlady nabraly. Mám teď šikovné pomocníky, s jejichž pomocí se JN ze skluzu opět vyhrabou.

[trekker.dk]

No vzhledem k tomu, kolik chyb jsem v tomhle díle nechal, tak ti pomocníci nejsou zjevně až tak šikovní...

[SigTERM]

autisto...

[Robert Krátký]

No vzhledem k tomu, kolik chyb jsem v tomhle díle nechal

To je moje práce (bohužel jsou JN na překlepy náchylné, jelikož spellchecker se zarazí na takové spoustě slov, že mi občas něco unikne - i když je pravda, že zrovna dnes to byly spíše chyby, kterých by si mělo všimnout oko, ne program :-)).

[Field]

Ramdisk stinovany s normalnim diskem jsme pouzivali pro urychleni I/O se slusnymi uspechy uz pred dobre deseti lety. Mozna to spatne chapu, ale v cem je Ramback jiny?

[Kvakor]

Jenom tim, ze je v jadre a optimalizuje zapisy na disk. Jinak je to samozdrejme implementovatelne i jinak, od mirrorovani dvojce ramdisk/fyzicky disk, pres cowloop, unionfs ci FUSE az po reseni ciste v userspace pomoci ramfs/tmpfs a nejakeho demona, co prez inotify sleduje zmenene soubory a ty zapisuje na disk.

[Jendа]

To s 500GB paměti a Firefoxem mě pobavilo

[Milan Vít]

Počkej, až si to přečte Ten, jehož jméno se nevyslovuje!

[Jan Kundrát (jkt)]

Shrnuti bezpecnostniho dopadu DF je zavadejici -- ohrozeny jsou *pouze* systemy, ktere maji ne-uplne-nejnovejsi jadro zkompilovane gcc-4.3.0. Snad zadna distribuce neni tak hloupa, aby do produkcniho sveta vypustila binarni balicky starych jader kompilovancyh novym kompilatorem. Ohrozeni jsou pouze lide, kteri si kompiluji ne-uplne-nejnovejsi jadra uplne-nejnovejsim kompilatorem sami.

[trekker.dk]

Nn, přečti si to pořádně. Ohrožené jsou systémy s nepatchovaným jádrem (bez ohledu na to, čím bylo přeloženo), na kterých běží programy zkompilované gcc-4.3

[alblaho]

Já myslím, že ne. Staré GCC nuluje ten flag při každém vstupu do funkce. Takže žádný userspace program (kompilovaný čímkoliv) tam svůj flag nepropašuje.

Pokud je to jak říkáš ty, tak stačí vzít assembler a shodíš jakékoliv neopatchované jádro.

[trekker.dk]

Já myslím, že ne. Staré GCC nuluje ten flag při každém vstupu do funkce. Takže žádný userspace program (kompilovaný čímkoliv) tam svůj flag nepropašuje.

Problém je v tom, že nové GCC to nedělá a nepatchované jádro taky ne. Takže když program běží a přijde mu signál, tak zpracování toho signálu skočí do nějaké funkce (obsluhy toho signálu) a tam se předpokládá, že DF je vynulovaný. Jenže on být vynulovaný nemusí, záleží na tom, v jakém stavu byl za běhu toho programu.

Pokud je to jak říkáš ty, tak stačí vzít assembler a shodíš jakékoliv neopatchované jádro.

S největší pravděpodobností shodíš jenom svůj program. AFAIK se DF ukládá (stejně jako ostatní příznaky) pro každý proces zvlášť... I když přesně o tom se v článku píše - zatím nikdo nezveřejnil způsob, jak touto chybou ohrozit systém, nicméně nikdo neví

[alblaho]

Nn, přečti si to pořádně. Ohrožené jsou systémy s nepatchovaným jádrem (bez ohledu na to, čím bylo přeloženo), na kterých běží programy zkompilované gcc-4.3

Ty tvrdíš, že neopatchované jádro přeložené starým gcc je ohroženo userspace programy kompilované novým gcc4.3. A já tvrdím, že to není pravda. Staré (neopatchované) jádro přeložené starým gcc příznak nuluje.

Jediné ohrožení podstupují stará (neopatchovaná) jádra přeložené novým gcc4.3. Což žádný příčetný distributor nevyrobí, že.

[trekker.dk]

Staré (neopatchované) jádro přeložené starým gcc příznak nuluje.

Nenuluje.

[alblaho]

Já si myslím, že nuluje:

Před verzí 4.3 by GCC vygenerovalo instrukci cld (vynuluj direction flag) před provedením jakékoliv inline operace s pamětí nebo řetězcem, takže takové operace by začaly ze známého stavu.

Z toho anglického textu to není jasné. Tvůj výklad ale nedává smysl: proč by potom vývojáři chtěli, aby GCC změnilo své chování zpět, když každý útočník se může na milé gcc vykašlat a napíše ten útok přímo v assembleru? Oni prostě chtějí, aby se nestalo to, že je staré jádro přeložené novým GCC (přičemž ani jeden z této dvojice dotčený příznak nenuluje).

[trekker.dk]

Před verzí 4.3 by GCC vygenerovalo instrukci cld

Ano, před verzí 4.3 by GCC vygenerovalo instrukci cld. Tedy jádro ten příznak nenuluje, nulovalo ho GCC samo, takže se ta chyba 15 let neprojevila. Z toho textu je to podle mě naprosto jasné...

proč by potom vývojáři chtěli, aby GCC změnilo své chování zpět, když každý útočník se může na milé gcc vykašlat a napíše ten útok přímo v assembleru?

Aby se chyba neprojevila v userspace programech do doby, než bude vydáno opravené jádro.

Oni prostě chtějí, aby se nestalo to, že je staré jádro přeložené novým GCC (přičemž ani jeden z této dvojice dotčený příznak nenuluje).

Čím je přeložené nové jádro, je úplně jedno. Protože ať už nepatchované jádro přeložíš čímkoliv, nemá to na vynulování/nevynulování příznaku DF před voláním obsluhy signálu vliv.

Připomenu jednu věc, která ti možná uniká - obsluha signálu (signal handler) není součást jádra.

[alblaho]

Připomenu jednu věc, která ti možná uniká - obsluha signálu (signal handler) není součást jádra.

Ano, to mi uniklo. Představil jsem si obsluhu přerušení.

To ale znamená, že ohrožené není jádro, ale userspace programy, ne? Tedy: nepřekládejte si programy novým gcc, dokud nemáte opatchované jádro. To už dává velmi dobrý smysl i to zpětné zabugování GCC.

[trekker.dk]

To ale znamená, že ohrožené není jádro, ale userspace programy, ne?

Přesně tak. To taky (dle mého mínění) tvrdí věta

GCC změnilo některé předpoklady o příznacích v x86 procesoru v souladu s ABI standardem, což ale může vést k poškození paměti u programů přeložených GCC 4.3.0.

v článku.

[alblaho]

Já prostě nečtu pozorně. Ale než jsem tady s tebou začal diskutovat, tak jsem měl. Sorry a dík

[trekker.dk]

Jj, když mám pravdu, tak jsem nebezpečnej

Není zač

[Jan Kundrát (jkt)]

To neni pravda. Jakekoli jadro kompilovane pre-4.3.0 gcc v signal handleru DF nuluje, a proto ho to neshodi.

[trekker.dk]

Nemáš pravdu. Cituju originál článku:

GCC's most recent release, 4.3.0, assumes that the direction flag has been cleared (i.e. memory operations go in a forward direction) at the entry of each function, as is specified by the ABI (which is, somewhat amusingly, found at sco.com [PDF]). Unfortunately, this clashes with Linux signal handlers, which get called, incorrectly, with the flag in whatever state it was in when the signal occurred.

V diskuzi se potom objevuje odkaz na patch, který zajišťuje vynulování příznaku DF při volání obsluhy signálu. Cituju z popisu patche:

The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that.

Patch podepsal mezi jinými Ingo Molnár, takže předpokládám, že ten ví, o čem je řeč.

[alblaho]

Ano, staré jádro ten příznak nenuluje, ale spoléhá na nulování od GCC. Tedy výsledné zkompilované jádro-binárka ten příznak nuluje

Patch podepsaný Ingem je samozřejmě v pořádku, zaručuje, že se příznak vynuluje, bez ohledu na chování GCC.

[trekker.dk]

Tedy výsledné zkompilované jádro-binárka ten příznak nuluje

Nenuluje. Viz poslední odstavec tady

[geebranz]

More discussions soon

cryotherapylouisville.com