Truncation

[asajeffrey]

If the shared memory file is truncated, accessing the newly-free memory will cause a SIGBUS.

[asajeffrey]

So, what to do about that? We could make this not part of the attacker model (which I think is the solution used by shared_memory); we could install a SIGBUS interrupt handler and claim this is safe; we could make initializing shared memory unsafe; we could find out if each underlying OS has a way to mark a shared memory file as being untruncatable. None of these are particularly appealing.

[asajeffrey]

cc @nox and @elast0ny.

[asajeffrey]

elast0ny/shared_memory#31 is the relevant shared_memory issue.

[asajeffrey]

Posix supports ANONYMOUS_MMAP to avoid having a publicly-accessible filename, but this only works for memory shared with processes created using fork().

[asajeffrey]

So Linux has pretty much what we want, which is the F_SEAL_SHRINK seal (http://man7.org/linux/man-pages/man2/memfd_create.2.html) but I'm not sure what the equivalent is on, e.g., Windows or MacOS.

[comex]

FWIW, on macOS:

• Currently, a given POSIX shared memory object (what shared_memory uses) can only have ftruncate called on it once, to allocate storage initially; future calls to ftruncate will always fail. Thus, it's not possible to maliciously truncate shared memory that's currently mapped. But this is not documented and could theoretically change in the future, given that it contradicts the POSIX spec.

• If you want a stronger guarantee, you could use platform-specific APIs like mach_make_memory_entry.

[asajeffrey]

Interesting! I didn't know that about ftruncate. If windows and android have similar properties, then we may be able to provide workarounds on most platforms.