Conversation

This is a very good tweet.

Quote Tweet

Mar 23, 2021

Replying to @andy_kelley @saleemrash1d and 2 others

Basically, make a massive PROT_NONE mapping and then you allocate with mprotect to PROT_READ|PROT_WRITE and free by using MAP_FIXED mmap to replace a section with a new fresh PROT_NONE region. It prevents anything else from getting that via mmap outside of your own mmap usage.

Replying to

This is like the Windows notion of reserving vs. committing address space. Linux secretly has this too, when you disable overcommit, but overcommit culture is so prevalent that you can't get information like "committed memory usage" for a process.

Replying to

and

Quote Tweet

Replying to @lynn314159 @andy_kelley and 3 others

It won't work well in the default heuristic overcommit mode which gives you the worst of both worlds. It only works properly in the full overcommit mode. Linux has support for a memory accounting mode too, and it doesn't work for that, since rw anon memory is accountable.

Replying to

and

For context: that's in reply to someone suggesting using a rw mapping from the start, which won't work properly. Linux does essentially have the concept by default in the heuristic overcommit mode, but it's pretty arbitrary about when it gives an error and it's per-process.

Replying to

By the way, the documentation for MAP_NORESERVE in mmap(2) for linux-man-pages is completely wrong. The flag is a no-op in the full overcommit mode and the memory accounting mode. Sole function is to have heuristic overcommit mode ignore a mapping. It can't segfault as it claims.

Replying to

One of the fun parts of having the linux-man-pages act as the user-facing kernel documentation while not actually being developed as part of the kernel or by the kernel developers. The docs people read are wrong and Linux itself barely bothers to have any docs for anything.

12:51 AM · Mar 23, 2021Twitter Web App

Replying to

So, for example, I know that using mmap with MAP_FIXED and PROT_NONE to clobber mappings will get rid of them as accountable memory. Seem to recall that using madvise MADV_DONTNEED and then mprotect to PROT_NONE will still count against you but it's not like they document stuff.

Replying to

There are some gotchas in their APIs such as mremap giving EINVAL if you use it on more than 1 VMA, but the kernel sometimes fails to merge VMAs, so even with MREMAP_DONTUNMAP|MREMAP_FIXED it's problematic with this kind of virtual memory usage.

Replying to

This is why I advocate “Literate Programming.” Doc sources and source code live together, and so are much more likely to be developed together.