Re: [linux-lvm] Can I combine LUKS and LVM to achieve encryption and snapshots?

Dne 27. 09. 23 v 15:45 Jean-Marc Saffroy napsal(a):
> On Wed, Sep 27, 2023 at 11:58 AM Zdenek Kabelac
> <[email protected]> wrote:
>>
>> Dne 27. 09. 23 v 1:10 Jean-Marc Saffroy napsal(a):
>>> Hi,
>>>
>>> On Tue, Sep 26, 2023 at 10:00 PM Zdenek Kabelac
>>> <[email protected]> wrote:
>>>> Yep typical usage is to encrypt underlying PV - and then create LVs and its
>>>> snapshots on encrypted device.
>>>
>>> Sure, I'd do that in other circumstances.
>>>
>>> But in my case it would just be a waste: I am replacing several disks
>>> on a desktop computer with a single 2TB NVME SSD for everything. Only
>>> /home needs to be encrypted, and it's tiny, like 100-200GB. Going
>>> through encryption for most application I/Os would use CPU time and
>>> increase latency with no benefit.
>>>
>>> So I prefer to manage available raw (un-encrypted) space with LVM.
>>>
>>> Now, I also need to do backups of /home, and that's why I want
>>> snapshots. But that first layer of LVM would only show a snapshot of
>>> an encrypted volume, and the backup job shouldn't have the passphrase
>>> to decrypt the volume.
>>>
>>> Which is why I'm trying to find a way of doing snaphots of an "opened"
>>> LUKS volume: this way, the backup job can do its job without requiring
>>> a passphrase.
>>
>> well that's where you will considerably 'complicate' your life :)
>> As you would need to 'orchestrace' this yourself with 'dmsetup' usage.
> 
> If you mean that I'd have to script a few things, then I am perfectly
> fine with that.
> 
>> running 'dmsetup suspend' on your home device,
>> that taking a snapshot of your underlying  LV.
> 
> What is the role of "dmsetup suspend"? I am having trouble finding
> decent documentation about its purpose and how it's related to
> snapshots. I did not need it in my experiments, so I am curious.
> 


Suspend is freezing device's i/o queue  (together with freezing FS layer - so 
the snapshot should be easily mountable without requiring extensive fsck 
operation as it would be missing some important metadata to be written on disk)
So the goal of a suspend is to take a 'good point in time' where the content 
of snapshot is having all 'committed' transaction on disk in valid state.

Clearly that needs a 'top-level device - which would be a crypto DM in your 
case - and goes via 'tree' down to PV level.

Clearly lvm2 does this while taking snapshot  - and you can easily observe 
that 'magic' if you read carefully  -vvvv  trace of a command.

Then your script needs to replicate this at script level.
Fun would begin once you would start to resolve all the possible error paths...


> If I were okay with giving the passphrase to my backup script, then I
> could simply have the backup script create its snapshot from the
> encrypted LV, and I wouldn't have started this thread in this case.
> :-)

Maybe you could drop your whole disk encryption idea then and just use some 
encrypted tarballs - since if you tend to place passwords into scripts - it's 
kind of big security hole....

If all you want to have is encrypted files on disk - there are probably more 
easier approaches with the use of encrypted filesystems...

>> But the level of complexity here is rather  high - this it might be actually
>> way easier to just 'partition' your device for  'encrypted'  and unecrypted'
>> parts and use 2 PVs for 2 VGs....
> 
> But then I can't resize the encrypted volume/partition.

Not sure how often do you need to do that - surely a 'split' between those 2 
partitions is a decisive point...

But then whatever you do within those VG is fully resizable as before.


> It seems LVM cannot do it directly, but it becomes possible (at least
> in my simple tests) if I use a bunch of dmsetup commands, or if I use
> the decrypted device as the PV for a new VG.
> 
> But I don't know if these approaches are safe to use, and that is what
> drove me here.
> 
> In the mean time, I found this page:
> https://access.redhat.com/articles/2106521
> 
> Apparently, LVM on LUKS on LVM would be case of "LVM recursion", and
> so not entirely unheard of.
> 
> Does anyone here have experience with "LVM recursion"?

lvm2 does not advice to use 'stacking'  - it's very complicated and in some 
way inefficient - it's always true the less layers -> the better the 
performance will be (especially true with modern NVMe devices...)

And lvm2 itself does NOT support/count with recursion - so while it may appear 
to be working - there will be corner cases with unresolvable problems - 
although this is mostly an issue if you are running your system from such 
'stacked' solution (causing deadlocks...)

Anyway - placing VG on top of another VG is always good to avoid and use only 
as a last resource if there is no better approach existing.

Regards

Zdenek

_______________________________________________
linux-lvm mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/