Are these installs with zkey/paes or without? Because, in Ubuntu, when zkey was introduced I have reverted the s390-tools upstream change to lower the argon2i settings. Due to my lack of understanding of the security features there. And later, we have made similar choices for TPM backed encryption elsewhere on the Ubuntu platofrm. Thus for example, for zkey/paes Imho argon2i should be used, but with a lower benchmark criteria capped at 200ms trial, instead of the builtin default of 2000ms trial. Otherwise, the RAM requirements to dump back onto paes/zkey encrypted volume will ever grow with the machine RAM size.
To test this out, install the system with little ram (ie. 1GB), then deactive, bump ram to 16GB. And I suspect that kdump to zkey/paes volume will then just work. For non-protected (no zkey/paes) encryption with just passthrases, the argon2i is the only protection we can provide, and yes it will always run install time benchmark and will always use ever increasing amount of ram to perform unlock. If we want to always have kdump working onto non- protected zkey/paes drives, we must introspect the luks volume argon2i benchmark details and base the reserved RAM off that. Because in theory, some future cryptsetup might change the benchmark, and thus result in different amount of RAM requirement to unlock the drive. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1877533 Title: [20.10 FEAT] Increase the crashkernel setting if the root volume is luks2-encrypted Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: In Progress Status in linux source package in Focal: Invalid Status in makedumpfile source package in Focal: In Progress Status in linux source package in Groovy: Invalid Status in makedumpfile source package in Groovy: In Progress Bug description: Description: In case the volume containing the root filesystem is encrypted using LUKS2 the memory used while unlocking the volume may exceed the size allocated to the kdump kernel. This will lead to a failure while processing kdump and the dump file will not be stored. Unfortunately, this condition may not be detected by a client before a problem occurs. The request is to have the kdump package installation script check for LUKS2 encryption (more precisely for Argon2i PBKDF, which is the root cause of the high memory usage). If the condition is met, the installation procedure should increase the crashkernel parameter to a higher value (>=512M)or issue a warning, if the system memory is insufficient to reserve enough crashkernel memory. Business Case: Pervasive Encryption and Secure Execution require encryption of the filesystems in order to keep customer data secure at all times. With the increasing usage of these technologies, the number of kdump will rise too, typically at inconvenient times, when the kdump is triggered due to a real customer issue. With the suggested change, the number of customer complaints and effort to handle them will be reduced. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877533/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
