Theo De Raadt planong palakasin ang mekanismo ng proteksyon ng memorya ng W^X (Write XOR Execute). Ang kakanyahan ng mekanismo ay ang mga pahina ng memorya ng proseso ay hindi maaaring sabay na ma-access para sa pagsulat at pagpapatupad. Kaya, ang code ay maipapatupad lamang pagkatapos ma-disable ang pagsusulat, at ang pagsusulat sa isang memory page ay posible lamang pagkatapos ma-disable ang execution. Ang mekanismo ng W^X ay tumutulong na protektahan ang mga application ng user-space mula sa mga karaniwang pag-atake ng buffer overflow, kabilang ang mga stack overflow, at aktibo sa OpenBSD .
Mula sa simula ng trabaho sa W^X, malinaw na ito ay isang mahabang kalsada, dahil mayroong malaking bilang ng mga application na gumagamit ng JIT. Ang mga pagpapatupad ng JIT ay maaaring nahahati sa tatlong kategorya:
- Pagpapalit ng memory sa pagitan ng W at X states, tinatanggap ang "gastos" ng system call .
- Paglikha ng mga alias sa pagitan ng isang pares ng W at X na mga pagmamapa ng parehong memorya.
- Ang pinaka "marumi" na opsyon ay ang mga nangangailangan ng W|X memory model na nagbibigay-daan sa sabay-sabay na pag-record at pagpapatupad.
Sa kasalukuyan, may mas kaunting mga programa na gumagamit ng pangatlong opsyon at mas marami ang gumagamit ng una at pangalawa. Gayunpaman, dahil kinakailangan na magpatakbo ng mga programa na may W|X JIT (pangunahin sa Chromium at Iridum), isang "wxallowed" na opsyon sa pag-mount ng filesystem ay idinagdag, na nagpapahintulot sa memory na magamit nang sabay-sabay para sa parehong pagsulat at pagpapatupad, kung sakaling ang executable na ELF Ang file ay minarkahan ng "wxneeded" marker, at ang mga application mismo ay karagdagang protektado gamit ang mga mekanismo ΠΈ upang limitahan ang listahan ng mga system call na ginamit at mga bahagi ng file system na magagamit sa application, ayon sa pagkakabanggit.
Upang higit pang gawing kumplikado ang pagsasamantala ng mga kahinaan sa naturang mga aplikasyon, ang isang karagdagan sa mekanismo ay iminungkahi , na nagsusuri kung ang tawag sa system ay isinasagawa mula sa isang pahina ng nasusulat na memorya. Kung maisusulat ang pahina, mapipilitang wakasan ang proseso. Sa ganitong paraan, hindi mapakinabangan ng isang attacker ang mga system call at mapipilitang subukang hanapin ang mga kinakailangang gadget sa pagpapatupad ng JIT, o kahit na gawin ang mas mahirap na gawain ng pag-detect ng mga system call stub nang direkta sa loob. .
Ang mga proseso ng Chrome/Iridium ay medyo mapagkakatiwalaan nang protektado gamit ang pledge at unveil, ngunit ang pag-alis ng kakayahang gamitin, halimbawa, ang write(2) system call ay malinaw na may ilang bentahe, dahil lumilikha ito ng mga karagdagang paghihirap para sa umaatake. Gayunpaman, ang mga paghihirap ay maaari ding lumitaw kung ang pagpapatupad ng JIT ay gumagamit ng mga katutubong tawag sa system mula sa memorya ng W|X. Gayunpaman, may dahilan para umasa na hindi ito mangyayari, dahil ilang beses nang binago ang ABI, ngunit walang sinuman ang nag-ulat ng mga problema.
Ang mga pagbabago ay magagamit na sa mga regular na snapshot ng OpenBSD-Current branch, lahat ng interesado ay iniimbitahan na subukan.
Ang mga kaugnay na balita tungkol sa hitsura ng mode sa Chrome/Iridium ay nararapat sa isang hiwalay na komento mula kay Theo . Mula sa kanyang pananaw, ito ay katanggap-tanggap para sa ilang mga modelo ng paggamit, ngunit malamang na hindi para sa lahat, dahil ang mode na ito ay malinaw na tataas ang pagkarga sa processor. Sa kasalukuyan, kadalasang gagana ang Chrome kung idi-disable mo ang "wxallowed" para sa /usr/local, bagama't maaaring may mga problema sa ilang extension (ang ghostery ay isang halimbawa). Sa isang paraan o iba pa, umaasa si Theo na ang ganap na trabaho sa JITless mode ay dadalhin sa isang ganap na pagpapatakbo na estado sa malapit na hinaharap.
Pinagmulan: opennet.ru