Now that we include libfscrypt in libfs_mgr via whole_static_libs we
should not reference it directly.
Bug: 143307095
Test: treehugger
Change-Id: I4cd138b50131ec8ce7835d9604c89c99cae53212
A little bit more self-explanatory name that explicitly says that root
is also allowed.
Test: builds
Change-Id: Ice20ffcba2a0994c599dbebace252138ffd827de
Merged-In: Ice20ffcba2a0994c599dbebace252138ffd827de
It will be used by userspace reboot to reset checkpoint state, to make
sure that when /data is remounted, it will be remounted in checkpointing
if a checkpoint was requested beforee userspace reboot.
Test: /system/bin/vdc startCheckpoint 1
/system/bin/vdc needsCheckpoint (returns 0)
/system/bin/vdc resetCheckpoint
/system/bin/vdc needsCheckpoint (returns 1)
Bug: 135984674
Change-Id: Ia29238686289b4eed93e2fb936a8b3d894b94dc9
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
Link .clang-format to the standard .clang-format file (4-space-indent
version) from build/soong, rather than use a custom file.
Among other changes, the standard file has the "IncludeBlocks: Preserve"
setting, so include blocks stay in order.
Don't actually reformat all the code yet.
Test: Tried 'clang-format -i $(find . -name \*.cpp -o -name \*.h)'
and checked that the changes look sane.
Change-Id: I11ecbd03b31e44ba7b3e01175a6fc317f8173ab0
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I890b572d537d66ecb49effd8efc782279c52956e
