am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I22c2be9483000fbf4b7c44190828b7ee96bc7ef4
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: Iebbbc82040a8b9f9126b17e5be21f669bd79e86d
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I02b02043d7fd112d860c3c39e92e78abbac136fd
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I7876d4bf00b328961ea1f40dfdc1d7d745599485
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I706e111de9d7ee32e3c26602e0c7f458d9156eeb
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I35727301158f7d64c0b39ad110add2f3e84ef86b
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: Icfebe368155bc2ccf36884a5df443e05b2b77880
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I6eff7575ea94ee938277937c0e71c444fe406fa1
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: Ic4c3d68fe49f3988565ff3795e9b1be9edca1d16
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: Iabeb25ab39981b7977fc71f487b7d33bc6d1a65a
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I3bae754efa80e9a9b8d8b91095c0576c0ff3f6a9
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
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.
Bug: 241601436
Test: check smart idle maint log of StorageManagerService
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I73f2bcf4bdb810164c174bd0d2518b15d577d5d5
Merged-In: I73f2bcf4bdb810164c174bd0d2518b15d577d5d5
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
Test: partner has tested that this works as expected, see bug
Fixes: 3dfb094cb2 ("vold: Support Storage keys for FBE")
Change-Id: I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6
(cherry picked from commit 2d30b890d2)
Merged-In: I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6
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
