[dm-devel] [dm-crypt] dm-integrity standalone - lack of metadata

[Milan Broz]

(added cc to dm-devel annd Mikulas)

Hi,

On 06/24/2018 11:53 AM, Harald Braumann wrote:
> Hi!
> 
> I'm using the dm-integrity target standalone with crc32c for component
> devices of a RAID. I don't use journaling, because the perfomance hit
> is too big and I don't really need it in that case.
> 
> I want to automatically activate these targets using udev
> rules (see below). However, the superblock lacks some crucial
> information:


yes, I agree. The reason is that dm-integrity was in the first
place designed for authenticated encryption (to store auth tags).
Then additional metadata ia stored in LUKS2 header.

For the rest I just I have not enough energy (and real-world use cases)
to convince Mikulas that we need attributes below in superblock (as the dm-integrity
code is written mostly by him).
At least for the algorithm I mention this idea several times ;-)

There are some patches for dm-integrity targeted to 4.19 floating around,
so let's add these ideas to the mix.

> - Integrity algorithm
> The algorithm is not stored in the superblock and so I have to use
> crc32 hard-coded in my udev rule. This is of course no general
> solution. I don't quite understand why it is not stored in the
> superblock. Is there a technical reason for that?
> 
> - Journal mode
> I open the integrity devices without journaling. But again, that's
> hard-coded and it would a be problem if I had other devices, where I
> actually want journaling. It would be nice, if the superblock
> contained a use_journal flag so the default could be configured on the
> device itself.
> 
> - UUID/label support
> Not strictly required for my use case, but would be nice for
> persistent naming.
> 
> While playing around with that, I also noticed that integritysetup
> format is extremly slow (this is on an HDD):
> 
> integritysetup format /dev/sdb2 -v --integrity crc32c --sector-size
> 4096
> => 39.6 MiB/s

This can be perhaps fine-tuned, but for standalone integrity I expect
we will use internal wipe, so this will be just fallback.
See https://www.redhat.com/archives/dm-devel/2018-June/msg00089.html

> Format with --no-wipe, open the target and use dd:
> dd if=/dev/zero of=/dev/mapper/int bs=1M
> => 63 MiB/s
> 
> Same as above, but opening without journal (which really isn't
> required for that step, even if the final target should be journaled):
> => 135 MiB/s

Internal wipe also uses activation without journal, it is slow probably
because we use direct-io (can you add oflag=direct to your dd command?
Is it the same speed as integritysetup wipe?)

> I have absolutely no problem with using the dd method, but it kind of
> makes the built-in format method redundant. 
> 
> Best regards
> harry
> 
> /etc/udev/rules.d/70-dm-integrity.rules:
> 
> ACTION!="add", GOTO="dm_integrity_end"
> SUBSYSTEM!="block", GOTO="dm_integrity_end"
> ENV{ID_FS_TYPE}!="DM_integrity", GOTO="dm_integrity_end"
> 
> RUN+="/sbin/integritysetup open $devnode $kernel-integrity --integrity crc32c --integrity-no-journal"
> 
> LABEL="dm_integrity_end"

This is not the best way - integritysetup itself need udev synchronization, so it will
race here with udev.

I think we need similar system like /etc/crypttab (or extend crypttab of integrity targets).

Milan