When running on kernel without FUSE, fs::directory_iterator
throws exception since /sys/fs/fuse/connections is missing.
This patch uses non-throwing fs::directory_iterator
and adds explicit error check.
Test: vold doesn't fail with FUSE disabled
Signed-off-by: Oleg Lyovin <ovlevin@sberdevices.ru>
Change-Id: I51b68363edf75033fcec3ce5623f419d5a68c991
As a small optimization and code simplification, stop reading and
writing the "stretching" file alongside each stored key. vold never
does key stretching anymore.
There was one special case in the code where if the stretching file
existed and contained "nopassword", then the secret was ignored.
However, this didn't seem to be of any use, especially since it didn't
cause Keystore to be used, so it did *not* allow a key stored with no
secret to be read if a secret was unexpectedly provided.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Change-Id: I5a7cbba7492526e51c451f222b9413d9fae6bce5
Storage keys that are encrypted by the user's synthetic password don't
need to be securely deletable by vold, since secure deletion is already
implemented at a higher level: the synthetic password protectors managed
by LockSettingsService. Therefore, remove the use of the secdiscardable
file by vold in this case to improve performance.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Change-Id: I847d6cd3b289dbeb1ca2760d6e261a78c179cad0
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
