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.
Merged-In: Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051
Change-Id: Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051
In order for the build system to track updates to the header files
during incremental builds, always specify the src files using the same
path as the package for C++ compilations.
Bug: 112114177
Test: treehugger
Change-Id: I9a2d638cbde46f67e2d5761f5b5113cc7e068ec5
Bug: 131815738
Test: vdc checkpoint startCheckpoint 2 succeeds on blueline
It fails with a modified fstab with no checkpoint=fs flag
Change-Id: I6d55810a1f711a670f18fbd10d8779c15f4e3cba
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.
(cherrypicked from commit 6a3ef488e5)
Bug: 132349934
Test: See bug 132349934 comment #12 for test procedure
Change-Id: Ifcbef5fdfb236ec6dea418efa9d965db3a3b782f
This mostly 1:1 replaces manual ioctls to device-mapper with calls to
libdm. There were two exceptions:
(1) There is a very old table-load-retry loop to workaround issues with
umount (b/7220345). This loop has been preserved, however, it now
includes DM_DEV_CREATE as well as DM_TABLE_LOAD.
(2) There was some ancient code to set DM_DEV_GEOMETRY for obb
dm-devices. This never did anything since geometry must be set after
loading a table. When setting it before (as vold was doing), the
subsequent DM_TABLE_LOAD will clear it.
Bug: 132206403
Test: FBE device boots
FBE device w/ metadata encryption boots
FDE device boots
atest StorageManagerIntegrationTest
Change-Id: Ib6db6b47329f093ac7084edaf604eddace8b9ac6
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
Merged-In: I0cb8b6a85ae787e1ba2cdd7998a46942ca69760f
Signed-off-by: Sandeep Patil <sspatil@google.com>
The boot failure symptom is reproduced on Walleye devices. System boots
up after taking OTA and try to upgrade key, but keymaster returns "failed
to ugprade key". Device reboots to recovery mode because of the failure,
and finally trapped in bootloader screen. Possible scenario is:
(After taking OTA)
vold sends old key and op=UPGRADE to keymaster
keymaster creates and saves new key to RPMB, responses new key to vold
vold saves new key as temp key
vold renames temp key to main key -------------- (1) -- still in cache
vold sends old key and op=DELETE_KEY to keymaster
keymaster removes old key from RPMB ------------ (2) -- write directly to RPMB
==> SYSTEM INTERRUPTED BY CRASH OR SOMETHING; ALL CACHE LOST.
==> System boots up, key in RPMB is deleted but key in storage is old key.
Solution: A Fsync is required between (1) and (2) to cover this case.
Detail analysis: b/124279741#comment21
Bug: 112145641
Bug: 124279741
Test: Insert fault right after deleteKey in vold::begin (KeyStorage.cpp),
original boot failure symptom is NOT reproducible.
Change-Id: Ia042b23699c37c94758fb660aecec64d39f39738
Merged-In: Ib8c349d6d033f86b247f4b35b8354d97cf249d26
(cherry picked from commit a598e04a91)
When a user's CE key is removed, write "2" to /proc/sys/vm/drop_caches
rather than "3". This avoids unnecessarily evicting the pagecache of
in-use inodes. It's only necessary to evict the inodes of the relevant
encrypted files, and these are already sync'ed and no longer in-use.
For this mode "2" suffices, as this evicts "reclaimable slab objects",
including inodes; and evicting an inode implies evicting its pagecache.
This matches the recommendation I've made in the documentation for the
fscrypt kernel feature at
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#online-attacks
Test: Sanity check that directories are still "locked" properly:
Unlock device with PIN. Then in adb shell: 'stop; start;
sleep 10; ls /data/data/' still shows filenames in ciphertext form.
Change-Id: I1bdf3c420ebf63e98cc314498211061ea36f2942
Tri Vo
Paul Lawrence
Treehugger Robot
Xin Li
The Android Open Source Project
Daniel Rosenberg
Dan Willemsen
android-build-team Robot
David Anderson
Nick Kralevich
Martijn Coenen
xzj
Sandeep Patil
Woody Lin
Paul Crowley
Eric Biggers