bcache: Set ra_pages based on backing device's ra_pages
TRESOR 0.3 from www1.informatik.uni-erlangen.de/tresor
TRESOR: Put name_to_dev_t in do_mounts.h for keydevice parameter.
TRESOR: s/custom thaw_kernel_processes/thaw_kernel_threads/

This switches from the custom thaw_kernel_processes which didn't
thaw workers (so that encryption requests weren't processed) to the
thaw_kernel_threads already in the kernel.  This allows keydevices
to be read when resuming from sleep.

In order to prevent any data corruption due to encrypting data when
the keys aren't present, we restructure TRESOR's use of the kernel
crypto APIs.  Instead of implementing a simple cipher, we implement
TRESOR as a asynchronous block cipher (CBC-only for now, though
others would be very trivial to add with a few minutes of
copy-paste).  This returns immediatey when keys are present (ie
essentially always) and only acts asynchronously when keys are
missing (ie when resuming from sleep, before userspace has been
restarted).
Zeroize some semi-sensitive info in sha256.

This tries to get the built-in sha256 slightly closer to TRESOR's
sha256 (which is dropped in favor of the built-in one in the next
commit).
TRESOR: Use built-in sha256 instead of a custom function.

It no longer limits password length (very important as keydevices
always make the length of the hashed data longer than that limit)
and it is a bit more proper in terms of coding standards.  Note
that while this means things like the length of your hashed data
is more likely to end up in memory, a. it already likely was on
the TRESOR stack, as assigning a variable at the end of a function
will likely just be optimized away and b. the length of the
passphrase is already displayed on the screen, which is
significantly more "leaky" than it ending up in memory.
TRESOR: Add support for "keydevices".

This allows you to use an arbitrary block of a block device as an
additional salt to TRESOR.

It uses the tresorkeydevice= parameter and name_to_dev_t (ie the
same semantics as root=) to select the block device.

Though the block number should be considered private data, no
effort is made to keep it out of memory.  This should be fixed.

The read uses a simple bio, so many block devices are likely to
cache the request, resulting in parts of your key ending up in
memory.  This might also be fixed, though it would likely require
significant effort.  If you use a regular block device as your key
device, you are likely safe.  (TODO: check that that is actually
true)

Note that you absolutely need to include all modules in your kernel
which are required to connect the keydevice.  If you fail to do so,
your boot will hang.

It is recommended that you not have a filesystem on the key block,
as it may end up overwriting your partiular block for little or no
reason (or atleast do lots of digging to make sure it won't).
TRESOR: When reading from terminal, try more than just one term.

Instead of just opening /dev/tty0 or /dev/console depending on the
circumstances, try opening more than one tty/console and see which
one the user responds on.

This fixes restore-from-sleep input in some cases.
TRESOR: Don't echo private information to screen.