Add HW FDE changes to new tip along with soong rules for
conditional compilation.
Following changes for HW FDE as well ported:
- Restart Android framework after HW FDE key has been created
- Add support of Inline Cryto Engine
- Use new HW FDE apis to update password
- vold: Tie HW FDE keys with Root of Trust(ROT)
- vold: Fix HW FDE OTA support on SW FDE encrypted device
- vold: Fix return value from get_keymaster_hw_fde_passwd()
- vold: Remove creation of new keymaster key for password update
- vold: Fix password update issue with HW FDE
- vold: hw_fde: fix OTA issues from L to M
- vold: Branch out SW and HW FDE paths to improve boot up time
- cryptfs: Use lower case alphabets for hex key during OTA upgrades
- vold: Improve device boot up time (Tune sleep calls)
- Retry mount if mount fails after setting HW FDE key
- cryptfs: Fix compilation error
- cryptfs: Fix mount failure when encryption triggered from settings
- cryptfs: fix issue that caused problems with forced HW encryption
- cryptfs: fix wrong password set by user during bootup.
CRs-Fixed: 2210986
Change-Id: I77279fc7e309ac94535123a2b2dbcb228bb47251
This is needed so "adb remount" can avoid writing to /data during a
checkpoint.
Bug: 157540389
Test: manual test
Change-Id: I33a691da3b99343acfc1e8ddf68a14504c3bfbe1
Merged-In: I33a691da3b99343acfc1e8ddf68a14504c3bfbe1
This can be done through binder as well as vdc, using 'vdc volume
abort_fuse'.
Bug: 153411204
Test: adb shell vdc volume abort_fuse
Change-Id: I93e46dc1cd361729cc1162c63520cf73152ea409
Vold needs to pass / accept IncFs control via Binder, so it
neeeds to get and put its internal FDs in and out. Using the new
release() function it works without extra fd duping
Bug: 153704006
Test: builds & boots
Change-Id: I64bc5b1ca9f2c69e34c3a860ed3edbe58bd9ea29
Vold now does not check caller's permission, but only accepts
transactions from system_server. And it's up to system server to do the
right thing and check permissions/appops.
Bug: b/152633648
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest
Test: adb shell appops set 1000 GET_USAGE_STATS deny
Change-Id: Id56c1673b135b72b3ec86e572aa4bcca3afc19ab
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
Also, use the pids provided by system server to remount all existing
processes, so we don't need to do the heavy and unreliable scanning in
/proc anymore.
Bug: 149548518
Test: atest AdoptableHostTest
Change-Id: Ifb5b79a3bc5438f36e0d61ec8aec96bdbc60ca13
This can be used to fixup application directories in case they have been
created by some other entity besides vold; the main use case for this
API right now is OBB directories, which can be created by installers
outside of vold; on devices without sdcardfs, such directories and the
files contained therein are not setup correctly. This API will make sure
everything is setup the way it needs to be setup.
Bug: 146419093
Test: inspect OBB dir after install
Change-Id: I2e35b7ac2992dbb21cc950e53651ffc07cfca907
StubVolume is a volume type for ARC++ external storage. Named StubVolume
because it is managed from outside Android (not through Android kernel).
Previously, StubVolume is a diskless volume. However, as mentioned in
jsharkey@ email, a disk is needed for StubVolume to hold "kInternal"
(external storage type that is "external" from Android perspective,
but is "internal" to the device. For example shared directory from
ChromeOS to Android) and "kIndexable" (whether or not a disk should be
indexed by MediaStore).
The addition of disk means we could expose the createStubVolume API to
add a disk flags, which is also introduced in this CL.
Both kInternal and kIndexable will be introduced in separate CL.
Bug: 132796154
Test: Mount/unmount ARC++ removable device in ChromeOS.
Change-Id: I8b77fa1cf50ab38a2892272154dafdb78f079378
Move most of it into cryptfs.cpp, and include cryptfs.h in fewer files.
Bug: 147814592
Test: Treehugger
Change-Id: Ia3592d73e7abc1f07a60538e0978a3033bdea7de
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Merged-In: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
vold historically offerred functionality to create directories on behalf
of others. This functionality was purely used to create app-specific
data/obb/media dirs. Make this more explicit by renaming the method to
indicate this.
Additionally, in the past, we never needed to care about the UID set on
these directories, because sdcardfs would take care of that for us
automatically. But with sdcardfs going away, we need to make sure the
UID of the app-specific directories is set correctly. Allow the caller
to pass this in as an argument.
Bug: 146419093
Test: atest FuseDaemonHostTest
Change-Id: Ibeb5fdc91b40d53583bc0960ee11c4d640549c34
Mounting a FUSE path needs two steps:
1. Mounting the filesystem
2. Starting the FUSE session in the FUSE daemon
The second part requires retriving an fd from (1) and the mount paths
and passing it to the FUSE daemon.
Previously, we'd return from the Vold mount call and mark the volume
as mounted while we scramble to do (2). This means there's a time
period where the Volume is marked as MOUNTED but not actually ready
and any IO access on the paths will hang forever. This could also be
misleading when interpreting bug reports.
Now, we block the Vold mount call until the FUSE session is started
Test: atest AdoptableHostTest
Bug: 144275217
Change-Id: I45238a31df71286f67ef1c65c711d0085d72e97f
Up until now, the FUSE mount logic has made two assumptions:
1. The primary external volume is an emulated volume on /data/media
2. Only the primary user is running, as user zero
These assumptions are fixed by the following changes
creating an EmulatedVolume per Android user and changing the
VolumeBase id format to append the user to the id, so
s/emulated/emulated-0/. This allows us mount separate volumes per user
Some additional refactorings to re-use/clean up code.
Test: adb shell sm set-virtual-disk and partition disk operations work
even after setting up a work profile
Bug: 135341433
Change-Id: Ifabaa12368e5a591fbcdce4ee71c83ff35fdac6b
A little bit more self-explanatory name that explicitly says that root
is also allowed.
Test: builds
Change-Id: Ice20ffcba2a0994c599dbebace252138ffd827de
Merged-In: Ice20ffcba2a0994c599dbebace252138ffd827de
A little bit more self-explanatory name that explicitly says that root
is also allowed.
Test: builds
Change-Id: Ice20ffcba2a0994c599dbebace252138ffd827de
It will be used by userspace reboot to reset checkpoint state, to make
sure that when /data is remounted, it will be remounted in checkpointing
if a checkpoint was requested beforee userspace reboot.
Test: /system/bin/vdc startCheckpoint 1
/system/bin/vdc needsCheckpoint (returns 0)
/system/bin/vdc resetCheckpoint
/system/bin/vdc needsCheckpoint (returns 1)
Bug: 135984674
Change-Id: Ia29238686289b4eed93e2fb936a8b3d894b94dc9
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
Also allow the state just before doMount() as a valid state for setting
fuse fd.
Test: manual
BUG:140173712
Change-Id: I012f8a83fef00e68f33010954fbc2ebc53cf8f1d
Since system_server cannot mount devices by itself,
add a binder interface to vold that system_server
can call to initiate this mount when required.
BUG: 135341433
Test: manual
Test: atest --test-mapping packages/providers/MediaProvider
Test: ExternalStorageHostTest DownloadProviderTests
Change-Id: If4fd02a1f1a8d921a3f96783d8c73e085c5b7ca1
When both ext4 user data checkpoints and metadata encryption are
enabled, we are creating two stacked dm devices. This had not been
properly thought through or debugged.
Test: Enable metadata encryption on taimen (add
keydirectory=/metadata/vold/metadata_encryption to flags for userdata in
fstab.hardware)
Unfortunately metadata is not wiped by fastboot -w, so it is
necessary to rm metadata/vold -rf whenever you wipe data.
fastboot flashall -w works
fastboot reboot -w works
A normal boot works
Disable checkpoint commits with
setprop persist.vold.dont_commit_checkpoint 1
vdc checkpoint startCheckpoint 10
adb reboot
wait for device to fully boot then
adb reboot
Wait for device to fully boot then
adb logcat -d | grep Checkpoint shows the rollback in the logs
This tests encryption on top of checkpoints with commit, encryption
without checkpoints, and rollback, which seems to be the key cases.
Bug: 135905679
Change-Id: I8365a40298b752af4bb10d00d9ff58ce04beab1f
abortChanges will attempt to pass a reboot message, and will only reboot
if the device is currently checkpointing. Additionally, it can opt to
attempt to prevent future attempts. This only works for non-bootloader
controlled updates. Failures are ignored, as it will always reboot the
device. In the unlikely event of such a failure, the device will
continue to retry as though you did not ask to prevent future attempts.
Test: vdc checkpoint abortChanges abort_retry_test 1
vdc checkpoint abortChanges abort_noretry_test 0
Change-Id: I7b6214765a1faaf4fd193c73331696b53ae572d2
Also add vdc checkpoint supportsFileCheckpoint
This is to allow tests to be specific to supported checkpoint mode.
Test: Built on Taimen and Crosshatch, made sure both new functions work
as expected
Change-Id: I0eab7453b13c0a2e31840ef9ad24a692cec55b00
Restores the first n entries of a checkpoint. Allows automated testing
of interrupted restores.
Test: vdc checkpoint restoreCheckpoint [device] [n]
Change-Id: I47570e8eba0bc3c6549a04a33600df05d393990b
This returns true if any entries in the fstab have checkpoint=
set.
Test: Call vdc checkpoint supportsCheckpoint. Should return 1
iff an fstab entry has checkpoint=fs or checkpoint=block set
Bug: 111020314
Change-Id: Ic79bc96ded4da6605f73992dcff542e7cb50d705
When an app is started, it's mountmode is dependent on
OP_REQUEST_INSTALL_PACKAGES. If user changes the appop grant of an app,
we need to update the mounts of any processes running in that app.
Bug: 121099965
Test: atest android.appsecurity.cts.ExternalStorageHostTest#testExternalStorageObbGifts
Change-Id: I87fee492891d33ccc9fc9e2548114f67d90cc759
Previously, AppFuse is mounted in system_server's mount namespace. This
CL moves the mount location to vold namespace.
Relanding this since it fails to be merged on ag/5521004 (blocked by
Presubmit, seems to be caused by temporary state) - this one now
passes presubmit without any changes.
Bug: 110379912
Test: testOpenProxyFileDescriptor passes
Change-Id: Id93c26d5a98842c78f27850c83e15df619cec1ab
Previously, AppFuse is mounted in system_server's mount namespace. This
CL moves the mount location to vold namespace.
Bug: 110379912
Test: testOpenProxyFileDescriptor passes
Change-Id: Id93c26d5a98842c78f27850c83e15df619cec1ab
StubVolume is a Volume that is maintained by external party such as the
ChromeOS processes in ARC++.
Bug: 110380403
Test: Tested on ARC++
Change-Id: I3198bd7283d5f60a524da3707dea7385ffec599d
AnilKumar Chimata
David Anderson
Martijn Coenen
Yurii Zubrytskyi
Alex Buynytskyy
Songchun Fan
Ricky Wai
TreeHugger Robot
Risan
Automerger Merge Worker
Paul Crowley
Barani Muthukumaran
Zim
Nikita Ioffe
Nandana Dutt
Paul Lawrence
Sudheer Shanka
Daniel Rosenberg
Eric Biggers