On 06/27/13 01:48, Jan Dušátko:
Ne, ale pamatuju si, ze nekde v handbooku ci kde je pouziti vlastnich
nastaveni optimalizace pri prekladu jadra povazovano za neco co delas "na
vlastni nebezpeci". Muze dojit ke vzniku race-condition zpusobenych
nevhodnou optimalizaci pri prekladu a jadro pak muze nahodne padat ci
vykazovat jine "podivne" chovani.
Jak mne Dan Lukes varoval, muze dojit k problemum s kompatibilitou kompileru
a jadra, ktera finalne muze skoncit az nefunkcnosti system - to je zivot.
Ona to zas takova selanka neni. Nejde jen o to, ze by nova optimalizace
mohla preskladat instrukce a tak by treba mohly nefungovat spravne
nektere zamky.
Specificka optimalizace muze spocivat i v pouziti specifickych registru,
ktere v obecnych procesorech vubec nejsou. A u tech se objevuje
jednoducha otazka - je jejich stav ukladan pri prepinani kontextu (task
switche, preruseni, obsluha vyjimek) ?
Jestli ne, je funknost kazdeho kusu kodu, ktery takovy registr pouziva,
zavisly na tom, zda v prubehu jeho provadeni dojde k nejake asynchronni
udalosti a pokud ano, zda mu obsluzna rutina te udalosti obsah toho
registru zachova nebo prepise. Normale se stav registru (a komponent
vubec), ktere neulozi sam hardware procesoru v ramci prepnuti stavu
uklada softwarove, v kazde asynchronne spustitelne obsluzne rutine.
Pokud ty ovsem jadru podstrcis uzivani tehle registru "tajne", jako
dusledek implicitni optimalizace prekladce, pak ulozeni stavu nenastane.
Zminoval's, ze optimalizace zrychlila praci s internim hardwarovym
kryptografickym akceratorem. Predstavuju si napriklad, jak mas sifrovany
disk, data se pred ulozenim prohaneji pres akcelerator rizeny
preoptimalizovanym kodem, behem zpracovani prijde nevhodne preruseni,
ktere zmeni stav nektereho z neulozenych registru, ten se po ukonceni
obsluhy preruseni bude dal v ramci algoritmu pouzivat ac se jeho stav
nahodne zmenil a vysledkem bude, ze na disk zapises v podstate nahodna
data aniz by se na to prislo - do doby, nez se ty data pokusis cist a
ono se zjisti, ze po desifrovani sektoru nevznikl puvodni plainttext ale
sypanej caj.
Jak rikas ty, je to zivot, a jak rika klasik, zivot je jen nahoda.
Mozna bys mel zjistit co presne vlastne pro prekladac zapnuti tehle
specificke optimalizace skutecne znamena. Protoze to ti muze pomoct
alespon trochu odhadnout jak velke potize tam mohou vzniknout.
V soucasne chvili mi to co delas pripada jako ruska ruleta, a to ses ani
nepodival kolik komor je nabitejch. Mozna treba zadna, pak mas stesti,
ale mozna je to jinak a nakonec to muze dopadnout docela spatne.
Ale to uz je na tobe.
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
