On 1/17/2022 12:50 PM, Milan Broz wrote:
On 17/01/2022 08:52, Christoph Hellwig wrote:
On Fri, Jan 14, 2022 at 09:51:20PM +0100, Milan Broz wrote:
I think dm-crypt should stay as SW crypto only (using kernel crypto
API,
so HW acceleration is done through crypto drivers there).
A cleaner solution is to write a much simpler new dm-crypt-inline
target,
which will implement only inline encryption.
(And userspace can decide which target to use.)
Code should be just an extension to the dm-linear target, most
of dm-crypt complexity is not needed here.
Why do we even need a dm target for this as well? There should be no
need to clone or remap bios, so I think hamdling inline crypto should be
just a small addition to the core block layer.
Well, yes, that was my question too :-)
Maybe there is need to have some new userspace utility to configure that
but otherwise I think that for inline encryption device mapper layer
only increases complexity and reduces IO performance.
Regarding performance degradation, I added only one if condition at the
data path (inside #ifdef).
Could anyone elaborate what it the reason for such DM extension?
Compatibility with existing encryption/key management tools (like LUKS)?
Easy support in LVM? ...
DM extension gives us several capabilities:
1. Use the Linux keyring and other key management tools.
- I used "keyctl padd user test-key @u < /tmp/wrapped_dek" at my tests
2. Split a single block device into several DMs. Allow us to use a
different encryption key and encryption mode per DM.
3. Replace a key during I/O by using "dmsetup suspend /dev/dm-0" and
"dmsetup resume /dev/dm-0".
Milan
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
