The error messages that are printed when probing for rollback resistance
support on a device that doesn't support rollback-resistant keys can
make it sound like something is going wrong. Print a WARNING message
afterwards to try to make it clear what is going on. Also adjust or add
DEBUG messages when starting to generate each key so that it's easier to
distinguish the log messages for different key generation operations.
Bug: 182815123
Test: boot on device that doesn't support rollback-resistant keys and
check log.
Change-Id: I37a13eb5c1e839fb94581f3e7ec1cd8da0263d2b
Merged-In: I37a13eb5c1e839fb94581f3e7ec1cd8da0263d2b
The error messages that are printed when probing for rollback resistance
support on a device that doesn't support rollback-resistant keys can
make it sound like something is going wrong. Print a WARNING message
afterwards to try to make it clear what is going on. Also adjust or add
DEBUG messages when starting to generate each key so that it's easier to
distinguish the log messages for different key generation operations.
Bug: 182815123
Test: boot on device that doesn't support rollback-resistant keys and
check log.
Change-Id: I37a13eb5c1e839fb94581f3e7ec1cd8da0263d2b
The FUSE daemon is often holding fds on behalf of other apps and if a
volume is ejected the daemon would often get killed first while vold
is walking /proc/<pid>/fd to kill pids with open fds on the
volume. This is required for the volume unmount successfully.
To mitigate this, we avoid killing the FUSE daemon during the usual
/proc walk. This ensures that we first send SIGINT, SIGTERM and
SIGKILL to other apps first. There is an additional SIGKILL attempt
and on that last attempt, we kill the FUSE daemon as a last resort
Test: Manual
Bug: 171673908
Change-Id: I100d2ce4cb4c145cbb49e0696842e97dfba2c1c9
This allows libincremental_aidl-cpp to be built via cc_library instead
of aidl_interface.
BUG: 181266844
Test: builds
Change-Id: I4f0bc82629c0df758467aa074274b30f9dc6718d
This directory is used as a root for external storage on adopted storage
devices. It needs to be writable by processes holding the AID_MEDIA_RW
GID permission; in particular, it should be writable by the FUSE daemon.
On devices with sdcardfs, this was ensured automatically, because
sdcardfs presented a view of this directory that was writable, that we
could use for the FUSE daemon. But on devices without sdcardfs, the FUSE
daemon sees the raw filesystem and its permissions. This also means that
files created by the FUSE daemon will have their uid/gid set to the uid
of the FUSE daemon; to ensure these files stay writable to other system
applications that have AID_MEDIA_RW, use a default ACL to make sure the
gid stays AID_MEDIA_RW.
In particular, this fixes an issue with app cloning, where we want the
FUSE daemon of user 0 to be able to access the files of the app clone
user, and vice versa.
Bug: 154057120
Test: inspect uid/gid of /data/media/0 and contents
Change-Id: Ic5d63457ec917ea407b900dbb7773d89311780c6
Acquiring a wakelock can fail if the suspend service is unavailable.
Explicitly check that wakelock was acquired before performing
operations that require the device to stay on.
Bug: b/179229598
Test: Boot test on Pixel 4 device
Change-Id: If30087223e44098801a31d1bfd239ac22e891abe
am skip reason: Change-Id I7124285f41c6a854ad5c86677bc94d78ddca5a97 with SHA-1 60537dad69 is in history
Original change: undetermined
MUST ONLY BE SUBMITTED BY AUTOMERGER
Change-Id: I2d2f9234a82f959148a047d2e6e91fd90182b96c
am skip reason: Change-Id I7124285f41c6a854ad5c86677bc94d78ddca5a97 with SHA-1 60537dad69 is in history
Original change: undetermined
MUST ONLY BE SUBMITTED BY AUTOMERGER
Change-Id: I50546bc29bc2fcd0dee816ded8d45d9b355c4eb1
vold creates some directories for storing encryption keys if they don't
already exist, potentially including parent directories:
/metadata/vold/metadata_encryption
/data/misc/vold/volume_keys/$volume_uuid
/data/misc_de/$user/vold/volume_keys/$volume_uuid
/data/misc_ce/$user/vold/volume_keys/$volume_uuid
Currently fs_mkdirs() is used for this. However, fs_mkdirs() doesn't
include the fsync()s of the parent directories that are needed to ensure
that the new directories are persisted to disk right away -- which is
important for encryption keys.
Add a utility function MkdirsSync() which does what is needed, and make
the appropriate places call it.
Test: Booted and checked log for "Created directory" message.
Also ran 'atest vold_tests' to run the new unit test.
Change-Id: Ie9917b616433080139b8db3fd6877203ee6faf77
When an FBE or metadata encryption key is created, it's important that
it be persisted to disk right away; otherwise the device may fail to
boot after an unclean shutdown. storeKey() has the needed fsync()s.
However, storeKeyAtomically() doesn't, as it doesn't fsync() the parent
directory of key_path after it renames tmp_path to it.
Two callers do fsync() the parent directory themselves, but others
don't. E.g., the metadata encryption key doesn't get properly synced.
Therefore, add the needed fsync() to storeKeyAtomically() so that it
gets done for everyone.
Also remove the now-unneeded fsync()s from the two callers that did it
themselves.
Change-Id: I342ebd94f0a3d2bf3a7a443c35b6bda0f12e1ab2
Added SPDX-license-identifier-Apache-2.0 to:
Android.bp
bench/inodeop_bench/Android.bp
tests/Android.bp
Bug: 68860345
Bug: 151177513
Bug: 151953481
Test: m all
Exempt-From-Owner-Approval: janitorial work
Change-Id: I91823c7097d7bee39a363a0c0cc30de13e4d7539
