Replace the current `string secret` argument to the lock/unlock of
CE storage with a `byte[]`. This is part of an effort to remove
instances of the LSKF and LSKF-derived secrets that are available
in a RAMdump -- since the strings are passed from Java, they cannot
be cleared, but `byte[]` can be.
This CL is the described argument change, and the propagation of this
change to the various functions that are called by the vold binder
functions.
Bug: 320392352
Test: Manual upgrade test:
1. Flash the device with a build not including these changes
2. Rebuild with these changes
3. Flash the device (but do not wipe) with the build including
these changes
4. See if the device boots and works normally -- if the CE
storage cannot be unlocked it will not start up and be usable
when the user logs in.
Change-Id: Icd4c925f2fd79e7533fdf9027e16f6736dbe1ab3
[Description]
The usb has invalid partition table, but vold thinks it has partition.
So vold not to treat entire disk as partition.
Bug: 160433451
[Test Report]
Build pass.
The special usb can mount ok.
Change-Id: I0b0e761641f6961e69d7d7f7fbc58d33eeab3a08
This reverts commit 697c6a5217.
It is reapplying the change in I0439f63fd4739bf5a6c957695cc9c3003ec89eb0.
Reason for revert: Undoing the revert (putting the change back in); after looking at the
performance bug, it seems impossible it was caused by the addition of the `@SensitiveData`
tag on IVold.
Performance bug: 331045735
Bug: 320392352
Test: launch_cvd -daemon
Change-Id: I522f63836155ea404260e89fd2f209738f37d5b3
This reverts commit da1d160074.
Reason for revert: reverting while figuring out what is causing performance bug 331045735
Change-Id: Ib306e679e65c3a585304ad4c33304c549cbb240e
Mitigate data leak across the Binder boundary to Vold, of secrets derived from the LSKF.
Specifically: the `String secret` argument to both `setCeStorageProtection` and `unlockCeStorage` is
a secret derived from the user's synthetic password.
This CL is part of an effort to wipe instances of the LSKF and
secrets derived from it, so they are not available in a RAMdump.
Bug: 320392352
Test: launch_cvd -daemon
Change-Id: I0439f63fd4739bf5a6c957695cc9c3003ec89eb0
am skip reason: Merged-In Ib360884801c37c093d9836109f0b817987abd850 with SHA-1 481c20da07 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2992701
Change-Id: I0b9da01887d5a64fbf8ad53a662b255b5343de8a
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In Ib360884801c37c093d9836109f0b817987abd850 with SHA-1 481c20da07 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2992701
Change-Id: Iff6aee9855e4c4ab12bdcc14e7f39145957cbaa9
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In Ib360884801c37c093d9836109f0b817987abd850 with SHA-1 481c20da07 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2992701
Change-Id: Id08e446287564a857c4415403825232eed2eb474
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In Ib360884801c37c093d9836109f0b817987abd850 with SHA-1 481c20da07 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2992701
Change-Id: I57c50d786c7c58331be3a0e2b716067af1383b99
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
Since MANAGE_MISC_DIRS is hardcoded to 0, and it always has been, there
is no need to have it in the code.
Test: build
Change-Id: I30a73e67999841271e07dbc3eeb1b8568529a7c3
The current shutdown / reset logic in VolumeManager unmounts
EmulatedVolume first, and unmounts the other disks.
In ARC (Android on ChromeOS), ChromeOS Downloads directory (exposed from
ChromeOS to Android as a disk having StubVolume) is bind-mounted to
/data/media/0/Download in the ARC-customized version of
StubVolume::doMount() (http://shortn/_lKaAhTLhY3), and the current
unmount order causes EmulatedVolume not to be cleanly unmounted. This
patch hence changes the order of the unmount of volumes to first unmount
StubVolume disks, then unmount the EmulatedVolumes, then unmount the
non-StubVolume disks.
Bug: 304369444
Test: On an Android phone, create a virtual public volume with the
following commands on adb shell (taken from
android.scopedstorage.cts.lib.TestUtils.createNewPublicVolume()):
$ sm set-force-adoptable on
$ sm set-virtual-disk true
$ sm list-disks # <- This returns the virtual disk name
$ sm partition <virtual disk name> public
Then, run `vdc volume reset` on lynx adb shell, observe logcat from
vold and check that no error is observed.
Test: Run `vdc volume reset` on ARC adb shell, and confirm that:
* Without this patch, the primary emulated volume fails to unmount
with "Device or resource busy", followed by MyFiles volume unmount.
* With this patch, MyFiles volume is unmounted before the primary
emulated volume, and no error is observed.
Change-Id: I54f60e3320574ccf8d3589545ff77967fff14fc7
This differs slightly from the previous API, which exists for idle
maintenance, whereas this value is intended to be displayed to users.
First, it returns remaining lifetime, rather than used lifetime. Second,
it rounds up the returned value for usabilty purposes. This isn't an
issue on Pixel (which reports at 1% granularity), but devices which
report at 10% granularity should show 100% out-of-box, which is not
possible to distinguish in the old API.
Bug: 309886423
Test: StorageManager.getRemainingStorageLifetime
Change-Id: Ic5f6ec9969667302ba8bad95b2765e2cc740bed4
