Currently, IPC shared memory is padded up to a multiple of the page size with zero bytes, which makes it easy to miss bugs that read or maybe even write a short distance past the end. Things we could do include: * Filling the padding with non-zero bytes, to detect overreads that expect nulls. * Checking the padding on free, in case of overwrites. * On ASan (or valgrind?) builds, tell the instrumentation that the padding must not be accessed. * Guard pages might be nice too. With mmap() we can get trailing guard pages “for free” by mapping a larger area than the underlying object; not sure about difficulty with other APIs. * Non-zero-filling the entire contents on debug builds, like we do with malloc, but this would require “fixing” code that depends on the memory being zeroed (which is normally a reasonable thing to assume here, because we get it pre-zeroed from the OS). Some of this is easy; some of it is less easy and may not be useful enough to justify doing it. Related work: ipc::Shmem has sentinels before and after the payload on debug builds only, but I believe they're also page-aligned and don't help with this, and I don't know that they're accomplishing anything useful as it stands. I'm not sure if bug 504250 is the right meta for this — I was originally thinking of this as a debugging aid for catching errors that happen during normal testing, not hardening against exploits on release — but I don't know if there's a better one, and there might be actual-hardening things we can do here.