[PATCH] lib: Increase default memsize to 1280 (RHBZ#1837765).
Argon2 is the default LUKS Password-Based Key Derivation Function (PBKDF) for some new guests such as RHEL 8.2 and Fedora. It is designed to be "memory hard", meaning that by design it requires large amounts of memory, making it expensive to brute-force. Unfortunately the default for guests which had more than a few GB of RAM at install time is to require about 1 GB of RAM to decrypt the block device, which is considerably larger than the default available in the libguestfs appliance. To make it possible to open these encrypted disks we need to make the appliance larger. This could be done as a one-off, and the current workaround is simply to set LIBGUESTFS_MEMSIZE=2048 or a similar amount. However since we don't know in advance whether we could be dealing with an encrypted disk, partition, etc. or what PBKDF it uses, the only way to deal with this in all circumstances is to increase the default memsize. This commit increases it quite a lot (768 -> 1280) which is unfortunate. Note as there is some confusion on this point: Since libguestfs does not attempt to decrypt disks in parallel, you only need ~ 1GB in total, not per encrypted disk. For a reproducer, see: https://bugzilla.redhat.com/show_bug.cgi?id=1837765#c14 --- lib/guestfs-internal.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index ce6eb68e8..d7ec7215d 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -94,7 +94,7 @@ * creating device nodes. */ #ifdef __powerpc__ -# define DEFAULT_MEMSIZE 1024 +# define DEFAULT_MEMSIZE 1280 #endif /* Kernel 3.19 is unable to uncompress the initramfs on aarch64 unless @@ -103,12 +103,12 @@ * common on aarch64, treat this like the ppc case above. */ #ifdef __aarch64__ -# define DEFAULT_MEMSIZE 1024 +# define DEFAULT_MEMSIZE 1280 #endif /* The default and minimum memory size for most users. */ #ifndef DEFAULT_MEMSIZE -# define DEFAULT_MEMSIZE 768 +# define DEFAULT_MEMSIZE 1280 #endif #ifndef MIN_MEMSIZE # define MIN_MEMSIZE 256 -- 2.26.2
On Tue, Jun 30, 2020 at 05:42:29PM +0100, Richard W.M. Jones wrote:
Argon2 is the default LUKS Password-Based Key Derivation Function (PBKDF) for some new guests such as RHEL 8.2 and Fedora. It is designed to be "memory hard", meaning that by design it requires large amounts of memory, making it expensive to brute-force. Unfortunately the default for guests which had more than a few GB of RAM at install time is to require about 1 GB of RAM to decrypt the block device, which is considerably larger than the default available in the libguestfs appliance.
To make it possible to open these encrypted disks we need to make the appliance larger. This could be done as a one-off, and the current workaround is simply to set LIBGUESTFS_MEMSIZE=2048 or a similar amount. However since we don't know in advance whether we could be dealing with an encrypted disk, partition, etc. or what PBKDF it uses, the only way to deal with this in all circumstances is to increase the default memsize. This commit increases it quite a lot (768 -> 1280) which is unfortunate.
I guess if you really want to minimize overhead for people, then DIMM hotplug is the way to go. ie launch with small memory, but configure memory to allow hotplug of another GB. So you can launch the appliance normally, and when you see a disk using argon2, then hotadd the DIMM before decrypting. Whether that complexity is worth it though depends on how important it is to keep RAM of the appliance small. Having said all that, increasing the QEMU RAM size doesn't actually consume memory on the host unless the guest actually touches the memory pages or you've told QEMU to use hugepage or RAM pre-alloc. So mostly you'll just pay for the small kernel pagetable accounting eg with default libguesfs settings I see resident RAM of 200 MB setting LIBGUESTFS_MEMSIZE=2048 i see resident RAM of 220 MB setting LIBGUESTFS_MEMSIZE=20480 I see resident RAM of ~600 MB So I think you could easily afford to bump from 768 to 2 GB without worrying about impact on real RAM usage. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (2)
-
Daniel P. Berrangé -
Richard W.M. Jones