Hacker News Reader

Comment by londons_explore | Hacker News Reader

the mprotect API could have been designed more like malloc() - ie. you don't protect a preexisting memory range - instead the API returns a new memory range with the protections you've asked for, possibly copying a load of data into it for you incase you asked for a readonly range.

And that 'copy' might be zero-overhead remapping of the original pages.

View on HN

That API basically exists (you can use mmap() with a dummy backing file), and it is not useful for any of the things you use mprotect() for.

There's some important use cases for mprotect(), like toggling W^X on JIT pages, which that wouldn't work for.

W^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."

For 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.

Oh right, good point!

You 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).

If 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);

That'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.”

Yes, but that is a platform implementation detail, not something NDK apps should mess with.

Reply on news.ycombinator.com