RFC: backporting GEOM to the 4.x branch

[Roland Dowdeswell]

On 1109549715 seconds since the Beginning of the UNIX epoch
Maxim Sobolev wrote:
>

>Well, I think that this is quite minor item, since GBDE doesn't govern 
>transformation of the passphrase into the actual key, so that another 
>scheme more bullet-prof against dictionary attacks (PKCS#5 or any other) 
>can be developed in virtually no time at all and will require making 
>only minor changes to the userland utility which gets password from the 
>keyboard or command line, hashes it and feeds to the kernel.

These changes have not been made.  Until they are, the security of
the entire system depends on choosing very strong passphrases which
most users do not do.  So, one should not inform users either
explicitly or implicitly that their data is safe [at least not
without the proviso that the passphrase is actually easier to attack
in practise than an entry in /etc/master.passwd and hence much more
care should be taken in choosing them.]

>Well, it's hard to comment on this, since the only paper that I have 
>found on CGD is http://www.imrryr.org/~elric/cgd/cgd.pdf, which 
>unfortunately doesn't provide any details on how CGD encrypts data and 
>lays it out on disk.

Actually, it does.  But, I can reiterate here.  CGD does not move
the blocks on the disk around at all.  It doesn't make much sense
to do that.  Each block is encrypted separately using the chosen
algorithm with your key.  An IV is chosen using a configurable
mechanism, although I have yet only implemented one which is the
encrypted block number.

>So what? If the write fails in the middle, reading sector will just 
>produce garbage. I don't think that it's different from plain old HDD 
>which has been powered down in the middle of doing disk write. Disk 
>encryption layer is definitely not the level at which journaling should 
>be implemented. It's task of file system to do this. The task of 
>encryption layer is merely to inform the file system when transaction 
>(i.e. both of those two writes in this case) have been completed 
>successfully, so that FS can adjust its journal accordingly.

That is actually quite different that what normally happens.
Basically what this means is that if your OS crashes or you suffer
a power out then you have a reasonable chance that you've lost
blocks on the disk.  This will lead to a situation where fsck may
not be able to recover your file system.

A file system depends on certain assumptions about the underlying
disk device, namely that a single sector write is an atomic operation
in order to accomplish its task.  It looks to me from the paper
and the code that GBDE breaks this fundamental assumption.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/