Increase the default RLIMIT_MEMLOCK
PATCH 1/1 Increase the default RLIMIT_MEMLOCK
Hi,
Currently, the default value for RLIMIT_MEMLOCK (defined in include/linux/resource.h) is 32 KiB, because this value is enough for GnuPG.
However this value is not enough for gnome-keyring-daemon, which will store both SSH and GnuPG keys, plus user passwords for various kinds of resources. Upstream authors recommend to provide a limit of at least 256 KiB for RLIMIT_MEMLOCK for the keys to remain securely in memory.
Given the amount of memory in current machines, I think 256 KiB is still a very reasonable value. What do you think of increasing this default value in the kernel?
Cheers,
Signature · 4 lines
.''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
linux/resource.h renamed from linux/resource.h.orig +4 -3
@@ -58,10 +58,11 @@#define _STK_LIM (8*1024*1024)/* -* GPG wants 32kB of mlocked memory, to make sure pass phrases -* and other sensitive information are never written to disk. +* The biggest widespread mlocked memory consumer is +* gnome-keyring-manager. It needs 256kB to make sure SSH/GPG +* passphrases and network passwords are never written to disk. */ -#define MLOCK_LIMIT (8 * PAGE_SIZE) +#define MLOCK_LIMIT (64 * PAGE_SIZE)/* * Due to binary compatibility, the actual resource numbers
Quoted 26 lines · On Sun, 27 Apr 2008 21:26:27 +0200 Josselin Mouette <[email protected]> wrote:
Currently, the default value for
RLIMIT_MEMLOCK(defined ininclude/linux/resource.h) is 32 KiB, because this value is enough for GnuPG.However this value is not enough for gnome-keyring-daemon, which will store both SSH and GnuPG keys, plus user passwords for various kinds of resources. Upstream authors recommend to provide a limit of at least 256 KiB for
RLIMIT_MEMLOCKfor the keys to remain securely in memory.Given the amount of memory in current machines, I think 256 KiB is still a very reasonable value. What do you think of increasing this default value in the kernel?
Cheers,
Signature · 7 lines
.''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile. [linux_mlock_256k.patch text/x-patch (668B)]linux/resource.h renamed from linux/resource.h.orig +0
-0@@ -58,10 +58,11 @@#define _STK_LIM (8*1024*1024)
linux/resource.h line 65
Quoted 10 lines
linux/resource.h renamed from linux/resource.h.orig +4
-3/* -* GPG wants 32kB of mlocked memory, to make sure pass phrases -* and other sensitive information are never written to disk. +* The biggest widespread mlocked memory consumer is +* gnome-keyring-manager. It needs 256kB to make sure SSH/GPG +* passphrases and network passwords are never written to disk. */ -#define MLOCK_LIMIT (8 * PAGE_SIZE) +#define MLOCK_LIMIT (64 * PAGE_SIZE)
gee, it seems rather arbitrary. Perhaps we should have set it to zero on day one to _force_ distributors to set an appropriate RLIMIT_MEMLOCK in init.
We can do this of course, but does it actually help anything? Perhaps it's actually a bad thing, permitting userspace developers to rely upon kernel defaults rather than setting things they way they should be set?
Quoted 5 lines · * Andrew Morton ([email protected]) wrote:
Quoted 5 lines
linux/resource.h renamed from linux/resource.h.orig +0
-0@@ -58,10 +58,11 @@#define _STK_LIM (8*1024*1024)
Quoted 13 lines
linux/resource.h line 65
Quoted 9 lines
linux/resource.h renamed from linux/resource.h.orig +4
-3/* -* GPG wants 32kB of mlocked memory, to make sure pass phrases -* and other sensitive information are never written to disk. +* The biggest widespread mlocked memory consumer is +* gnome-keyring-manager. It needs 256kB to make sure SSH/GPG +* passphrases and network passwords are never written to disk. */ -#define MLOCK_LIMIT (8 * PAGE_SIZE) +#define MLOCK_LIMIT (64 * PAGE_SIZE)gee, it seems rather arbitrary. Perhaps we should have set it to zero on day one to _force_ distributors to set an appropriate
RLIMIT_MEMLOCKin init.
Yes, it is fairly arbitrary. The motivation was gpg, but in fact when the patchset started gpg had already changed from 1 page to 8 pages.
http://thread.gmane.org/gmane.linux.kernel/222613/focus=222681
Quoted 3 lines
We can do this of course, but does it actually help anything? Perhaps it's actually a bad thing, permitting userspace developers to rely upon kernel defaults rather than setting things they way they should be set?
We don't want to keep changing at whim of random apps, agreed. Feels like a distro issue, since kernel can't even know what apps might run, and using 8 pages was just a courtesy hint to distros.
thanks,
-chris