make.conf

[Dan Lukes]

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