Locked memory limits are too low

[Thomas Daede]

For Fedora Workstation, the current limit on mlock()ed memory per user
is 64kiB, which less than what some applications need.

In particular, Bitcoin Core uses mlock() to prevent private keys from
being swapped to disk. The total size of the wallet keys can exceed 300kB.

Audio is another use case that uses mlock() to prevent skips. Fedora
already has special cases for some apps such as jack, which it gives 4GB.

It looks like another custom rule was given to qemu recently:
https://bugzilla.redhat.com/show_bug.cgi?id=1293024

The reason for the restriction is presumably an anti-DoS measure for
multi-user systems. It's not really clear where the 64kiB value came
from though - it seems like it could be much, much higher.

Thoughts on raising the value?

- Thomas

[Lailah]

Hello!

I think it's reasonable to raise the value, not sure how much, but
definitely should be higher.


Cheers,
Sylvia


On Tue, 2016-09-20 at 00:00 -0700, Thomas Daede wrote:
>  > For Fedora Workstation, the current limit on mlock()ed memory
> per 
user
>  is 64kiB, which less than what some applications need.
>  
>  In particular, Bitcoin Core uses mlock() to prevent private keys from
>  > being swapped to disk. The total size of the wallet keys can exceed 
300kB.
>  
>  Audio is another use case that uses mlock() to prevent skips. Fedora
>  > already has special cases for some apps such as jack, which it gives 
4GB.
>  
>  It looks like another custom rule was given to qemu recently:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1293024
>  
>  The reason for the restriction is presumably an anti-DoS measure for
>  multi-user systems. It's not really clear where the 64kiB value came
>  from though - it seems like it could be much, much higher.
>  
>  Thoughts on raising the value?
>  
>  - Thomas
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Björn Persson]

Thomas Daede <bztdlinux(a)gmail.com&gt; wrote:
>  The reason for the restriction is presumably an anti-DoS measure for
>  multi-user systems. It's not really clear where the 64kiB value came
>  from though - it seems like it could be much, much higher. 
How about 1% of the total system memory? That would be tens of megabytes
per user on modern workstations, and it would still take many
cooperating users to cause any denial of service.

Björn Persson

[Michael Catanzaro]

On Tue, 2016-09-20 at 00:00 -0700, Thomas Daede wrote:
>  For Fedora Workstation, the current limit on mlock()ed memory per
>  user
>  is 64kiB, which less than what some applications need. 
Could this be why memory locking in seahorse/gnome-keyring has been
broken for years?

[Lailah]

I think yes, that's the reason.  Besides, I agree with Björn about
setting a 1% of the total memory.

Cheers, 
Sylvia
On Tue, 2016-09-20 at 09:40 -0500, Michael Catanzaro wrote:
>  On Tue, 2016-09-20 at 00:00 -0700, Thomas Daede wrote:
>  > For Fedora Workstation, the current limit on mlock()ed memory per
>  > user
>  > is 64kiB, which less than what some applications need.
>  
>  Could this be why memory locking in seahorse/gnome-keyring has been
>  broken for years?
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Joachim Backes]

On 09/21/16 08:31, Sylvia wrote:
>  I think yes, that's the reason.  Besides, I agree with Björn about
>  setting a 1% of the total memory. 
The command "ulimit -l ..." lets you control such a limit. See command 
ulimit -a:

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31723
*max locked memory       (kbytes, -l) 64*
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31723
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimite

Kind regards

Joachim Backes


-- 

Fedora release 24 (Twenty Four)
Kernel-4.7.4-200.fc24.x86_64


Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
http://www-user.rhrk.uni-kl.de/~backes/

[Richard W.M. Jones]

On Wed, Sep 21, 2016 at 09:27:25AM +0200, Joachim Backes wrote:
>  The command "ulimit -l ..." lets you control such a limit.
> See
>  command ulimit -a: 
I think everyone's well aware of that.

That doesn't help when we were trying to run ppc64 qemu instances,
since those were launched from libvirtd, and therefore from systemd
(see the bug I filed which the original poster linked to).

It also shouldn't be necessary to have to faff around with memory
limits to do ordinary operations like starting a VM or trying to use
GNOME keyring.  The 64K limit is obviously much too low.

In answer to the original poster, this limit comes from the kernel
(include/uapi/linux/resource.h MLOCK_LIMIT), so I think we need to
persuade the kernel maintainers to fix this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Michael Catanzaro]

On Wed, 2016-09-21 at 13:29 +0100, Richard W.M. Jones wrote:
>  It also shouldn't be necessary to have to faff around with
> memory
>  limits to do ordinary operations like starting a VM or trying to use
>  GNOME keyring.  The 64K limit is obviously much too low. 
Oh, GNOME keyring still works mostly fine, it just fails to lock the
memory to prevent it from being paged to disk. It only really matters
if you're running some ultra-secure military/government stuff, but it's
not how it was designed to work.

Michael

[Björn Persson]

Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  Oh, GNOME keyring still works mostly fine, it just fails to lock the
>  memory to prevent it from being paged to disk. It only really matters
>  if you're running some ultra-secure military/government stuff, but it's
>  not how it was designed to work. 
Although I can't find a source now, I seem to recall that GnuPG recently
stopped using special memory-locking widgets for its passphrase entry
dialog. One of the reasons mentioned was that mlock doesn't add much
security because hibernation will write even locked memory to the disk.

I think encrypting the swap partition (and the rest of the disk) is a
better way of protecting secrets. Ultra-secure military stuff should
probably just have enough RAM and no swap partition.

mlock seems better suited for time-critical algorithms, like preventing
skips in audio like Thomas mentioned. The limit should be chosen with
that kind of usage in mind.

Björn Persson

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 21 September 2016 at 18:05, Björn Persson wrote:
>  Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  > Oh, GNOME keyring still works mostly fine, it just fails to lock the
>  > memory to prevent it from being paged to disk. It only really matters
>  > if you're running some ultra-secure military/government stuff, but it's
>  > not how it was designed to work.
>  
>  Although I can't find a source now, I seem to recall that GnuPG recently
>  stopped using special memory-locking widgets for its passphrase entry
>  dialog. One of the reasons mentioned was that mlock doesn't add much
>  security because hibernation will write even locked memory to the disk. 
When using SecureBoot, hibernation is disabled, so only suspend-to-RAM
might be a concern.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Orcan Ogetbil]

On 20 September 2016 at 03:00, Thomas Daede wrote:
>  For Fedora Workstation, the current limit on mlock()ed memory per
> user
>  is 64kiB, which less than what some applications need.
>
>  In particular, Bitcoin Core uses mlock() to prevent private keys from
>  being swapped to disk. The total size of the wallet keys can exceed 300kB.
>
>  Audio is another use case that uses mlock() to prevent skips. Fedora
>  already has special cases for some apps such as jack, which it gives 4GB. 
Note that there is a bug in Gnome Terminal [1] that overrides the
ulimit settings (e.g. for jack), which may be unknown to some.

Orcan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1364332