[dm-crypt] Several issues with cryptsetup 2.0.0
sven at eschenberg.eu
Sun Jan 14 19:47:11 CET 2018
Just some minor thoughts ...
Am 14.01.2018 um 18:18 schrieb Milan Broz:
> On 01/14/2018 02:21 AM, curve25519 at mailbox.org wrote:
>> Hi everyone,
>> 3. Why does cryptsetup luksFormat allow at max 1048576kb (~1GB) of
>> memory usage for Argon2? This seems incredibly low compared to the
>> parameter choice recommendations from the Argon2 RFC draft. Even if you
>> don't use those as defaults, why would you ever set an upper limit which
>> is way below the recommendations?
> This is very good question. It was my decision to internally limit it until
> we are sure how Argon2 behaves. It was introduced before the physical-memory
> limits and perhaps should be increased now.
> My major concern here is maintenance - there is a lot of systems that just will
> not have >1GB memory available. Unfortunately, in reality we see that Linux systems
> kill the process here (OOM) instead of returning -ENOMEM, so we cannot even print any
> useful messages. People will complain.
> I would also expect some strange process limits that various container or systemd
> services (and discussion with people developing these is not something I really enjoy TBH).
I bet they are very insightful - Anyway, so basicly there is no safe and
sane way, to find if there's enough (physical) mem for cryptsetup's
purpose. Then (IMHO) setting sensible default and max is unavoidable.
> I know it limits the Argon2 use and I plan to increase it. Perhaps we should make
> it configure time option.
And then, configured with one system in mind and used on another system,
this becomes a pitfall. Adding extra options gives choice, I welcome
this, but I don't see how this will help with the actual problem.
> I am not sure how the parameters in RFC draft were calculated, but IMO they are not
> usable in general with many of systems today.
> But you are right, this is something we should change.
Agreed, of course a solid mechanismn to capture the (available) size of
physical memory would be the better way, but I fear this won'T be easy
>> 4. Similar to the memory setting the thread count seems to be capped at
>> the number of processor cores, even tough the IRTF Argon Draft paper
>> explicitly uses twice the amount of cores in ALL examples on parameter
>> choice. Again, this might be acceptable as a default, but why is it a
>> hard limit? Even if there is a good reason to do so (I can't imagine
>> one), why is the user input silently ignored instead of throwing an
>> error as with the memory setting?
> The reason is similar to previous one - we set limits to be sane and if it works,
> we can slightly slow down it later.
> The user input should not be ignored if you have enough CPUs.
> (And I do not think it is good idea to use twice many parallel cost as physical
> CPUs, this will our bencmark calculate something completely different on systems
> where it has enough CPU and were it causes thread switch craziness.)
When core really means corethen 2 * #cores would be reasonable for
hyperthreaded cores. But again, that would be with a specific
configuration in mind, IMHO there's no gain going way beyond the number
of physical cores, when they are not hyperthreaded.
> Also it will behave differently on different architectures (for example CPU
> in Power systems is completely virtualized).
> So the truly answer: these were sane defaults I set, perhaps they are wrong and need
> to be updated. Just we need more people to use it to be sure we did not break anything.
> Maybe I am just too careful, dunno.
No, I don't think you are too careful. But that'S just my POV.
>> 11. The default numbers for --pbkdf-memory compared with the
>> defaults/minimums claimed on this list (e.g. 131072 kB vs 128MB) don't
>> match up, which seems to indicate Kibibytes, and Mebibytes were meant.
>> However kilobytes is used in the manpage and output. Could you enlighten
>> me if the base unit is actually kB or KiB?
> Every time I use SI term kibibytes, someone start to scream :-)
Honestly, the IEC/SI bin-prefix recommendations sound awfully indeed, no
wonder people tend to scream :-D.
> I think all printd numbers are in 2^x (1024) and not SI units (10^x), so only
> unit description is inconsistent. We should unify it in text.
When it comes to base 2 adressing, sizes with decimal prefixes are in
general rather unuseful. There's a reason JEDEC accepts kilo with 2^10
as a prefix, while SI and IEC get snotty about it.
But let's not start a flamewar on this, would not lead anywhere anyhow.
Let's rather define what is meat by KB (or whatever prefix/term should
be used) and then match all text up with it.
More information about the dm-crypt