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

[Mikulas Patocka]

On Tue, 3 Jul 2018, Milan Broz wrote:

> On 06/25/2018 08:05 PM, Mikulas Patocka wrote:
> > On Sun, 24 Jun 2018, Milan Broz wrote:
> > 
> >> (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).
> > 
> > You can write whatever you want to the end of the superblock. If 
> > kernelspace allocates superblock entries from the beginning and userspace 
> > allocates them from the end, they won't cross each other.
> 
> This is really hackish solution :)

Then - there's an "offset" argument - you can use it and create your own 
superblock before the offset.

> I think the superblock should be either maintained inside kernel or in userspace.
> 
> Or at least kernel superblock should define area reserved for userspace
> (IOW the area that kernel guarantees to be never overwritten by kernel driver).
> 
> I really do not want to define any userspace-only attributes until there
> is some plan how (and if) to integrate plain dm-integrity devices.
> 
> Milan

Mikulas