Control: tag -1 + wontfix Control: tag -1 - moreinfo Control: severity -1 normal
On Thu, 14 Mar 2019 at 17:31:05 +0000, Dimitri John Ledkov wrote: > On Thu, 14 Mar 2019 at 16:55, Guilhem Moulin <guil...@debian.org> wrote: >> AFAICT it does. What I guess doesn't is if the machine's resources are >> significantly reduced between luksFormat/luksAddKey and luksOpen. > > I guess that is the reason here. Majority of IoT / pi / etc devices > might prepare rootfs / SDcard / golden image / etc on a bigger > developer machine, prior to flashing it onto SDcard to then deploy on > the target device. I see. > So the solution there is to run the benchmark on the device, once, > record parameters and use those when creating the golden image for > memory, threads and possibly iterations too? Yup, you can re-use the parameters from a previous benchmark run on the target system (where the volume will be unlocked) and use it to luksFormat elsewhere. This applies to PBKDF2 too by the way, though skipping this step doesn't have the same severity; for PBKDF2 the benchmark only affect the iteration time, so if the volume is formatted on a fast system, unlocking on a slower one will slower than it should be (but won't OOM). > I wonder if I should open a bug report in systemd, to potentially > execute luks2 unlock with some locking / sequentially. Seems sensible. > I guess this bug should be tagged wontfixing and lowered priority to > normal, or something. Alright :-) -- Guilhem.
Description: PGP signature