Re: Locked memory limits are too low
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
On Wednesday, 21 September 2016 at 18:05, Björn Persson wrote: > Michael Catanzaro 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" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
Michael Catanzaro 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 pgpH81_wbJ8al.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
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 http://www-user.rhrk.uni-kl.de/~backes/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
Thomas Daede 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 pgpdv6XDiXVuQ.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Locked memory limits are too low
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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Locked memory limits are too low
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
