[dm-devel] LUKS2 - RAID0 - NVME : alignment issue

[Milan Broz]

Hi,

sorry for late reply...

On 28/10/2018 01:05, laurent cop wrote:
> Thank you all for your advises.
> 
> Meanwhile, I have read  Practical Cryptographic Data Integrity Protection with Full Disk Encryption Extended Version (1 jul 2018). Very interesting publication. :-)

Thanks. My major intention here is to demonstrate that we need authenticated encryption (AEAD) in future instead of current length
preserving encryption that is not able to provide even trivial integrity protections.

But as you already found, dm-integrity is far from ideal in some situations.
Anyway it is something to play with... and improve it in future.

> 1) Performances seems pretty correct for linear access write 4k blocks NO JOURNAL. Nevertheless, you don't indicate how you realise this test (cp, dd, fio tool...?).

It was just basic linear access that can be simulated with dd as well.
I used my code https://github.com/mbroz/dm_int_tools (that was later used in cryptsetup to wipe device).

Device was activated by cryptsetup (for no journal with option --integrity-no-journal) and then accessed
by the tool mentioned above.

In short, read test used for 4k and no-direct mode)
  # integrity_check check -n -b 8 <device>

and write test
  # integrity_check format -n -b 8 <device>

Time is measured in the test program using gettimeofday() (see code).
(The script also used /usr/bin/time, this way we found stupid mistakes like missing fsync() etc :-)

I think I removed more info from paper and forgot to put it back in extended version, sorry.

Anyway, the kernel evolves very quickly (specifically for NVME devices) so any comparison with older
version is misleading now, it need new tests.

Ondra (while working on his master thesis) had some benchmark scripts here
https://gitlab.com/omos/dm-crypt-test-scripts

(I would like to integrate dm-crypt/dm-integrity benchmarking to some better usable package...)

> 2) I will reconsider doing again my stack. (No datas on it) Have you
> any advises related to fs, RAID0, luksformat (type luk2) creation?
> Indeed, I don't clearly understand this point : /"dm-integrity
> interleaves data and metadata and consequently data are not aligned
> on raid stripe boundary."/ According to what I inderstand this will
> kill my RAID0 main goal for getting fast performance.
Unfortunately, yes. I would like to have some dm-integrity mode that is aligned though.
I added mention to release notes for cryptsetup 2.0.5 about performance problems.

We (DM developers) need to discuss what can be done with these configurations & dm-integrity in future...

TBH, do not expect super-fast performance with dm-integrity. The goal was
to prove it can be done, it can be used with common scenarios, but the performace
penalty for sector interleaving and journal will be always there.

> 3) I want integrity features and I want to try the no journal option for performance gain. How to use it  ?
> cryptsetup -v luksFormat --type luks2 /dev/md127 --cipher aes-gcm-random --integrity aead  /--integrity-no-journal/

Yes, --integrity-no-journal is the flag. Use it with open (luksOpen) command.

If open command is used with --persistent, it should be written to LUKS2 metadata and used later automatically.
Unfortunately, I just found a bug for persistent setting for this specific option...
So for now you have to use it on commandline always. I'll fix this.

> 4) I am not sure to understand the relation between sector size of
> each layer of the stack as we introduce a layer (dif) with metadata
> under dm-crypt layer and above storage devices. Does 4096 bytes must
> be choosen for all layers? *--sector-size <bytes>* Set sector size
> for use with disk encryption. It must be power of two and in range
> 512 - 4096 bytes. The default is 512 bytes sectors. This option is
> available only in the LUKS2 mode.
...

The sector size should be the same for all layers. 
For dm-crypt 4k sector should improve performance as well
(by default it uses 512 byte sector).

Anyway, thank you for testing and using it!

Regards,
Milan