All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM
Date: Tue, 20 Sep 2011 13:47:24 +0200	[thread overview]
Message-ID: <20110920114724.GA21251@tansi.org> (raw)
In-Reply-To: <1316515022.7965.31.camel@zarniwoop>

On Tue, Sep 20, 2011 at 08:36:58PM +1000, Robbie Smith wrote:
[...]
> What are some potential worst-case scenarios? i.e. the system had a hard
> reset, either because the power got cut or (somehow) an application
> brought the system to a complete halt? How would this affect the
> encryption, and could it result in total data loss? 

The encryption can be established as long as the header and
at least on ekeyslot are intact. If you cut the power just in the
microsecond while a keyslot is written you would damage that
keyslot. If it was your only one and you do not have a header backup,
then you would have total data loss. That is the only scenario
I can think of. In normal operation, the header is not written.

With an SSD, things are a bit different. Due to the large
internal sector size, the header can be in a sector that
also has data that gets rewritten in it. As sectors are
always written completely, the header then is at risk whenever
that data gets rewritten.

Also keep in mind that HDDs have about a 5%/year rate of failure
(even if some vendors claim 0.5%, but that is under perfect
conditions). A backup of the data is non-optional. The
header-backup is just an additional precaution.

> The FAQ makes mention that the most frequent cause of data loss is
> either losing access to the keys or somehow corrupting the LUKS header.
> The former I can understand, and "common" sense would dictate to have a
> couple of backup keys in secure locations. I am at a loss though as to
> how someone could unintentionally corrupt the header though. 

This is from observations on the mailing-list. It happens pretty
often. And most people are surprised by it. 
 
> I'm inclined to set up my system with /boot and a LUKS partition, and
> then use LVM inside that, so if I decide to rearrange virtual partitions
> I won't run the risk of messing up the LUKS header. This also seems like
> the simplest setup.

Keep in mind that LVM adds to the complexity when you have to do
data recovery when something went wrong. Other that that it sounds
like a good approach.

> (I keep daily backups of $HOME and of essential system settings, the
> rest can be reinstalled if needed, but I'd prefer not to have to spend a
> few days recovering everything if I had a hard reset or something like
> that.)

You will not damage the encrypted data in normal operation.
All the header-damages reported were done during installation,
repartitioning, moving partitions, etc. 

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 

  parent reply	other threads:[~2011-09-20 11:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-20 10:36 [dm-crypt] (More) Questions about LUKS / LVM Robbie Smith
2011-09-20 10:52 ` Quentin Lefebvre
2011-09-20 11:47 ` Arno Wagner [this message]
2011-09-20 13:13   ` Milan Broz
2011-09-20 14:14     ` Arno Wagner
2011-09-20 14:52       ` Milan Broz
2011-10-03  6:17       ` Luca Berra
2011-10-03 10:55         ` Arno Wagner
2011-09-20 15:21   ` Alexander Koch
2011-09-20 16:12     ` Milan Broz
2011-09-20 17:41     ` Arno Wagner
2011-09-20 18:06       ` Karl O. Pinc
2011-09-20 18:19         ` Milan Broz
2011-09-21 10:22           ` Arno Wagner
2011-09-21 16:14             ` Dragan Milivojevic

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=20110920114724.GA21251@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.