cryptfs.cpp and MetadataCrypt.cpp can use android::vold::sFsckContext directly.
hash.h is unuseful.
Test: make
Change-Id: I7acdac97d6ed1c9b2a5dc367fcea8aa2942192e8
Log the main configuration of the dm-crypt device -- the name, the
cipher, the keysize, the real device, and the length -- in addition to
the extra parameters which we were already logging.
(We can't simply log the actual string passed to the kernel, of course,
because that includes the key. So we choose the fields individually.)
Test: booted device configured to use FDE and checked the log message
Change-Id: Ia95de807c4fad68d93b7e7e73508a01e5139dc76
This is needed to make adoptable storage volumes work with a 4K crypto
sector size when the block device size is not a multiple of 4K.
It is fine to do this because the filesystem ends on a 4K boundary
anyway and doesn't use any partial block at the end.
Bug: 123375298
Test: booted device configured to use FDE with sector size 4k, ran
'sm set-virtual-disk true' and formatted the virtual SD card as
adoptable storage. Then did the same but with a temporary patch
that changed kSizeVirtualDisk to be misaligned
Change-Id: I95ee6d7dcaaa8989c674aea9988c09116e830b0c
When generating the key and salt we weren't checking for an error
opening or reading from /dev/urandom. Switch to the helper function
ReadRandomBytes() and start checking for errors.
Test: Booted device with FDE. As a extra sanity check I also
temporarily added log messages that dump the key and salt,
and I verified they still appear random.
Change-Id: I01ccee4f1f9910bf9508c8f02a918157393b0e68
We do not know what happened if remove dm-crypt device is failed, so
the error status added is useful to debug failed ioctl.
Change-Id: I49be91b9087ef2a213a706dd6b2a07eb6dafe6e6
Signed-off-by: Yue Hu <zbestahu@gmail.com>
We add the property ro.crypto.fde_sector_size to allow devices
to pass the "sector_size:<size>" argument to dm-crypt in the kernel.
We also pass "iv_large_sectors" when setting the sector size.
Using 4096-byte sectors rather than the default of 512 improves
dm-crypt performance, especially when the Adiantum encryption mode
is used.
Bug: 112010205
Test: Run on a device
Change-Id: I144ec7088a0aad3430369dc7158370d7ff3ef5d2
Adiantum is a crypto method Android is supporting for devices
which don't have AES CPU instructions. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details.
We add Adiantum to our list of supported crypto types.
Bug: 112010205
Test: Tested on a device
Change-Id: Ic190a9b90fc8bc077fdc7d60c9d5ae8d8f555025
persist_get_max_entries() is supposed to return an unsigned integer as the
maximum number of entries but it also wrongly returns "-1" as an error
condition. Also fix an issue where an unsigned subtraction in this routine
could lead to integer underflow.
Bug: 112731440
Test: manual
Change-Id: I9672e39bef2c12156dda7806a08c52044962c178
It can sometimes take a moment for the dm-device to appear after
creation, causing operations on it such as formatting to fail.
Ensure the device exists before create_crypto_blk_dev returns.
Test: adb sm set-virtual-disk true and format as adoptable.
Bug: 117586466
Change-Id: Id8f571b551f50fc759e78d917e4ac3080e926722
Merged-In: Id8f571b551f50fc759e78d917e4ac3080e926722
We support file-based encryption on both ext4 and f2fs now, and the
kernel API is the same. So rename things appropriately in vold:
e4crypt => fscrypt
ext4enc => fscrypt
Ext4Crypt => FsCrypt
EXT4_* => FS_*
ext4_encryption_key => fscrypt_key
Additionally, the common functions shared by 'vold' and 'init' are now
in libfscrypt rather than ext4_utils. So update vold to link to
libfscrypt and include the renamed headers.
Note: there's a chance of 'fscrypt' being confused with the dm-crypt
based encryption code in vold which is called 'cryptfs'. However,
fscrypt is the name used in the kernel for ext4/f2fs/ubifs encryption,
and it's preferable to use the same name in userspace.
Test: built, booted device with f2fs encryption
Change-Id: I2a46a49f30d9c0b73d6f6fe09e4a4904d4138ff6
Helpers to get a block device size in bytes or 512 byte sectors,
using BLKGETSIZE64 and returning value of uint64_t type.
This also removes get_blkdev_size().
Test: build, manual, mount exFAT volume
Bug: 80202067
Change-Id: Ib07e8ac6ef7ff49de0ed570d1fa202e8b558b80c
Checkpointing uses a combination of files on the meta partition
and the checkpoint= fs_mgr flag. Checkpointed partitions will
revert to their starting state on reboot unless checkpoint commit
is called.
Test: Run vdc commands, check file on metadata
Merged-In: Icba16578608a6cbf922472e9d4ae5b8cf5f016c6
Change-Id: Icba16578608a6cbf922472e9d4ae5b8cf5f016c6
Remove the Speck encryption support. It was eventually
decided not to allow Speck in Android P, so this code
is no longer needed and wasn't used outside of testing.
Note we don't just "git revert" the original commit
(38723f23ff) because we want
to retain the infrastructure for allowing new types of
crypto algorithms in the future.
Bug: 112009351
Test: Attempted to setup a device with ro.crypto.fde_algorithm set to Speck, and Speck was rejected and the system defaulted to AES.
Change-Id: I69a8b4e8632f8d30b5b54783cb986ab42d4397d9
This change adds null-checks for all the places where cryptfs tries to
access the /data entry in fstab, to avoid crashes.
Bug: 80493321
Test: No crashes in Android-in-Chrome OS (which lacks /data in fstab)
Change-Id: Id6cdfe01cdd336cebf8afb9bdd07135811115182
Merged-In: Id6cdfe01cdd336cebf8afb9bdd07135811115182
This commit replaces the double quotations for library headers with
angle quotations.
Test: cd system/vold && mma
Change-Id: I3c14cfcf80f29173669409df548af84c1b39b96d
Merged-In: I3c14cfcf80f29173669409df548af84c1b39b96d
This commit reorders the include directives in cryptfs.cpp so that
upcoming <cutils/log.h> change can be obvious.
Test: lunch aosp_walleye-userdebug && cd system/vold && mma
Change-Id: I9d2ea66c15b7b68014a67ba7c1420075953459ba
Merged-In: I9d2ea66c15b7b68014a67ba7c1420075953459ba
This commit replaces <cutils/log.h> and <utils/Log.h> with <log/log.h>.
Background:
<cutils/log.h> has been moved to <log/log.h> for a while. Both
<cutils/log.h> and <utils/Log.h> simply includes <log/log.h> for
backward compatibility. This commit is a part of the effort to remove
<cutils/log.h> and <utils/Log.h> from the source tree eventually.
Bug: 78370064
Test: lunch aosp_walleye-userdebug && cd system/vold && mma
Change-Id: I1f9b7b132f9c35469e97556a30b521cc47e829d7
This commit replaces the double quotations for library headers with
angle quotations.
Test: cd system/vold && mma
Change-Id: I3c14cfcf80f29173669409df548af84c1b39b96d
This commit reorders the include directives in cryptfs.cpp so that
upcoming <cutils/log.h> change can be obvious.
Test: lunch aosp_walleye-userdebug && cd system/vold && mma
Change-Id: I9d2ea66c15b7b68014a67ba7c1420075953459ba
Instead of hardcoding to "aes-cbc-essiv:sha256" with a 16 byte
key, we introduce a new property, "ro.crypto.fde_algorithm",
to allow the use of different crypto types. The only other
method we currently support is "speck128-xts-plain64" with
a 32 byte key, although new crypto types are easily added.
We intentionally derive things like the crypto name and the
keysize from the given property name. This means the code
must be changed for each new crypto type we want to support,
but that's worth it to remove the exploit vector of crypto
types with incorrect key sizes.
Due to previous refactoring CLs, this has minimal impact on
the current code other than changing what we return for
cryptfs_get_{keysize,crypto_name}.
Bug: 73079191
Test: Flashed onto a gobo device with the property set for SPECK, and confirmed via kernel debug output we were using SPECK on the device.
Change-Id: I9c9df61590344c5f62114dfbf679031b0c2ceb1f
Our external partitions have no crypto header/footer, so we
only get the keysize and key. Our code has been implicitly
assuming that this keysize off of disk matches the crypto
type we have in our code (and thus matches the keysize our
code is using as well). We now make this assumption
explicit, and check for this and no longer allow external
code to pass a keysize in to cryptfs.
Bug: 73079191
Test: Compiled and tested in combination with other CLs.
Change-Id: I1a1996187e1aaad6f103982652b1bcdfd5be33ce
Our code has places where we were reading in the crypt_mnt_ftr
struct from disk, but then proceeding to use a hardcoded constant
for the keysize. We plan to allow crypto with different sized
keys in the future, so we want to just trust the keysize we get
off of disk.
While doing this, we reject any crypt_mnt_ftr we read from disk
which has a keysize in excess of MAX_KEY_LEN. This defends us
against buffer overflows in the case of corrupt disk data.
Bug: 73079191
Test: Compiled and tested in combination with other CLs.
Change-Id: Id6f192b905960e5508833e9cd3b4668d4754dc7e
Rather than use an integer and have a comment, we use a named
constant for sizing these master key buffers. This will help
avoid confusion when we switch to allowing different sized
master keys.
Bug: 73079191
Test: Build
Change-Id: Ifaffdd94d337bb2d5a178f818dfe00f9386ae03b
Some parts of the code were intermingling constants for the master
key and the intermediate key. That works at the moment because
these are the same size. But we'll be introducing logic allowing
different sized master keys, while keeping the intermediate the
same. To aid that introduction, we use separate constants for
the intermediate key.
Bug: 73079191
Test: Build
Change-Id: I22b1dbf18aff2f76229df1c898fc606d6c1af3ca
Instead of hardcoding to "aes-cbc-essiv:sha256", we introduce a
new property, "ro.crypto.crypt_type_name", to allow the use of
different crypt methods. The only other method we currently
support is "speck128-xts-plain64", although new methods are
easily added.
We intentionally derive things like the keysize from the given
crypt name, to reduce exploit vectors. We also only accept
crypt names the code has whitelisted.
The biggest impact is replacing the hard-coded KEY_LEN_BYTES.
For compile-time buffers, we use the MAX_KEY_LEN to assure they
will be big enough for any crypt type. For run-time sizing,
we use the value derived from our property.
Bug: 73079191
Test: On an encrypted gobo, booted successfully with (1) no property set, (2) proproperty set to invalid value (and confirmed we defaulted to aes), and (3) after wiping userdata, with property set to "speck128-xts-plain64", confirmed we were using SPECK.
Change-Id: Ic4e10840d6ee2a4d4df58582448e0f768e6f403f
Looking at the EVP_DecryptUpdate() documentation, we need a
buffer which isn't just the keysize, but also provides the
cipher block length minus one byte extra. For EVP_aes_128_cbc(),
that block length is 16, but we use the maximum block length to
be safe for any future cipher change.
For two of our decrypted_master_key usages, the buffer was
already sufficiently sized. But for one of our instances,
in cryptfs_enable_internal(), the buffer was previously
smaller than this. So this CL represents a possible behavior
change if we were ever overrunning that buffer.
Bug: 73079191, 73176599
Test: Flashed an encrypted sailfish and it booted.
Change-Id: Ic5043340910dc7d625e6e5baedbca5bd4b2bfb03
We're removing hardcoded buffer sizes in anticipation of allowing
different keysizes. In this case, our buffer was sufficiently
large for all current cases. But if we ever changed the
crypt_mnt_ftr struct to allow larger keys, this code will adjust
with the change.
Bug: 73079191
Test: Flashed an encrypted sailfish and it booted.
Change-Id: I261e729a77b351e287fbb55327564fe512a23d47
We were hardcoding the size of the ikey buffer, but then had logic
which used KEY_LEN_BYTES and IV_LEN_BYTES to offset into the array
and describe the length of its contents.
In anticipation of allowing the keysize to be set via a property,
instead of at compile time, we change this code to make the relation
between the keysize and the buffer size explicit.
Bug: 73079191
Test: Flashed an encrypted sailfish and it booted.
Change-Id: I109a5dc812662220e53163bfb4b5e51bf5abf185
We'll be allowing modifyable key sizes in the near future,
and want to remove this variable to reduce confusion with this
change.
Bug: 73079191
Test: None
Change-Id: I7047bb375553d8c46ff0724add697a5105ebc68c
Don't use the FDE flow to support metadata encryption; just provide a
vold service which directly mounts the volume and use that.
Bug: 63927601
Test: Boot Taimen to SUW with and without metadata encryption.
Change-Id: Ifc6a012c02c0ea66893020ed1d0da4cba6914aed
Bug: 64766105
Test: FBE boots, forceencrypt boots, set pattern, reboots, encryptable
boots and can be encrypted
Change-Id: I8c6dc0acdc37c3a6f1bea28d5607ed8938a4eb0c
On FBE systems, adoptable storage uses both file-based encryption (for
per-user protection) and full disk encryption (for metadata
protection). For performance/battery reasons, we don't want to encrypt
the same data twice; to that end, ensure that the
allow_encrypt_override flag is sent to dm_crypt.
Bug: 25861755
Test: see ag/3247969
Change-Id: Ib0c5891ab2d2ee9007e27a50254d29fc867d7bc5
Correctly handle a key upgrade error from keymaster by upgrading the
FDE RSA key and writing the new key blob to disk.
Bug: 69792304
Test: Roll back PLATFORM_SECURITY_PATCH a month, wipe and reboot, roll
forwards again, check logs with and without this patch.
Change-Id: I220d2dd4e3d791f636e9bc5f063064cecbf1b88a
