Én az egyik hivatkozott threadet olvastam el 2005-ből, ahol Mingo elég jól leírta az álláspontját, hogy neki (mint RedHat fejlesztő) mi volt a problémája a PaX-szal.
Nem értek hozzá, de a 3 dolog, amiket felhozott teljesen értelmesnek tűntek a RedHat szempontjából:
- a processzek számára elérhető memória felére csökkenése (3G -> 1.5G): ez RedHat számára probléma, ha van olyan alkalmazás fizető klienseknél, ami ennél többet igényel.
- az implementáció komplexitása: ezen nyilván lehet vitatkozni, szerintem ez némi lélekápolással megoldható lett volna.
- exception list kézi karbantartása: jól látszik, hogy az ő megoldásuknak (exec-shield) az automatikus kivételfelderítés volt az egyik általuk kitalált "killer" feature. Ennek természetesen fontos gyakorlati jelentősége volt számukra a disztribúció fejlesztése / támogatása szempontjából.
Azt Mingo elismerte, hogy a PaX teljes védelmet nyújt, míg az exec-shield nem. Viszont az ő (RedHat) követelményeiknek az exec-shield jobban megfelelt. A levelekből határozottan az az érzésem, hogy ha a fenti problémákra megoldásokat lehetett volna találni, akkor a RedHat/Mingo nem ellenezte volna a beolvasztást. Azt persze nem tudom, hogy a fenti problémák idő közben megoldásra kerültek-e, és milyen volt ezeknek a javításoknak a fogadtatása.
Nekem Linus mostani válaszából is úgy tűnik, hogy lehetőség lenne a Grsec / PaX jelentős részének beolvasztására, ha a Grsec / PaX fejlesztők hajlandók együtt dolgozni (szétszedni a patcheket triviális részekre, egyenként az összes review problémát türelmesen megvitatni...stb.)
Ez persze nem érdekes munka, sok idegeskedéssel/levelezéssel és kevés kódolással jár. Ugyanakkor egy ilyen átírás/review kör véleményem szerint javíthatja a kód minőségét.
Üdv,
Gergely