[Cryptography] WIPEONFORK in Linux 4.14

Henry Baker hbaker1 at pipeline.com
Fri Nov 24 10:54:07 EST 2017


At 11:32 AM 11/22/2017, Colm MacCárthaigh wrote:
>Version 4.14 of the Linux kernel was released on November 12th, and it contains a new MADV_WIPEONFORK option for madvise().
>
>Memory regions marked with the option will be wiped (set to all zeroes) in the child process after a call to fork() (or clone() or whatever).
>
>This is similar to the MINHERIT_ZERO option from OpenBSD that the new addition is based on.
>
>For crypto libraries this is particularly useful:
>
>  * The option can be used to robustly reset a guard variable, and hence re-initialize an RNG, DRBG, PRF, or other generator where duplicate state across processes would be a security issue.
>  * The option can be used to ensure that keys and plaintext are not inadvertently duplicated across processes and lingering in memory needlessly.
>  * The option avoids the problems of pthread_atfork, which is avoided by some applications (they syscall clone directly), and the overhead, probabilistic risk or caching risk of using getpid() and getppid() guards to detect forks.
>  * The option can be combined with MADV_DONTDUMP (prevents memory from showing up in a core dump) and mlock() (prevents memory from being swapped) to ensure that sensitive data is also not recorded on disk.
>
>To use the option, it's as simple as something like ...
>
>#ifdef MADV_WIPEONFORK
>
>if (madvise(addr, len, MADV_WIPEONFORK)) {
>    /* madvise failed, maybe an older kernel */
>}
>
>#endif

Now if we could just get a "clean" file system that is guaranteed to erase all traces of a file when it is deleted -- not only the file contents, but also any metadata and old filenames stored in the directories.

Yes, I know there are "secure delete" commands, but they're useless unless they can somehow be made the *default* behavior for all file operations.



More information about the cryptography mailing list