Theo De Raadt W^X (Write XOR Execute) memoria babesteko mekanismoa indartzeko asmoa du. Mekanismoaren funtsa da prozesuen memoria-orrialdeak ezin direla aldi berean sartu idazteko eta exekutatzeko. Beraz, kodea idazketa desgaitu ondoren bakarrik exekutatu daiteke, eta memoria-orri batean idaztea posible da exekuzioa desgaitu ondoren. W^X mekanismoak erabiltzaile-espazioko aplikazioak buffer gainezkatze-eraso arruntetatik babesten laguntzen du, pila-gainetik barne, eta OpenBSD-en aktibo dago. .
W^X-ko lanak hasi zirenetik, argi zegoen bide luzea zela, JIT erabiltzen zuten aplikazio kopuru esanguratsuak baitzeuden. JIT inplementazioak hiru kategoriatan bana daitezke:
- Memoria W eta X egoeren artean aldatzea, sistema-deiaren βkostuaβ onartuz .
- Memoria bereko W eta X mapeoen arteko aliasak sortzea.
- Aukerarik βzikinenakβ W|X memoria eredua behar du, aldibereko grabazioa eta exekuzioa ahalbidetzen dituena.
Gaur egun, nabarmen gutxiago daude hirugarren aukera erabiltzen duten programak eta gehiago lehenengoa eta bigarrena erabiltzen dutenak. Hala ere, W|X JIT-ekin programak exekutatu behar zirenez (batez ere Chromium eta Iridum), "wxallowed" fitxategi-sistema muntatzeko aukera bat gehitu zen, eta horri esker, memoria aldi berean erabili zen idazteko eta exekutatzeko, ELF exekutagarria bada. fitxategia "wxneeded" markatzailearekin markatuta dago, eta aplikazioak beraiek ere babestu zituzten mekanismoak erabiliz ΠΈ erabilitako sistema-deien zerrenda eta aplikazioak eskuragarri dituen fitxategi-sistemaren zatiak mugatzeko, hurrenez hurren.
Horrelako aplikazioetan ahulezien ustiapena are gehiago zailtzeko, mekanismoaren gehikuntza proposatzen da , sistema-deia idazteko memoria orri batetik exekutatzen ari den egiaztatzen duena. Orria idazteko modukoa bada, prozesua amaitzera behartuta dago. Horrela, erasotzaile batek ezin izango ditu sistema-deiak ustiatu eta JIT inplementazioan beharrezko tresnak aurkitzen saiatzera behartuta egongo da edo baita sistemaren deien zirriborroak zuzenean detektatzeko lan zailagoa egitera ere. .
Chrome/Iridium prozesuak fidagarritasunez babestuta daude dagoeneko konpromisoa eta agerraldia erabiliz, baina erabiltzeko gaitasuna kentzeak, adibidez, idazteko (2) sistema deiak, jakina, abantaila batzuk ditu, erasotzaileari zailtasun gehigarriak sortzen dizkiolako. Hala ere, zailtasunak ere sor daitezke JIT inplementazioak W|X memoriatik jatorrizko sistema-deiak erabiltzen baditu. Hala ere, bada hori horrela ez izatea espero izateko, ABI hainbat aldiz aldatu baita, baina inork ez du inoiz arazorik jakinarazi.
Aldaketak dagoeneko eskuragarri daude OpenBSD-Current adarraren ohiko argazkietan, interesa duten guztiak proba egitera gonbidatuta daude.
Chrome/Iridium-en moduaren itxurari buruzko albisteek Theo-ren iruzkin bat merezi dute . Bere ikuspuntutik, hau erabilera-eredu batzuentzat onargarria da, baina seguruenik ez guztientzako, modu honek, jakina, prozesadorearen karga handituko duelako. Gaur egun, Chrome-k gehienbat funtzionatuko du /usr/local-erako "wxallowed" desgaitzen baduzu, luzapen batzuekin arazoak egon daitezkeen arren (ghostery da adibide bat). Modu batera edo bestera, Theok espero du etorkizun hurbilean erabateko funtzionamendu egoerara eramango dela JITless moduan.
Iturria: opennet.ru