Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

This obscures the length of the filenames, to decrease the amount of
information leakage.  By default, we pad the filenames to the next 4
byte boundaries.  This costs nothing, since the directory entries are
aligned to 4 byte boundaries anyway.  Filenames can also be padded to
8, 16, or 32 bytes, which will consume more directory space.

Change-Id: Ibb7a0fb76d2c48e2061240a709358ff40b14f322
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

Signed-off-by: NUday Savagaonkar <savagaon@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

Signed-off-by: NUday Savagaonkar <savagaon@google.com>
Signed-off-by: NIldar Muslukhov <ildarm@google.com>
Signed-off-by: NMichael Halcrow <mhalcrow@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

Signed-off-by: NMichael Halcrow <mhalcrow@google.com>
Signed-off-by: NIldar Muslukhov <muslukhovi@gmail.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

On encrypt, we will re-assign the buffer_heads to point to a bounce
page rather than the control_page (which is the original page to write
that contains the plaintext). The block I/O occurs against the bounce
page.  On write completion, we re-assign the buffer_heads to the
original plaintext page.

On decrypt, we will attach a read completion callback to the bio
struct. This read completion will decrypt the read contents in-place
prior to setting the page up-to-date.

The current encryption mode, AES-256-XTS, lacks cryptographic
integrity. AES-256-GCM is in-plan, but we will need to devise a
mechanism for handling the integrity data.
Signed-off-by: NMichael Halcrow <mhalcrow@google.com>
Signed-off-by: NIldar Muslukhov <ildarm@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

Signed-off-by: NMichael Halcrow <mhalcrow@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NIldar Muslukhov <muslukhovi@gmail.com>