Date: Tue, 17 Apr 2018 21:37:43 +0200 From: Jann Horn <jannh@...gle.com> To: Solar Designer <solar@...nwall.com> Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com> Subject: Re: mmap flags On Tue, Apr 17, 2018 at 9:31 PM, Solar Designer <solar@...nwall.com> wrote: > Hi, > > I'd like to have two new security-related mmap() flags on Linux: > > 1. MAP_NOCORE - same as FreeBSD already has, "Region is not included in > a core file." per their man page. We can now do similar by writing a > bitmask into /proc/<pid>/coredump_filter, but it's cumbersome (not > something a library would be OK doing because of its one security > sensitive and/or very large mapping needing this), low granularity (not > per mapping), and non-portable (MAP_NOCORE would be portable at least > between Linux and FreeBSD). Linux already has madvise(addr, len, MADV_DONTDUMP): http://man7.org/linux/man-pages/man2/madvise.2.html > 2. MAP_ZEROIZE (or whatever we call it) - zeroize the pages on unmap > (but not necessarily before the munmap() syscall returns), including on > [abnormal] process exit, which is good for security (if the data is > sensitive) and also for performance (the program doesn't have to do the > zeroization on its own and either wait for it to complete or spawn a > thread, but instead can trivially defer this work to be done by the > kernel a bit later; also, a subsequent mmap() with MAP_POPULATE, or > corresponding memory accesses if without MAP_POPULATE, can complete > quicker due to the lazily-zeroized pages). > > I'd use both for yescrypt. In fact, I learned of FreeBSD's MAP_NOCORE > from scrypt, so indeed yescrypt already uses it where available, too. > > I'd also like SHM_* equivalents of these. And a SHM_POPULATE too, but > that's purely for performance (not security), so is off-topic here. > I'd use those for yescrypt ROMs. > > Perhaps the zeroization can build upon a common framework also > supporting a sysctl where it's forced on all (or only ever writable?) > mappings of all processes, without them requesting it explicitly. It's > just set the flag on all mappings (few systems will) vs. only on some > (few libraries and programs will, but hopefully those where it's needed > the most). This would reduce total complexity of the implementation. > > Not hardening of the kernel (in fact, there's a risk we'd introduce bugs > at first), but helping harden the userland. > > I'm just posting this in case anyone capable has time and willingness > to work on this. > > Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.