Portál AbcLinuxu, 6. května 2025 08:36
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í"
To je chyba, který sama o sobě má zdánlivě minimální dopad.Má být „chyba, která“…
12.5.2008 14:20
Prcek | skóre: 43
| Jindřichův Hradec / Brno
No vzhledem k tomu, kolik chyb jsem v tomhle díle nechalTo 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 :-)).
12.5.2008 16:41
Jendа | skóre: 78
| blog: Jenda
| JO70FB
12.5.2008 16:45
Milan Vít | skóre: 23
| blog: about:linux
| Orlová
12.5.2008 21:06
alblaho | skóre: 17
| blog: alblog
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í
12.5.2008 21:54
alblaho | skóre: 17
| blog: alblog
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.3Ty 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.
Staré (neopatchované) jádro přeložené starým gcc příznak nuluje.Nenuluje.
12.5.2008 22:19
alblaho | skóre: 17
| blog: alblog
Před verzí 4.3 by GCC vygenerovalo instrukci cldAno, 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.
12.5.2008 22:47
alblaho | skóre: 17
| blog: alblog
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.
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.
12.5.2008 23:13
alblaho | skóre: 17
| blog: alblog
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č.
12.5.2008 22:23
alblaho | skóre: 17
| blog: alblog
Patch podepsaný Ingem je samozřejmě v pořádku, zaručuje, že se příznak vynuluje, bez ohledu na chování GCC.
Tedy výsledné zkompilované jádro-binárka ten příznak nulujeNenuluje. Viz poslední odstavec tady
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
