Currently, the vold detects the factory reset by checking the
metadata encryption key. This logic is only valid when the
device is not in DSU mode.
Bug: 199222795
Test: run DSU installation on a Pixel device
Change-Id: Ib40bd44d2ef7c872eba177c9ccfefac8934a49e6
The userdata will be formatted by VOLD during bootup when the userdata
is not completed file system(EXT4 or F2FS).
For EXT4 on userdata and quota feature is enabled. the parameter quota
is incorrect in ext4::Format(). Change the parameter from
quotatype=prjquota to quotatype=usrquota:grpquota:prjquota.
Bug: 199802158
Test: run cts-on-gsi -m CtsAppSecurityHostTestCases -t
android.appsecurity.cts.StorageHostTest
Change-Id: Ibff10e8e67b4e6ffabea97f534ff6551aed91963
security_context_t has been marked as deprecated in libselinux from
version 3.2. Update to the `char*` type.
Bug: 190808996
Test: m
Change-Id: I6f40e161251c79893d41e12c368715736578aacc
Revert "Add deleteAllKeys to IKeystoreMaintenance"
Revert "Enable deleteAllKeys from vold"
Revert "Allow vold to deleteAllKeys in Keystore"
Revert submission 15521094-vold-deleteAllKeys
Reason for revert: Causes infinite loop in Trusty KeyMint
Reverted Changes:
I9c5c54714:Detect factory reset and deleteAllKeys
I2fb0e94db:Allow vold to deleteAllKeys in Keystore
Id23f25c69:Add deleteAllKeys to IKeystoreMaintenance
Ife779307d:Enable deleteAllKeys from vold
I4312b9a11:Enable deleteAllKeys from vold
Bug: 187105270
Change-Id: I8e2621bef234d0a59be422b8d1d8d52a91378a5e
If KM is upgraded from a version that does not support rollback
resistance to one that does, we really want our upgraded keys to
include rollback resistance. By passing this tag in when we use the
keys, we ensure that the tag is passed into the upgradeKey request
whenever it is made, which some KM implementations can use to add
rollback resistance to our keys.
Bug: 187105270
Ignore-AOSP-First: no merge path to this branch from AOSP.
Test: Manual
Change-Id: I6154fe26a10b60cd686cc60dbc2e0a85c152f43b
Where metadata encryption is enabled, if there is no metadata encryption
key present and we are generating one anew, then there has been a
factory reset, and this is the first key to be generated. We then call
deleteAllKeys to ensure data from before the factory reset is securely
deleted.
This shouldn't really be necessary; the factory reset call itself
should be doing this. However there are currently three factory reset
paths (settings, recovery, fastboot -w) and it is not clear that all
three are doing this correctly on all devices. Obviously an attacker
can prevent this code from being run by running a version of the OS
that does not include this change; however, if the bootloader is
locked, then keys will be version bound such that they will only work
on locked devices with a sufficiently recent version of the OS. If
every sufficiently recent signed version of the OS includes this change
the attack is defeated.
Bug: 187105270
Test: booted Cuttlefish twice, checked logs
Ignore-AOSP-First: no merge path to this branch from AOSP.
Merged-In: I9c5c547140e8b1bbffb9c1d215f75251f0f1354e
Change-Id: I9c5c547140e8b1bbffb9c1d215f75251f0f1354e
Where metadata encryption is enabled, if there is no metadata encryption
key present and we are generating one anew, then there has been a
factory reset, and this is the first key to be generated. We then call
deleteAllKeys to ensure data from before the factory reset is securely
deleted.
This shouldn't really be necessary; the factory reset call itself
should be doing this. However there are currently three factory reset
paths (settings, recovery, fastboot -w) and it is not clear that all
three are doing this correctly on all devices. Obviously an attacker
can prevent this code from being run by running a version of the OS
that does not include this change; however, if the bootloader is
locked, then keys will be version bound such that they will only work
on locked devices with a sufficiently recent version of the OS. If
every sufficiently recent signed version of the OS includes this change
the attack is defeated.
Bug: 187105270
Test: booted Cuttlefish twice, checked logs
Change-Id: I9c5c547140e8b1bbffb9c1d215f75251f0f1354e
Since every APEX requires at least one loop device, now most of the
block devices on a device are not managed by vold. This change removes
some log statements around block devices that vold is not aware of.
Test: device boots
Test: adb logcat
Change-Id: I8efa22023c1f888e75f40178fac464af4457df3c
The ndk_platform backend will soon be deprecated because the ndk backend
can serve the same purpose. This is to eliminate the confusion about
having two variants (ndk and ndk_platform) for the same 'ndk' backend.
Bug: 161456198
Test: m
Change-Id: I87554ce86da0f862568c5aa84a21e6613655eb25
The seed value is passed to vold early in startup so that the
key-encryption keys are bound to the seed. This is useful for systems
like auto, in which the Android device may not require credentials to
use. In that case, the device should be bound to the rest of the system
(the car, in the case of auto) to guard against theft.
Test: manual
Change-Id: I2e16387b0752a30ef226b5ddf32ebf955aa9610a
Don't call IKeystoreMaintenance::earlyBootEnded() too early on FDE
devices, so that keystore2 doesn't have to be restarted.
Bug: 192090857
Test: Tested FDE on Cuttlefish, both first and non-first boots.
Verified via log that earlyBootEnded is now called only when it
should be, and that keystore2 no longer has to be restarted.
Change-Id: I03f816db194a8276ad19ca99b3c8894e8a5fed23
(cherry picked from commit 4859e0ca0f)
Merged-In: I03f816db194a8276ad19ca99b3c8894e8a5fed23
