Add support for setting v2 encryption policies when configured in the
fstab (for internal storage) or in system properties (for adoptable
storage), and for installing and evicting the keys for such policies.
v2 policies support the same encryption modes and flags as v1 policies,
but internally they use a more standard, secure, and flexible KDF. Due
to this, some future features will be supported by v2 policies only.
Bug: 140500999
Test: Configured a device to use v2 encryption policies (applied the
needed kernel patches and added
"fileencryption=aes-256-xts:aes-256-cts:v2" to fstab, and set the
corresponding system properties for adoptable storage). Wiped
userdata, booted device and checked logs to verify that v2
policies were being used.
Also enabled virtual SD card and formatted as adoptable storage;
verified it works and that v2 policies were being used on it.
Also created, started, and stopped a 2nd user and verified their
keys were evicted.
Also verified that the device comes up again after rebooting.
Also verified that a device using v1 encryption policies continues
to work, both with and without an updated kernel -- including
stopping a user so that their keys get evicted.
Change-Id: If64028d8580584b2c33c614cabd5d6b93657f608
When the kernel supports the new fscrypt key management ioctls, use them
instead of add_key() and keyctl_unlink().
This will be needed in order to support v2 encryption policies, since v2
encryption policies only support the new ioctls.
The new ioctls have other advantages too. For example,
FS_IOC_REMOVE_ENCRYPTION_KEY automatically evicts exactly the necessary
kernel objects, so the drop_caches sysctl is no longer needed. This
makes evicting keys faster and more reliable.
FS_IOC_REMOVE_ENCRYPTION_KEY also detects if any files are still open
and therefore couldn't be "locked", whereas this went undetected before.
Therefore, to start out this patch adds support for using the new ioctls
for v1 encryption policies, i.e. on existing devices.
(Originally based on a patch by Satya Tangirala <satyat@google.com>)
Bug: 140500828
Test: tested that a device using v1 policies continues to work, both
with and without an updated kernel. See
If64028d8580584b2c33c614cabd5d6b93657f608 for more details.
Also checked via the log that the filesystem-level keyring is in
fact used when supported.
Change-Id: I296ef78138578a3fd773797ac0cd46af1296b959
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
When Android boots after file_contexts has changed, the boot process
walks the entire /data partition, updating any changed SELinux labels as
appropriate. However, credential encrypted ("ce") directories are
deliberately excluded from this early boot directory walk. Files within
ce directories have their filenames encrypted, and as a result, cannot
match the file_contexts entries. Only after the user has unlocked their
device are the unencrypted filenames available and a restorecon
appropriate.
Ensure that we do a post-unlock restorecon on /data/vendor_ce, like we
do for /data/system_ce and /data/misc_ce. This ensures the labels on
files within these directories are correct after the device has been
unlocked.
Bug: 132349934
Test: See bug 132349934 comment #12 for test procedure
Change-Id: Ifcbef5fdfb236ec6dea418efa9d965db3a3b782f
When a user's CE key is removed, write "2" to /proc/sys/vm/drop_caches
rather than "3". This avoids unnecessarily evicting the pagecache of
in-use inodes. It's only necessary to evict the inodes of the relevant
encrypted files, and these are already sync'ed and no longer in-use.
For this mode "2" suffices, as this evicts "reclaimable slab objects",
including inodes; and evicting an inode implies evicting its pagecache.
This matches the recommendation I've made in the documentation for the
fscrypt kernel feature at
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#online-attacks
Test: Sanity check that directories are still "locked" properly:
Unlock device with PIN. Then in adb shell: 'stop; start;
sleep 10; ls /data/data/' still shows filenames in ciphertext form.
Change-Id: I1bdf3c420ebf63e98cc314498211061ea36f2942
Use vold version of writeStringToFile which fsync files, and
manually fsync directories after initialize global DE
(cherry picked from commit a98464f688)
Bug: 71810347
Test: Build pass and reboot stress test.
Original boot failure symptom is NOT reproducible.
Change-Id: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Merged-In: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Now that lockUserKey() will be called for every user each time the
framework is started, it's a normal case that the key being removed
doesn't exist. So downgrade the log message about being unable to find
a key from ERROR to DEBUG.
Test: build and boot, message is now debug level.
Change-Id: I2d1dce8dd8825b02982eab1c902aa10fe5b54b84
Use vold version of writeStringToFile which fsync files, and
manually fsync directories after initialize global DE
Bug: 71810347
Test: Build pass and reboot stress test.
Original boot failure symptom is NOT reproducible.
Change-Id: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Device can't start up after the following steps:
1. set screen lock to PIN/Pattern/Password
2. set screen lock to Swipe/None
3. power down immediately after pressing "YES, REMOVE"
4. reboot
failed log:
Failed to read from /data/misc/vold/user_keys/ce/0/current/keymaster_key_blob
root cause:
flushing data failed because of power down
issue:
https://partnerissuetracker.corp.google.com/u/1/issues/119382750
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
Paul Crowley
Eric Biggers
Nick Kralevich
Tommy Chiu
Tom Cherry
Jie