Jaderné noviny - 12. 3. 2008 (diskuse)

[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