Re: dm-crypt overhead

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Milan,

thank you very much for a useful and informative answer. I'll have a look at this.

Maybe I have a one more question: which part requires the 4.12+ kernel?

I'm afraid I'll have to backport the changes if we decide to proceed.

Thanks again,
Lukas

2018-03-01 18:41 GMT+01:00 Milan Broz <gmazyland@xxxxxxxxx>:
On 03/01/2018 03:59 PM, Lukáš Pohanka wrote:
> thanks for clarifications. Unfortunately, we are currently
> constrained to use only dmsetup and cannot provision the target
> device with cryptsetup. Thus we cannot use LUKS, only plain
> dm-crypt. Hopefully it will change in the future. However, does this
> mean there is currently no chance of using any form of authenticated
> encryption in our case?

Hi,

you can use it just with dmsetup, but there are several steps that
are not obvious (for example formatting dm-integrity device requires
two steps etc).
But it is definitely something I would not suggest :-)

So in general (I intentionally do not want to paste exact commands,
you have to be sure what you are doing here):

- you will need recent-enough kernel (4.12+)

Formatting (only once):
- prepare block device, wipe first megabytes with zeroes
- activate dm-integrity device (using dm-setup) with size 8 sectors,
and with proper parameters (mainly tag size per sector) you need (do not use internal hash)
- deactivate dm-integrity device

(Steps above will format the device in-kernel, writing integrity superblock.)

Later use (normal activation):
- activate dm-integrity device with proper data size (read from dm-integrity
superblock). (In future it will be simpler.)
- activate dm-crypt device with proper parameters above the dm-itegrity device
(with proper authentication mode parameters, tag size, random IV etc)

- Profit. (Use top-level dm-crypt device as usual.)

(You should probably overwrite the whole device using direct-io on the first
activation to initialize auth.tags.
Otherwise any reads, including page cache, will fail on -EILSEQ - integrity error.)

The above is in principle what crypstestup is doing for you.

Authenticated filesystem is definitely better idea, but because I can
guess in which environment you are trying to implement
this I guess it is not an option...

Milan

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux