From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] dm-crypt on top of DRBD for live migration
Date: Wed, 7 Dec 2011 17:55:52 +0100 [thread overview]
Message-ID: <20111207165552.GA12508@tansi.org> (raw)
In-Reply-To: <CAJT7rVJupE9p2+A0i-chWVQW=jM_XaH9BMy0LqnV9ts8XfaGmQ@mail.gmail.com>
I think CPU-load should only be a secondary consideration.
On the placement of dm-crypt, my intuition would be to place
it as close to the storage as possible as it works on sector
layer, and regard DRBD as sort-of part of the buffer-cache.
I may be wrong. Milan is the person that should know.
An other aspect is that when placing encryption above BRDB, then
the traffic over the network is also encrypted. To me,it does not
make a lot of sense to encrypt data on disk, but put the same
data unencrypted over a network, even if it is a physically
separated network. So with dm-crypt below DRBD, you need to encrypt
the data 3 times: 1x local 1x transport and 1x remote, while
with dm-crypt above BRDB, you only need to encrypt once.
Should the both placents be fine, then definitely place it
above. Mirroring a dm-crypt or LUKS container should
not cause security problems in itself, two identical containers
with the same key(s) should in fact be a tiny bit more secure
than two containers with different keys and the same data.
(with tiny = does not matter in practice). And with link
encryption in addition, you need to trust 2 mechanisms,
namely the link encryption in addition. That does increase
the attack surface considerably.
On the migration issue, I do not understand the question.
What is your concern here?
Arno
On Wed, Dec 07, 2011 at 01:30:37PM +0100, Berengar Lehr wrote:
> We want to use LVM, dm-crypt and DRBD in a 2-machine setup for KVM.
>
> We think, a proper setup could be something like this (dm-crypt below DRBD):
>
>
> ?? ??Machine 1 ?? ?? ?? ?? ?? ?? ?? Machine 2
>
> ?? ?? ?? KVM ??-> -> -> -> -> -> ??KVM
> ?? ?? ?? ??| ?? (live migration) ?? ??.
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? .
> ?? ?? ?? DRBD - - - - - - - - - DRBD
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? |
> ?? ?? ?? LVM ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? LVM
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? |
> ?? ?? dm-crypt ?? ?? ?? ?? ?? ?? ?? ??dm-crypt
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? |
> ??Disk/Partition ?? ?? ?? ?? ??Disk/Partition
>
> The KVM guest machines should run on machine 1. Live migration to
> machine 2 should be supported.
>
> Using this setup, every write to DRBD would be (independently) crypted
> on both machines,
> leading to additional (unnecessary?) cpu load on machine 2 before live
> migrating, and additional
> cpu load on machine 1 after live migration.
>
> Could these additional cpu loads be avoided using a setup like this
> (dm-crypt in top of DRBD):
>
>
> ?? ??Machine 1 ?? ?? ?? ?? ?? ?? ?? Machine 2
>
> ?? ?? ?? KVM ??-> -> -> -> -> -> ??KVM
> ?? ?? ?? ??| ?? (live migration) ?? ??.
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? .(b)
> ?? ?? dm-crypt ?? ?? ?? ?? ?? ?? ?? ??dm-crypt
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? |(a)
> ?? ?? ?? DRBD - - - - - - - - - DRBD
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? |
> ?? ?? ?? LVM ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? LVM
> ?? ?? ?? ??| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? |
> ??Disk/Partition ?? ?? ?? ?? ??Disk/Partition
>
> In this setup, dm-crypt runs on both machines, too, but is not used on
> machine 2 until KVM
> guests send write-requests after the live migration. So crypting is
> done only by one machine
> at every time point.
>
> Is such a setup safe and stable?
>
> What about caching at points (a) or (b) on machine 2?
> Can KVM read cached, outdated data from dm-crypt after live migration?
>
> Is there a workaround?
>
> Thank You
> B. Lehr & M. M??ller
>
> --
> Mate ist gesunder Schlaf in Halbliterflaschen
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
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
next prev parent reply other threads:[~2011-12-07 16:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-07 12:30 [dm-crypt] dm-crypt on top of DRBD for live migration Berengar Lehr
2011-12-07 16:55 ` Arno Wagner [this message]
2011-12-12 8:51 ` Berengar Lehr
2011-12-12 14:11 ` Arno Wagner
2011-12-16 9:22 ` Milan Broz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111207165552.GA12508@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox