retrieveKey can fail in load_all_de_keys if a user
is partially removed, i.e. cases where
fscrypt_destroy_user_key() got interrupted. So just
ignore the failure, else could reboot into recovery.
Test: pm create-user foo
pm remove-user 10
adb reboot && check device not enter recovery
Signed-off-by: liulvping <liulvping@xiaomi.com>
Change-Id: Iba9d53a0833524d00e65d0427ab03002c5d8d509
The legacy method for metadata encryption on adoptable storage failed
when the size of the block device isn't a multiple of the crypto sector size.
Update the size of dm-crypt device according to sector size
before construct dm_target.
Bug: 248582018
Change-Id: I5c78889bdfedca7f7b0704500fc313d7a48d5a3b
Signed-off-by: Hongyu Jin <hongyu.jin@unisoc.com>
Hardware-wrapped inline encryption keys (a.k.a. "wrapped storage keys"
or "TAG_STORAGE_KEY keys") are being generated with rollback resistance
enabled, but are never deleted. This leaks the space that KeyMint
implementations reserve for rollback-resistant keys, e.g. space in the
RPMB. This is a problem especially for the per-boot key, as that gets
regenerated every time the device is rebooted. After enough reboots,
KeyMint runs out of space for rollback-resistant keys. This stops any
new or upgraded keys from being rollback-resistant, reducing security.
This bug affects all devices that use HW-wrapped inline encryption keys
for FBE (have "wrappedkey_v0" in the options for fileencryption in their
fstab), and whose KeyMint implementations support TAG_STORAGE_KEY in
combination with TAG_ROLLBACK_RESISTANCE. But it's more of a problem on
devices that are rebooted frequently, as per the above.
Fix this bug by not requesting rollback resistance for HW-wrapped inline
encryption keys. It was a mistake for these keys to ever be rollback-
resistant, as they are simply a stand-in for raw keys. Secure deletion
instead has to happen higher up the stack, via the Keystore key that
encrypts these keys being deleted, or via the Keystore key and/or Weaver
slot needed to decrypt the user's synthetic password being deleted.
(It was also a mistake for HW-wrapped inline encryption keys to use
Keystore at all. The revised design for them that I'm working on for
upstream Linux doesn't use Keystore. But for now, Android uses Keystore
for them, and the fix is to not request rollback resistance.)
Bug: 240533602
Fixes: 3dfb094cb2 ("vold: Support Storage keys for FBE")
Change-Id: I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6
Underscore character may cause bpf prog/map naming collision. For
example, x.o with map y_z and x_y.o with map z both result in x_y_z
prog/map name, which should be prevented during compile-time.
aosp/2147825 will prohibit underscore character in bpf source name
(source name derives the obj name). Existing bpf modules with underscore
characters in source name need to be updated accordingly.
Bug: 236706995
Test: build
Change-Id: Ie6ea47560b1d44de0a0d9d124e17616fee6b0922
We introduce a new parameter of target dirty segment ratio,
which can be used to set a target dirty / (dirty + free) segments
ratio. For example, if we set this as 80%, GC sleep time will be
calculated to achieve this ratio in a GC period.
Test: check smart idle maint log of StorageManagerService
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I73f2bcf4bdb810164c174bd0d2518b15d577d5d5
Sometimes, waiting for the HAL makes infinite calls to HAL and ending
up with power consuming issues. While tracking the root cause, we will
temporally turn off HAL for storage device GC.
Bug: 235470321
Test: run "sm idle-maint run"
Ignore-AOSP-First: This is a temporal fix for Android TM devices.
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: Ieb371b7fdebfe938206a45547bb24dfbf2c2e7be
Now that emulated FBE is no longer supported, there is no longer any
distinction between native FBE and emulated FBE. There is just FBE.
Referring to FBE as "fscrypt" is also poor practice, as fscrypt (the
Linux kernel support for filesystem-level encryption) is just one part
of FBE, the Android feature.
Therefore, rename fscrypt_is_native() to IsFbeEnabled().
Bug: 232458753
Change-Id: Idf4cb25d37bc3e81836fcc5a1d96f79ccfa443b7
Note that, encrypt_inplace cannot support zoned device, since it
doesn't support in-place updates. And, dm-default-key will have
a different key.
Bug: 172378121
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I34cb1e747e0f3faa07c5a4bfeded11fb789a033c
This fixes a bug in Android T where MediaProvider leaked FUSE fds in
it's process preveventing it from dying after being killed. This
resulted in the MP in a zombie state.
Even though, this bug was more prevalent in Android T due to a change
in the Parcel lifecycle (see b/233216232), this bug could have always
occurred in theory.
This fix should be harmless since after volume reset, all FUSE volumes
should be unmounted and aborting the FUSE connections will either
no-op or actually prevent the FUSE daemon from getting wedged in a
zombie state.
Test: Manually trigger a FUSE fd leak in the MediaProvider, kill it
and verify that it is restarted without zombie.
Bug: 233216232
Bug: 231792374
Bug: 230445008
Change-Id: I9e559a48b9a72e6ecbc3a277a09ea5d34c9ec499
Emulated FBE was a developer-mode feature intended to allow developers
to add Direct Boot support to apps before native FBE devices became
widely available. Since all devices running the latest version of
Android now use native FBE (except for a couple edge cases not relevant
here, like in-development devices on which encryption hasn't been
enabled yet), and emulated FBE doesn't work on native FBE devices
anyway, there's no longer any need to carry the code for emulated FBE.
Bug: 232458753
Change-Id: Ia6824699b578aca3af340fe578e26d5a5dc82b16
This fixes a bug in Android T where MediaProvider leaked FUSE fds in
it's process preveventing it from dying after being killed. This
resulted in the MP in a zombie state.
Even though, this bug was more prevalent in Android T due to a change
in the Parcel lifecycle (see b/233216232), this bug could have always
occurred in theory.
This fix should be harmless since after volume reset, all FUSE volumes
should be unmounted and aborting the FUSE connections will either
no-op or actually prevent the FUSE daemon from getting wedged in a
zombie state.
Test: Manually trigger a FUSE fd leak in the MediaProvider, kill it
and verify that it is restarted without zombie.
Bug: 233216232
Bug: 231792374
Change-Id: I9e559a48b9a72e6ecbc3a277a09ea5d34c9ec499
Merged-In: I9e559a48b9a72e6ecbc3a277a09ea5d34c9ec499
