Commit graph

2 commits

Author SHA1 Message Date
Jeff Sharkey
d0640f6358 Add f2fs support for private volumes.
When formatting volumes, pass along fsType string which can be "auto"
to let the volume select the best choice.  For now, private volumes
assume that MMC devices (like SD cards) are best off using f2fs when
both kernel support and tools are present, otherwise fall back to
ext4.  Use blkid when mounting to pick the right set of tools.

Move filesystem utility methods into namespaces and place in separate
directory to be more organized.

Bug: 20275581
Change-Id: Id5f82d8672dda2e9f68c35b075f28232b0b55ed4
2015-06-08 20:21:25 -07:00
Jeff Sharkey
9c48498f45 Support for private (adopted) volumes.
This adds support for private volumes which is just a filesystem
wrapped in a dm-crypt layer.  For now we're using the exact same
configuration as internal encryption (aes-cbc-essiv:sha256), but we
don't store any key material on the removable media.  Instead, we
store the key on internal storage, and use the GPT partition GUID
to identify which key should be used.

This means that private external storage is effectively as secure as
the internal storage of the device.  That is, if the internal storage
is encrypted, then our external storage key is also encrypted.

When partitioning disks, we now support a "private" mode which has
a PrivateVolume partition, and a currently unused 16MB metadata
partition reserved for future use.  It also supports a "mixed" mode
which creates both a PublicVolume and PrivateVolume on the same
disk.  Mixed mode is currently experimental.

For now, just add ext4 support to PrivateVolume; we'll look at f2fs
in a future change.  Add VolumeBase lifecycle for setting up crypto
mappings, and extract blkid logic into shared method.  Sprinkle some
more "static" around the cryptfs code to improve invariants.

Bug: 19993667
Change-Id: Ibd1df6250735b706959a1eb9d9f7219ea85912a0
2015-04-01 10:45:05 -07:00