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.
Also ran same tests on unmodified Taimen and Blueline
Bug: 135905679
Merged-In: I8365a40298b752af4bb10d00d9ff58ce04beab1f
Change-Id: I8365a40298b752af4bb10d00d9ff58ce04beab1f
Old approach (do not start class main) does not work because when
testings userdebug GSI on user system, adb does not start until the
framework starts.
Bug: 134126407
Test: Test passes with userdebug GSI on user Taimen
Change-Id: I20441964dbc7b6ad5b445fa17a1374c1282bbbd8
Don't delete keys in checkpointing mode. Instead wait until the
checkpoint has been committed.
Bug: 134631661
Test: Flash A with a working build. Flash B with a broken build. Test
that the device rolls back to A without getting sent to recovery.
Change-Id: Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051
When Android boots after file_contexts has changed, the boot process
walks the entire /data partition, updating any changed SELinux labels as
appropriate. However, credential encrypted ("ce") directories are
deliberately excluded from this early boot directory walk. Files within
ce directories have their filenames encrypted, and as a result, cannot
match the file_contexts entries. Only after the user has unlocked their
device are the unencrypted filenames available and a restorecon
appropriate.
Ensure that we do a post-unlock restorecon on /data/vendor_ce, like we
do for /data/system_ce and /data/misc_ce. This ensures the labels on
files within these directories are correct after the device has been
unlocked.
Bug: 132349934
Test: See bug 132349934 comment #12 for test procedure
Change-Id: Ifcbef5fdfb236ec6dea418efa9d965db3a3b782f
This trigger was used on FDE devices to bring down the minimal
framework, and worked by shutting down the 'main' service class.
With APEX being introduced, we want to restart all services that were
started after the tmpfs /data was mounted, as those are the services
that haven't been able to use updated APEXes in the (real) /data.
In order to do this, we need to reset more classes; that in turn
made the 'shutdown_main' trigger pretty much similar to the
previously existing 'trigger_shutdown_framework' trigger; so instead
of keeping two duplicate triggers, use only the
'trigger_shutdown_framework' one.
Bug: 118485723
Test: Taimen configured as FDE boots, Taimen configured as FBE boots
Change-Id: I0d80ef2528bd70870b063a2c580cd00a03de9961
Bug: 120095226
Test: Tested by forcing /data/system/last-fstrim last modified time back
2 years & manually trigger checkpoint using 'vdc checkpoint startCheckpoint 1'
Change-Id: I0cb8b6a85ae787e1ba2cdd7998a46942ca69760f
Signed-off-by: Sandeep Patil <sspatil@google.com>
am: a598e04a91 -s ours
am skip reason: change_id Ib8c349d6d033f86b247f4b35b8354d97cf249d26 with SHA1 37c82f5c0f is in history
Change-Id: Ifec2d700dbe6bbe55e65e6e07003d1e77fb3dbc2
am: 2e58acb412 -s ours
am skip reason: change_id I53d252942c21365983b4f8b6e0948b1864f195c1 with SHA1 621d9b9732 is in history
Change-Id: Icdb62b1d4e6e7ca7d18df1083020d61d9b215165
We'd previously call ForceUnmount after the call to PrepareDir,
which would sometimes fail because the userspace counterpart of a
FUSE FS that was previously mounted at that mountpoint has gone
away. This is usually reproducible after a runtime restart.
Bug: 128459728
Test: Loop (adb shell start; atest MediaStore_Images_MediaTest; adb shell stop;)
Change-Id: I38d3908487123614c338266f983afb04e3ed78d4
Now that lockUserKey() will be called for every user each time the
framework is started, it's a normal case that the key being removed
doesn't exist. So downgrade the log message about being unable to find
a key from ERROR to DEBUG.
Test: build and boot, message is now debug level.
Change-Id: I2d1dce8dd8825b02982eab1c902aa10fe5b54b84
If more than the default number of loop devices is in use, we may need
to wait for the device path to be available.
Bug: 128873591
Bug: 122059364
Test: Set up adopted virtual disk and check that it loads on boot
Change-Id: I201dcc32043664076f50b0d6f40de6e5e1a65342
Paul Lawrence
TreeHugger Robot
Xin Li
Daniel Rosenberg
Sudheer Shanka
Nick Kralevich
Martijn Coenen
Paul Crowley
Sandeep Patil
Woody Lin
Narayan Kamath
Eric Biggers
Jaegeuk Kim