Theo De Raadt planifikon të forcojë mekanizmin e mbrojtjes së kujtesës W^X (Write XOR Execute). Thelbi i mekanizmit është se faqet e kujtesës së procesit nuk mund të aksesohen njëkohësisht për shkrim dhe ekzekutim. Kështu, kodi mund të ekzekutohet vetëm pasi shkrimi është i çaktivizuar, dhe shkrimi në një faqe memorie është i mundur vetëm pasi ekzekutimi është i çaktivizuar. Mekanizmi W^X ndihmon në mbrojtjen e aplikacioneve të hapësirës së përdoruesit nga sulmet e zakonshme të tejmbushjes së tamponit, duke përfshirë tejmbushjet e stivit, dhe është aktiv në OpenBSD .
Që nga fillimi i punës në W^X, ishte e qartë se kjo ishte një rrugë e gjatë, pasi kishte një numër të konsiderueshëm aplikacionesh që përdornin JIT. Zbatimet e JIT mund të ndahen në tre kategori:
- Ndërrimi i memories midis gjendjeve W dhe X, pranimi i "kostos" së thirrjes së sistemit .
- Krijimi i pseudonimeve midis një çifti pasqyrimesh W dhe X të së njëjtës memorie.
- Opsioni më i "ndotur" kërkon një model memorie W|X që lejon regjistrimin dhe ekzekutimin e njëkohshëm.
Aktualisht, ka shumë më pak programe që përdorin opsionin e tretë dhe më shumë duke përdorur të parën dhe të dytën. Megjithatë, meqenëse ishte e nevojshme të ekzekutoheshin programe me W|X JIT (kryesisht Chromium dhe Iridum), u shtua një opsion "wxallowed" i montimit të sistemit të skedarëve, i cili lejonte përdorimin e memories njëkohësisht si për shkrim ashtu edhe për ekzekutim, në rast se ELF i ekzekutueshëm skedari është shënuar me shënuesin "wxneeded", dhe vetë aplikacionet u mbruan gjithashtu duke përdorur mekanizma и për të kufizuar listën e thirrjeve të sistemit të përdorura dhe pjesëve të sistemit të skedarëve në dispozicion të aplikacionit, përkatësisht.
Për të komplikuar më tej shfrytëzimin e dobësive në aplikacione të tilla, propozohet një shtesë në mekanizëm , i cili kontrollon nëse thirrja e sistemit po ekzekutohet nga një faqe memorie e shkrueshme. Nëse faqja është e shkrueshme, procesi detyrohet të përfundojë. Në këtë mënyrë, një sulmues nuk do të jetë në gjendje të shfrytëzojë thirrjet e sistemit dhe do të detyrohet të përpiqet të gjejë pajisjet e nevojshme në zbatimin JIT ose edhe të bëjë punën më të vështirë të zbulimit të cungëve të thirrjeve të sistemit direkt brenda .
Proceset e Chrome/Iridium janë tashmë mjaft të besueshme të mbrojtura duke përdorur premtimin dhe zbulimin, por heqja e aftësisë për të përdorur, për shembull, thirrjen e sistemit shkrim(2) ka padyshim një avantazh, pasi krijon vështirësi shtesë për sulmuesin. Megjithatë, vështirësi mund të lindin gjithashtu nëse zbatimi JIT përdor thirrjet e sistemit vendas nga memoria W|X. Megjithatë, ka arsye për të shpresuar se nuk do të jetë kështu, pasi ABI është ndryshuar disa herë, por askush nuk ka raportuar ndonjëherë probleme.
Ndryshimet janë tashmë të disponueshme në fotot e rregullta të degës OpenBSD-Current, të gjithë të interesuarit janë të ftuar të testojnë.
Lajmet e lidhura në lidhje me paraqitjen e modalitetit në Chrome/Iridium meritojnë një koment të veçantë nga Theo . Nga këndvështrimi i tij, kjo është e pranueshme për disa modele përdorimi, por ndoshta jo për të gjithë, pasi kjo mënyrë padyshim do të rrisë ngarkesën në procesor. Aktualisht, Chrome do të funksionojë kryesisht nëse çaktivizon "wxallowed" për /usr/local, edhe pse mund të ketë probleme me disa shtesa (një shembull është ghostery). Në një mënyrë apo tjetër, Theo shpreson që puna e plotë në modalitetin JITless do të sillet në një gjendje plotësisht funksionale në të ardhmen e afërt.
Burimi: opennet.ru