This is needed to debug vold mounting errors before adb is up. It also
helps diagnose failures on devices that store dmesg persistently.
Tested by adding an error log with serial attached.
Bug: 205314634
Test: manual test
Change-Id: Ia095340c562e3f1f94bc44c5d13ad466a7a35345
This patch adds more error logging to mountFstab. In a few cases, the
were error paths with no existing error logs. In other cases, the log
messages are there to help understand error flow in logs (for example
when a function with lots of error paths returns false).
Bug: 205314634
Test: treehugger builds
Change-Id: I464edc6e74ea0d7419ee9d9b75fd238752c13f4f
Default buffer size of 4 pages causes many missed log records
because of ring buffer overflows. This change adds a dynamic
sizing, up to 32 pages, that has shown to decrease dropped
records pretty much to nil
Fallback code automatically decreases the buffer size in case
of kernel memory fragmentation - some logs are still much
better than no logs at all
Bug: 203551890
Test: manual, adb install <Apk>; checked for fallback by
increasing max size to 1024 pages
Change-Id: I0ea46c1ad2534b1dbb5faaead52afab88b66747b
http://aosp/1845900 creates the directory with the wrong permission
and context. And when we attempt to fix it in http://aosp/1860276, the
device would fail to boot if the device is already on the bad build.
As a temporarily fix, already delete that checkin directory in vold. And
we can revert the deletion when the droidfood daily polulation gets out
of the bad state.
Bug: 203742483
Test: Update from TP1A.211016.001 and make sure the boot doesn't fail
Change-Id: Iec74528c1fe0e5876acc601e5cd008f99852d269
Gmscore runs in cache group, so set the own:group of the checkin
directory to system:cache to align with other use cases. Because we
want proper user separation when accessing the dir, also provide
user id to set the correct selinux mls_level.
Bug: 197636740
Test: check selinux label, make sure checkin can access the directory.
Change-Id: Id47a2a30a2f37c204ef72a81ac2aebe4ee3a37b0
- Original code of re-opening /proc/self/fd/fd does not work
due to selinux violation.
- fd (=pipe) passed over binder should be used as it is.
Bug: 202999256
Test: $ adb shell su root dumpsys vold
Change-Id: I1fceba89f1b07228e1677c266f87e431e93f7cb5
Vold stores some status in memory.
If vold crashed and restarted, those status are not
restored. Reboot device if vold on failure.
Bug: 202048432
Test: manually kill vold
Change-Id: Ic56acd9cc906b0166adf805023e34bbd6b3648a5
We need some storage on the device to backup the token for checkin
services. So users won't lose the checkin tokens when they clear
the app's storage. If the device accidentally loses the
token without backup, it won't be able to checkin again until
factory reset.
Because we want the token to be user specific, put it under misc_ce
and let vold create the sub-directory.
Bug: 197636740
Test: boot device, check selinux label of the dir
Change-Id: I0e19dcb7f4feb98fd9d1013cfd84b56ff1325373
CreateDevice() implicitly calls WaitForDevice(), which can impact boot
time if there are many uevents waiting to be processed. To alleviate
this, create an empty "userdata" device when vold starts (if metada
encryption is enabled). When it comes time to actually enable metadata
encryption, the device can be re-used and the subsequent Wait should be
much faster.
Bug: 198405417
Test: manual test; device boots
Change-Id: Iaacd10858272f17353475e25075ea1dda13f8fc4
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
