Correctly handle a key upgrade error from keymaster by upgrading the
FDE RSA key and writing the new key blob to disk.
Bug: 69792304
Test: Roll back PLATFORM_SECURITY_PATCH a month, wipe and reboot, roll
forwards again, check logs with and without this patch.
Change-Id: I220d2dd4e3d791f636e9bc5f063064cecbf1b88a
This patch formats f2fs paritition with proper flags.
Change-Id: Ie5ded1f2ceb3869771b2eaf9bea3b0966cab18c5
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
runIdleMaint is equivalent with:
1. echo 1 > /sys/fs/f2fs/sdX/gc_urgent
2. wait until /sys/fs/f2fs/sdX/dirty_segments
<= threshold or timeout
3. echo 0 > /sys/fs/f2fs/sdX/gc_urgent
4. fstrim
abortIdleMaint forces the wait loop above to exit and
skips fstrim. However, if fstrim is already running,
abortIdleMaint will just leave it run to completion.
Test: adb shell sm idle-maint [run|abort]
Bug: 67776637
Change-Id: I4adff8d9b6bbd63bce41368cea55dc9e9b117eb6
This is temporary. Keystore is in the process of being upgraded to use
the new Keymaster 4.0 HAL, and I want to leave vold alone, using
Keymaster 3.0 for the moment. This CL just copies relevant bits of
keystore support utilities into vold, so it can stop depending on the
copies from keystore.
After the keystore update is complete, vold will be changed either to
use Keymaster 4.0 or -- more likely -- to use keystore rather than
talking to Keymaster directly. At that point the files added by this CL
will be deleted.
Test: Device boots and successfully decrypts /data
Change-Id: I73f6d4cc4c5e20d89d7ac37d29d025bf279f9e12
A typical storage device finishes the benchmark in under 10 seconds,
but some extremely slow devices can take minutes, resulting in a
confusing UX that looks like we've frozen. Even worse, we keep
churning through all that I/O even though we know the device will
blow past our user-warning threshold.
So periodically check if we've timed out, and also use that to report
progress up into the Settings UI.
Test: manual
Bug: 62201209, 65639764, 67055204
Change-Id: I321397bcff230976f034cede0947d4a5a1f3e8a7
Remove lots of "extern C" and "ifdef __cplusplus" which are no longer
needed now all of vold is C++. Also turn on the cert-err58-cpp warning
we once had to disable.
Bug: 67041047
Test: compiles, boots
Change-Id: I8c6f9dd486f2409e0deed7bb648d959677465b21
Protect all per-volume-per-user keys with a per-volume key, which is
forgotten when the volume is forgotten. This means that the user's key
is securely lost even when their storage is encrypted at forgetting
time.
Bug: 25861755
Test: create a volume, forget it, check logs and filesystem.
Change-Id: I8df77bc91bbfa2258e082ddd54d6160dbf39b378
If it's not a keymaster key, don't try to invalidate or delete the key
blob.
Bug: 25861755
Test: Create and forget a volume, check logs and files.
Change-Id: If8bfb1a9ab41e6c7e46bc311eb296242e56d264f
When we set up encryption on real volumes - not just /data - we should
give them their own keys, so that these keys can be deleted when the
volume is forgotten. Also, we must choose the encryption modes
differently, since ICE encryption which works on /data may not work on
such volumes.
Bug: 25861755
Test: boot device, add SD card, check modes.
Change-Id: I354cd651757c3566dba046ae99d324833ad9b0e5
Minimize overhead in boot by replacing shell script invoked multiple
times with a C++ program invoked once.
Bug: 67901036
Test: create user, run adb shell ls -laZ /data/misc_ce/10; delete user
and check logs.
Change-Id: I886cfd6505cca1f5b5902f2071e13f48e612214d
FDE keys are indexed using the partition GUID, while FBE keys will be
indexed using the filesystem UUID, so pass both of those identifiers
along when forgetting a volume.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Bug: 25861755
Change-Id: I6e239d5ba67a01c9a848d705f6167da00f975924