Apps are able to prevent their death by forking multiple processes
under different services and monitoring for the death of any of these.
When a child death is detected, the remaining process restarts the
terminating/terminated service before it's able to be killed itself.
This is now prevented by freezing the entire cgroup of the package to be
killed before killing the individual processes. After the kills are
completed synchronously, the cgroup can be unfrozen to allow for
restarts. Before freezing the cgroup, the binder interfaces of the
processes about to be frozen are also frozen to prevent indefinite
blocking by synchronous Binder callers.
Bug: 236708592
Bug: 148425913
Test: raven:/ $ monkey -p com.haok.nirvana 1
Test: bash arg: -p
Test: bash arg: com.haok.nirvana
Test: bash arg: 1
Test: args: [-p, com.haok.nirvana, 1]
Test: arg: "-p"
Test: arg: "com.haok.nirvana"
Test: arg: "1"
Test: data="com.haok.nirvana"
Test: Events injected: 1
Test: ## Network stats: elapsed time=14ms (0ms mobile, 0ms wifi, 14ms not connected)
Test: raven:/ $ ps -eo pid,uid,ppid,name|grep 10266
Test: 2499 10266 823 com.haok.nirvana
Test: 2577 10266 823 com.haok.nirvana:resident
Test: 2584 10266 823 android.media
Test: 2669 10266 1 app_d
Test: 2672 10266 1 app_d
Test: raven:/ $ am force-stop com.haok.nirvana
Test: raven:/ $ ps -eo pid,uid,ppid,name|grep 10266
Test: 1|raven:/ $
Test: atest PermissionControllerHostTest
Change-Id: I1718a9263a01d18da7e3d2e3771091cf8475e599
* changes:
Make the CE key always be encrypted by the synthetic password
Give all users SP-based credentials
Unlock user keys from LockSettingsService only
Merge WakeLock trace tracks into "WakeLocks" and SuspendBlocker tracks
into "SuspendBlockers" to create fewer tracks and make traces easier
to navigate.
Test: WakeLock/SuspendBlocker traces appear
Bug: 250614152
Change-Id: Ifadc31368d5ea3c5954aeef0d0d056a66ff94213
Addresses a security vulnerability where a (-8) length object would
cause dataPosition to be reset back to the statt of the value, and be
re-read again.
Bug: 240138294
Test: atest ParcelTest BundleTest AmbiguousBundlesTest
Test: manually ran PoC
Change-Id: I1ab1df6f2a802d8cdf02c89c12959b09d7b1a5c4
Merged-In: I1ab1df6f2a802d8cdf02c89c12959b09d7b1a5c4
Currently, whenever an LSKF isn't set, the CE key isn't encrypted by the
SP but rather by a non-auth-bound Keystore key. This is inconsistent,
and it's preventing us from taking advantage of the secure deletion
support of Weaver (on devices that support Weaver), with the current
scheme relying entirely on rollback resistance support in Keystore.
Therefore, make the CE key always be encrypted by the SP-derived key.
To do this, encrypt the CE key by the SP-derived key when the SP is
initially created. After the corresponding vold change, this will start
being the only time that the CE key is written to disk at all.
Also re-encrypt the CE key of existing users who don't have an LSKF, so
that we don't have to continue to support the legacy scheme.
Both operations are done via the new vold method setUserKeyProtection()
(accessed via StorageManagerService), which (re-)encrypts the CE key
using the given secret. The CE key must be either not-yet-persisted or
default-encrypted. This method replaces addUserKeyAuth(),
clearUserKeyAuth(), and fixateUserKeyAuth().
On the unlock side, make unlockUserKeyIfUnsecured() unwrap the SP and
unlock the CE key using it. As this makes
tryDeriveVendorAuthSecretForUnsecuredPrimaryUser() no longer needed,
remove that too.
Test: atest com.android.server.locksettings && \
atest com.android.server.am.UserControllerTest \
com.android.server.pm.UserManagerServiceTest \
com.android.server.pm.UserManagerTest
Test: Booted and rebooted Cuttlefish, both phone and auto builds
Test: Without the CLs in this topic, set up a Pixel 6 to have a user
with an LSKF, a user with no LSKF or SP, and a user with an SP but
no LSKF. Upgraded to the CLs in this topic. Checked log for
the expected messages from LockSettingsService. Verified that all
the users can still be unlocked. Verified that
/data/system_de/$userId/spblob exists for all users, and that
/data/misc/vold/user_keys/ce/$userId/encrypted_key exists but not
a keymaster_key_blob file alongside it. Verified that
/data/system/locksettings.db contains
migrated_all_users_to_sp_and_bound_ce=true.
Bug: 232452368
Change-Id: Ia753ea21bbaca8ef7a90c03fe73b66c896b1536e
In preparation for making the CE key of each user always be protected by
the user's synthetic password even when the user has no LSKF, make
LockSettingsService the sole caller of IStorageManager.unlockUserKey().
For the opportunistic secret-less unlock by UserController at user start
time, call a new method LSS.unlockUserKeyIfUnsecured(). For now this
method calls IStorageManager.unlockUserKey() with a null secret. Later
it will unwrap the user's synthetic password if needed.
For the unlock via credential verification that is triggered by LSS,
make LSS call IStorageManager.unlockUserKey() before calling
IActivityManager.unlockUser(), rather than passing the SP-derived secret
to IActivityManager.unlockUser() for it to do the unlockUserKey().
Since neither the secret nor the token arguments to
IActivityManager.unlockUser() are used anymore, add a new method
IActivityManager.unlockUser2() that lacks these arguments. Note that
method name overloading cannot be used because AIDL doesn't support it.
Test: atest com.android.server.locksettings && \
atest com.android.server.am.UserControllerTest \
com.android.server.pm.UserManagerServiceTest \
com.android.server.pm.UserManagerTest
Test: Boot and reboot Cuttlefish
Bug: 232452368
Change-Id: I8971b92bb5055fca8e19e0f9d14e8f0a7022b453
We have @NonNull annotations, but not everyone is watching the warning
messages related to them. Make the implementation a bit more robust
by swapping in the "(null)" literal when someone accidentally leaks
one through.
Bug: 249325721
Test: atest FrameworksCoreTests:TraceTest
Change-Id: Ic0f5a0236fbce88e086f3d68b2e5c6ed6b0aa33c
Modified remove user flow to delete the associated profiles when
deleting the user.
Test: atest UserManagerTest
Bug: 217758779
Change-Id: If0943cedd3892789f41cacbd4e0311fb9061b719
This API will get the advertised memory size from the bootloader parameter
passed to the kernel. The advertised memory size might be different from
the MemTotal value in /proc/meminfo. This could be due the original design
manufacturer (ODM) reserved part of the memory for the Trusted Execution
Environment.
Test: Run test caes
Bug: 231718727
Change-Id: I06494cb9013048d73a83f2180a9241c2259d46eb
The method parseSize() will parse the strings that match
the regular expression:
"^((\\s*[-+]?[0-9]+)\\s*(B|K|KB|M|MB|G|GB|Ki|KiB|Mi|MiB|Gi|GiB)\\s*)$"
For example: 12GB, +100MB, 23MiB.
It will return the size in bytes.
Test: atest
Bug: 231718727
Change-Id: Id4b9084d2ff8a0a8bd23ddb8a7e10dcf17391c49
Prior to this CL, WorkSources would Parcel their list of WorkChains as
-1 if null, or the size of the list followed by the list itself if
non-null. When reading it back in, on the other hand, they would check
if the size was positive, and only then read the list from the Parcel.
This works for all cases except when the WorkSource has an empty but
non-null list of WorkChains as the list would get written to the parcel,
but then never read on the other side.
If parceling a list was a no-op when empty this wouldn't be an issue,
but it must write at least its size into the parcel to know how many
elements to extract. In the empty list case, this single element is left
unread as the size is not positive which essentially corrupts any future
items read from that same parcelable.
Bug: 220302519
Test: atest android.security.cts.WorkSourceTest#testWorkChainParceling
Change-Id: I2fec40dfced420ca38e717059b0e95ee8ef9946a
Drop invalid data when writing or reading from XML. PersistableBundle
does lazy unparcelling, so checking the values during unparcelling would
remove the benefit of the lazy unparcelling. Checking the validity when
writing to or reading from XML seems like the best alternative.
Bug: 246542285
Test: install test app with invalid job config, start app to schedule job, then check logcat and jobscheduler persisted file
Change-Id: Ie817aa0993e9046cb313a750d2323cadc8c1ef15
Previously, for each binder interface, we populated a cache of all
txn codes to names on the first binder txn to that interface. This
skewed the binder txn latency significantly for the first txn to an
interface.
Now, we lazily populate the cache on each new binder txn.
Test: atest open-prebuilt-calculator --rebuild-module-info
--tf-template metric_post_processor=
google/template/postprocessors/metric-file-aggregate.xml
(neglible startup time diff locally)
Bug: 246650647
Change-Id: Ib569ebe34e7ef6bb4fa6e53defedcb33ed824308
Current implementation only returns the Volumes for the current user.
In case of Cloned user this causes issues as Cloned user uses Media
Provider of User 0, thereby returning only Volume 0, causing problems in
assigning projectIds, and affecting storage calculation.
The projectId assignement happens via
MediaProvider.updateExternalStorageFileQuota.
Bug: 235321217
Test: atest android.appsecurity.cts.StorageHostTest
Change-Id: I617bae9b201fd66d7b62b6cbd1c48b9f276f1924
