[dm-crypt] btrfs

[dm-crypt] btrfs

[M Thomas Frederiksen]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

I've got 4 HDs, and would like encrypted btrfs.  I'm considering installing
Kubuntu 10.10.  As btrfs doesn't support encryption yet, I'd have to use
LUKS underneath.  Is this likely to be a decent setup, or would I be well
advised to wait for btrfs to support encryption natively?

-- 
Cheers,
~Thomas

[-- Attachment #2: Type: text/html, Size: 358 bytes --]

Re: [dm-crypt] btrfs

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Wed, 2010-10-27 at 08:54 -0400, M Thomas Frederiksen wrote:
> I've got 4 HDs, and would like encrypted btrfs.  I'm considering
> installing Kubuntu 10.10.  As btrfs doesn't support encryption yet,
> I'd have to use LUKS underneath.  Is this likely to be a decent setup,
> or would I be well advised to wait for btrfs to support encryption
> natively? 

In principle it's a good idea to use dmcrypt/LUKS IMHO (not sure whether
I like the idea to put encryption directly in the fs),... nevertheless,
there once used to be (IIRC) a note in the btrfs wiki, that it was for
some reason insecure/buggy/whatever to be used with dm-crypt...

So perhaps better ask them too.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] btrfs

[Arno Wagner]

On Wed, Oct 27, 2010 at 02:59:17PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2010-10-27 at 08:54 -0400, M Thomas Frederiksen wrote:
> > I've got 4 HDs, and would like encrypted btrfs.  I'm considering
> > installing Kubuntu 10.10.  As btrfs doesn't support encryption yet,
> > I'd have to use LUKS underneath.  Is this likely to be a decent setup,
> > or would I be well advised to wait for btrfs to support encryption
> > natively? 
> 
> In principle it's a good idea to use dmcrypt/LUKS IMHO (not sure whether
> I like the idea to put encryption directly in the fs),... nevertheless,
> there once used to be (IIRC) a note in the btrfs wiki, that it was for
> some reason insecure/buggy/whatever to be used with dm-crypt...
> 
> So perhaps better ask them too.
> 
> 
> Cheers,
> Chris.


Currently there are kernel issues with write synchronisation.
These may affect a combination of any filesystem with LUKS/dm-crypt
more strongly than the filesystem alone. Fortunately (after a very
long time ignoring it) the kernel developpers have started to do 
something about this issue. It is basically the same thing you get
when writing a very large file to disk and everything starts to 
crawl. Or a smaller file to a slow device and dm-crypted/LUKSed
devices are slower.

2.6.36 is already a lot more responsive under these circumstances,
at least for the large file situation.
2.6.37 is expected to improve the situation further.

There is no reason why there should be any security issues, btrfs
cannot break LUKS/dm-crypt security. 

It may be buggy, but btrfs is still new and likely buggy itself. 
I would not trust if for at least another year.

If you can reliably detect corruption and have good backups,
just try it.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] btrfs

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Wed, 2010-10-27 at 16:10 +0200, Arno Wagner wrote:
> There is no reason why there should be any security issues, btrfs
> cannot break LUKS/dm-crypt security. 
I meant "data security" ... but just referring to that via security is
probably very ambiguous on a list like this ;)

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] btrfs

[Arno Wagner]

On Wed, Oct 27, 2010 at 04:15:01PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2010-10-27 at 16:10 +0200, Arno Wagner wrote:
> > There is no reason why there should be any security issues, btrfs
> > cannot break LUKS/dm-crypt security. 
> I meant "data security" ... but just referring to that via security is
> probably very ambiguous on a list like this ;)
> 
> Cheers,
> Chris.

The word you are looking for is "reliability" or "safety"... ;-)

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] btrfs

[Paul Dugas]

On Wed, Oct 27, 2010 at 10:10 AM, Arno Wagner <arno@wagner.name> wrote:
> Currently there are kernel issues with write synchronisation.
> These may affect a combination of any filesystem with LUKS/dm-crypt
> more strongly than the filesystem alone. Fortunately (after a very
> long time ignoring it) the kernel developpers have started to do
> something about this issue. It is basically the same thing you get
> when writing a very large file to disk and everything starts to
> crawl. Or a smaller file to a slow device and dm-crypted/LUKSed
> devices are slower.
>
> 2.6.36 is already a lot more responsive under these circumstances,
> at least for the large file situation.
> 2.6.37 is expected to improve the situation further.

Where can I learn more about the specifics and implications of these
issues?  I posted a few weeks ago about some performance issues that
sound a lot like the symptoms you describe.  I've got an LUKS device
on a 2TB Ethernet SAN drive (ATA over Ethernet) that is painfully slow
when initializing and mkfs'ing; last try took 4+ days after a couple
crashes due to what appear to be an out-of-memory condition in the
kernel somewhere.  Once it finished, I tried copying a 1TB file to it
and that too ran for days before it mysteriously stalled after about
300GB.

Paul
--
Paul Dugas • Dugas Enterprises, LLC • Computer Engineer
Paul@DugasEnterprises.com • +1.404.932.1355

Re: [dm-crypt] btrfs

[Heinz Diehl]

On 27.10.2010, M Thomas Frederiksen wrote: 

> Is this likely to be a decent setup, or would I be well
> advised to wait for btrfs to support encryption natively?

It's up to you. I'd prefer LUKS/dmcrypt. 

Re: [dm-crypt] btrfs with raid5/6

[Markus Krainz]

> It's up to you. I'd prefer LUKS/dmcrypt.
So do I. But I have a related concern:

I currently do ext4 <-> dm-crypt <-> linux-software-raid <-> hdds

However Linux Software Raid (mdadm) does not protect you from silent 
data loss, because it does not store checksums in it's metadata.
So what mdadm does is, it compensates for failed devices, or blocks, if 
the device reports them as bad. But I can NOT correct data, that was 
e.g. corrupted by the SATA controller or backplane.
See http://neil.brown.name/blog/20100211050355 "Smart or simple RAID 
recovery??" for more information.

Btrfs (like ZFS) can be the solution here, as it stores CRC checksums 
with all data and metadata. RAID5 with protection from silent data loss 
is promised to be implemented in the future.
A setup on top of dm-crypt would look as follows:

btrfs <-> multiple dm-crypt partitions <-> multiple devices

However in the past I experienced very disappointing results, if raid is 
running on top of dm-crypt partitions.
If I remove hdds from such a setup the dm-crypt partition wont 
disappear. It won't propagate the error to the software raid on top of 
it (not familiar with the implementation details, maybe mdadm is to 
blame here).
And finally it won't even let itself be deleted without restart (I think 
the last issue has been fixed in the meantime).

I urge the dm-crypt developers to improve this situation with raid on 
top of dm-crypt, be it with mdadm or btrfs.
Solutions for other long-time annoying issues like insufficient 
threading support, and the lack of discard support, would be appreciated 
too. :P
I know the OSS pradigm is provide patches yourself. Would you be 
accepting patches?

Sincerly,
Markus