Re: Data authentication for geli(8) committed to HEAD.

On Thu, Jun 08, 2006 at 07:41:13PM +0200, Ulrich Spoerlein wrote:
+> Pawel Jakub Dawidek wrote:
+> > One of the main design goals was to make it reliable and resistant to
+> > power failures or system crashes. This was very important to commit both
+> > data update and HMAC update as an atomic operation to the disk, so users
+> > don't have to fight with false positives.
+> 
+> Great stuff. I take this opportunity to hijack this thread and ask I
+> question that has been bothering me a long time now.
+> 
+> I have an external HDD that I initially attached via Firewire, but I've
+> since switched to USB, as our firewire subsystem is less than rock
+> solid. When configuring geli encryption on the drive, I made the folly
+> of using 4kB sectors, as this should improve performance. But, it has a
+> disastrous impact on data integrity if your system crashes.
+> 
+> Now, I don't know if I'm right with the following thoughts, so please
+> correct me if I'm wrong.
+> 
+> Consider an mtime or atime update. You need to update 4 bytes on the
+> disk, which will be accomplished by writes of 512 bytes. If the system
+> crashes in between (I'm not talking about power failures), the disk has
+> either updated the 512 bytes, or not. No harm done.
+> 
+> With 4096 byte sectors and unencrypted data, the hard disk will have
+> written/updated 512 or 1024, ... or the whole 4096 bytes. Since only 4
+> bytes needed to be changed, you either got these changes or not. No harm
+> done.
+> 
+> Now consider encryption with 4096 byte sectors. Whenever you twiddle one
+> bit, the whole 4096 byte sector changes completely. To leave the disk in
+> a consistent state, you always have to make sure, that the whole 8
+> 512-byte blocks are written to disk. If only a single 512-byte block is
+> not updated (due to kernel crashing because of that !_at_#^#$_at_ firewire),
+> the whole 4096 are useless. SoL.
+> 
+> The question really is, are 512 byte disk writes considered to be some
+> kind of "atomic" as it is the smallest disk block size? What does the
+> ATA subsystem do with writes of 4096? Are they completed atomically too,
+> or not?
+> 
+> Due to various kernel panics (no power failures involved!) I lost
+> several blocks of inodes on a 4096 byte sector geli mount. It's really
+> no fun, if fsck tells you that inodes 102340 - 109329 are lost.
+> 
+> Please note that I'm not asking any action from you, I'd simply
+> appreciated it, if someone could confirm or dispute my claims. Thanks.

Unfortunately, you're right. This is because how CBC chaining works.
When you specify to use larger sector size, geli(8) will generate one IV
for every 4kB of data and will encrypt the whole 4kB together.
If geli(8) will only have chance to encrypt first 512 bytes and those
512 have changed, the following 3584 bytes will not be readable.
I should mention it in the manual page for sure.

When geli(8) is used with authentication there is no such problem,
because every single 512-bytes sector has its own IV.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!