Re: [dm-crypt] concurrency

[Hugh Bragg <hughbragg@dodo.com.au>]

On 28/03/2016 2:52 AM, Michael Kjörling wrote:
> On 27 Mar 2016 00:50 +1000, from hughbragg@dodo.com.au (Hugh Bragg):
>> Should I be able to use Luks concurrently on a shared filesystem from
>> different computers?
>> Attempts so far have failed with writes not being seen from the other
>> computer until both computers remount the filesystem or reboot.
> As a thought experiment, try removing LUKS from the equation. For the
> purposes of what you seem to be asking, LUKS is just a part of the
> physical storage layer.
>
> Instead of [unencrypted physical storage device + LUKS container]
> providing the feature "encrypted storage of user-selected data",
> consider the case [self-encrypting physical storage device] which
> provides the same feature "encrypted storage of user-selected data"
> but this time without involving LUKS or dm-crypt.
>
> _Would you expect what you have in mind to work after making that
> single change?_
Yes, in the case of virtualbox storage, if the disk was self encrypting
it would work.
Sounds interesting. Are there any opensource tools that can do this? I
was expecting lvm on luks on a virtual disk to do this, but it failed.
For network shares, this wouldn't be any good. I wouldn't want to store
the key on the cloud server.
> If not, then there is no reason to expect it to suddenly start working
> when you introduce an additional component (LUKS) into the _physical_
> storage stack. And as far as the file system is concerned, LUKS very
> much _is_ a part of the physical storage stack. (There would be
> nothing _architecturally_ weird with a HBA that itself runs LUKS and
> exposes the decrypted container while writing the encrypted data to
> the actual physical storage device. It would come with some fairly
> serious design challenges if one wants to make it secure, however.)
>