Re: Heads-up / for discussion: dnf not working with 1G of RAM or less

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30/08/2022 15:48, Chris Murphy wrote:

The built-in default for cryptsetup on Fedora is LUKS2 which uses
argon2id with parameters:
	Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4

This is maximum, it is decreased according to benchmark during format.


It is possible to specify a different memory requirement at luksFormat
time. But I'm not sure if there's any warning emitted by cryptsetup if
there's significant memory pressure, i.e. high potential that a future
Fedora might fail to open this volume.

But yeah, if we have use cases where an encrypted image is created on
a system or in a container with plenty of memory, thus the high
memory requirement of the default applies, but then is later used
with libguestfs in a container or VM with less memory available, it's
a possible problem. I'm not really sure what the resolution for this
is though. We'd either have to change the cryptsetup default to
something like 512MB Fedora wide, or the burden is on the create time
sysadmin to override the Fedora default.

Please do not change defaults. If you prepare an image on some different system,
you have to always think about setting parameters for the target.

Cryptsetup will never use more that half of physical memory, it works perfectly fine with
small memory systems like RPi - just you need to format it there (or decrease parameters
if formatted elsewhere).

Also you can use luksChangeKey later to decrease costs.
For very limited systems it makes more sense to switch to older PBKDF2 anyway
(losing some bruteforce resistance).

What is the real problem with cryptsetup on systems with low memory is that it locks
all used memory and that includes all loaded libraries - and this often kicks OOM killer.
That will change in the next release where we removed that problematic mlockall() behavior.

... but the thread was about dnf and there it really does not make sense to eat such amount
of memory... :)

Milan
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux