[pkg-cryptsetup-devel] Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Guilhem Moulin]

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 <guilhem at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20190314/ed2dbeea/attachment.sig>