4 ms·
There's some important use cases for mprotect(), like toggling W^X on JIT pages, which that wouldn't work for.
by duskwuff 1y ago
There's some important use cases for mprotect(), like toggling W^X on JIT pages, which that wouldn't work for.
- Jyaif 1y agoW^X would be supported by the API that they suggest: "possibly copying a load of data into it for you incase you asked for a readonly range."
- duskwuff 1y agoFor JIT, you specifically need to be able to write some code to a page, then switch that page from writable to executable in place. Having the page move to a new location isn't acceptable, as the generated code will contain relative calls to other JIT generated code in other pages you've previously written to.
- Jyaif 1y agoOh right, good point!
- PhilipRoman 1y agoYou can probably replace some of those use cases by mapping the same physical page in two places with different permissions (W^X is per-address, not per physical page).
- IshKebab 1y agoIf you had a way of allocating pages of at least N bytes it would work. uint8_t* mem = malloc_pages(1024); mprotect_paged(mem, 1024);
- fweimer 1y agoThat's how mmap and mprotect work today. Sizes get rounded up to the next multiple of the page size. Many applications using mmap do not need to know about the page size. I think it's even part of POSIX: “The system performs mapping operations over whole pages. Thus, while the parameter len need not meet a size or alignment constraint, the system shall include, in any mapping operation, any partial page specified by the address range starting at pa and continuing for len bytes.”
- pjmlp 1y agoYes, but that is a platform implementation detail, not something NDK apps should mess with.