Otherwise we get strange results when the time changes. Worst
effect is that the encryption takes a lot longer since we are
calling the logging code far more frequently.
Bug: 17625981
Change-Id: Ice29f28b3720e9e4a1ea28e45eeab574d1959ec1
Change-Id: I88ae719cdae490433390d624f75612a9f4f96677
Cryptfs : Enabling support for allow_discards in dmcrypt.
Cryptfs : Password matches
Cryptfs : test_mount_encrypted_fs(): Master key saved
TrustyKeymaster: Creating device
TrustyKeymaster: Device address: 0x7f8f416100
Cryptfs : keymaster version is 3
Cryptfs : Just asked init to shut down class main
ServiceManager: service 'drm.drmManager' died
ServiceManager: service 'media.audio_flinger' died
ServiceManager: service 'media.player' died
ServiceManager: service 'media.camera' died
ServiceManager: service 'android.security.keystore' died
Cryptfs : unmounting /data failed
Bug: 17576594
This change simply switches from the deprecated
EVP_{En|De}crypt{Init|Final} to the newer, _ex versions of the same.
There is no difference in behaviour, save for calling
EVP_CIPHER_CTX_init, as the deprecated versions are just wrappers around
the _ex functions. See
https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/evp_enc.c;h=f705967a40ab92cdf3c2ba8dd6bc19680d6157d6;hb=HEAD#l274
This change is required for the transition to BoringSSL, which removes
the deprecated functions.
Bug: 17409664
Change-Id: I35c6cc2d86d0c876a9edaff1e5571170fe393d87
Signed-off-by: Adam Langley <agl@google.com>
Correct implementations of keymaster should reject using an n-bit
RSA key to sign less than n bits of data, because we specify that
keymaster should not perform padding.
Change-Id: Ibdff1bbfbee84fd5bdbfb3149a124dbbaa7827fc
Note that this also changes the boot sequence, and moves the test for corrupted
data to cryptfs_restart_internal.
Bug: 17213613
Change-Id: I0f86e8fe3d482e2d1373bd0f4d0d861e63ad8904
In field reports, sometimes the remaining time gets stuck for many
minutes. This has to be caused by a spurious low reading early on which
cannot be overridded because of old logic.
Solution: allow time to increase but only by large amounts (avoid time
jittering up and down).
Bug: 16973374
Change-Id: I49d23ae8c54ded416cbedf383a3c03b33dc02e1c
Store salted scrypt of intermediate key in crypto header
When mount fails, check if matches, and if it does return error
code prompting a wipe
Bug: 11477689
Change-Id: I3dcf9e0c64f2a01c8ba8eaf58df82cbe717d421b
Set flag on starting encryption to say it failed, and only clear
when we get into a recoverable state (partially or fully encrypted.)
Go to recovery on seeing this flag on boot
Bug: 16552363
Change-Id: I7e452b653edf3a087ecfaba8f81f41765a1c8daf
When a crypto is enabled with a wipe flag (obsolete?),
it will correctly handle the fstab's choice for the fs type.
Remove the dead code for FAT_FS which was un-invocable.
Change-Id: I8d141a0d4d14df9fe84d3b131484e9696fcd8870
Signed-off-by: JP Abgrall <jpa@google.com>
The code was using encrypted_upto == 0 as an indicator that encryption
has succeeded. This meant that if no encryption happened, we would reboot
continually.
We now set encrypted_upto to fs_size when encryption is complete.
Also don't start to encrypt unless we are at 10% power. Stop when we
get to 5% power. This should lead to partial encryptions only very
rarely.
Bug: 15513202
Change-Id: I6214d78579d1fbbe2f63ee8862473d86a89d29b3
This reverts commit 5cc86c5741.
Without two more commits, this will break encryption. I'll re-commit when the other two pass code review.
Change-Id: I71720d065c16cf0f7f534e74ffe883f1e113c477
Stop encryption when battery is low, mark position, and continue on reboot.
Note - support for multiple encrypted volumes removed as no devices seem
to exist with an fstab that uses this feature. If you want support for such
a device, contact me and we will re-add it with appropriate testing.
Bug: 13284213
Change-Id: I1f7178e4f7dd8ea816cbc03ab5c4f6543e98acaa
If we are not to double prompt, we need to pass the password from
CryptKeeper to KeyStore. Since the entire framework is taken down
and restarted, we must store the password in a secure system daemon.
There seems no better way than holding it in vold.
Change-Id: Ia60f2f051fc3f87c4b6468465f17b655f43f97de
Add a call to vold that says if we decrypted the data partition. Reset the
flag so that it only returns true the first time.
Bug: 12990752
Change-Id: Ib00be87137c00fb8ad29205c85a3ea187764b702
Modify enablecrypto command to make the password optional. When it is
not there, default encrypt the device.
Remove a warning by making at least some parts of this file const-correct.
Bug: 11985952
Change-Id: Ie27da4c4072386d9d6519d97ff46c6dc4ed188dc
Store encryption type in crypto footer, and provide functions to
manipulate it. Add mount_default_encrypted command to vdc to allow
mounting of default encrypted volumes at boot time.
Bug: 8769627
Change-Id: Ie41848f258e128b48b579e09789abfa24c95e2b2
By setting ro.crypto.readonly to 1, cryptfs will mount an encrypted
filesystem that is normally mounted read-write as read-only instead.
To be used when recovery mounts /data.
Bug: 12188746
Change-Id: If3f3f9a3024f29ebc4ad721a48546a332cb92b6b
Prior to this, the Key derivation function would get
blindly updated even if the user entered the wrong password.
Now, we only attempt to upgrade the KDF if the pwd/key have
been verified (i.e. after a successful mount).
Bug: 11460197
Change-Id: I0469228cc9b87c47754e8ca3c7146651da177da5
Currently, if a non-framework process or service is using /data,
unmounting will fail as nothing will kill it.
Instead of rebooting on unmount failure, we now kill all processes
using /data, then try one more time.
Bug: 11291208
Change-Id: I6c5276c78aa55965914ace96e1db74dc80fca3c1
With the recent selinux changes imposed on vold, it no longer has
permission to run a shell, so invoking the filesystem formatting
commands with system(3) gives an error. So change to using
android_fork_execvp().
Bug: 10279958
Change-Id: Ifa18b28867618858ec7c5cfcc67935e377de38fb
scrypt is a sequential memory-hard key derivation algorithm that makes
it more difficult for adversaries to brute force passwords using
specialized equipment. See http://www.tarsnap.com/scrypt/scrypt.pdf for
more details of the algorithm.
This adds support for initializing disk encryption using scrypt and
upgrading from the previous PBKDF2 algorithm.
Change-Id: I1d26db4eb9d27fea7310be3e49c8e6219e6d2c3b
In order to make it easier to upgrade the crypto footer, extract some
constants to a header file instead. Then the header can control what the
current version is and the upgrade_crypto_ftr code should be the only
thing that needs to be updated.
Change-Id: I3ed5a7d3b640419cd8af91388d94a00de8cc09db
In the future, we'd like to have the ability to upgrade from any
supported version to any future version. Change the upgrade function
slightly to support this.
Change-Id: I3b20ccfff51c4c86f1e5e08690c263dc95ff5ce4
The new wipe option to the vold format command will invoke BLKDISCARD
on the partition before invoking newfs_msdos. This will be used whenever
a full wipe of the device is wanted, as this is more secure than just
doing newfs_msdos.
Bug: 9392982
Change-Id: Ie106f1b9cc70abc61206006d1821641c27c7ccae
The new selinux_reload_policy command can take a while to complete on
some systems. The reason is being investigated, and hopefully a fix can
be found to improve performance, but for now, increase the timeout that
vold waits for the post_fs_data section to complete when decrypting a
device on boot.
Also, emit a decent error message if the device times out.
Bug: 8967715
Change-Id: Ifb01c983dffe095a9de752c17c467a1751e9ce99
In order to display the correct language, timezone, airplane
mode and other settings on the decrypt screen, a copy of those
settings needs to be stored unencrypted so the framework can
query them. This adds support to vold to store up to 32
property like key/value pairs that are not encrypted.
Change-Id: Id5c936d2c57d46ed5cff9325d92ba1e8d2ec8972
Change vold to use the unified fstab. This includes both
support for sdcards, and changes to the crypto code to work
with some changes to the fs_mgr library api.
Change-Id: Id5a8aa5b699afe151db6e31aa0d76105f9c95a80
dm-crypt version 1.11.0 and later supports the allow_discards option
when setting up a crypto device. This passes discard requests from
the filesytem to the underlying block device. This helps make flash
based storage faster. So query the dm-crypt version, and pass the
option if the version is 1.11.0 or greater.
Change-Id: If30e9db5a2dbd6ea0281d91344e5b2c35e75131e
The previous problem of the framework not properly restarting after accepting
the password to decrypt the storage is also a problem when restarting the
framework to display the encryption progress screen. So like the previous
hacky fix, add a sleep to wait a few moments before proceeding. Also,
increase the sleep of the previous fix from 1 second to 2, as the problem
was seen once more in testing. A proper fix has been designed and hopefully
will work and be checked-in RSN.
Change-Id: Icc2c072ce7f7ebcdea22cd7ff8cb2b87a627c578
There is a race in the encryption code that after it accepts the
decryption password, it tells init to kill all the processes in
class "main", then it mounts the decrypted filesystem, preps it,
and restarts the framework. For an unknown reason on some devices,
the new framework sometimes starts up before init has killed and
reaped all the old processes. The proper fix is to make the killing
of the old framework synchronous, so vold waits till all the
processes have died. But with factory rom a few days away, the
much more pragmatic solution of adding a sleep of 1 second after
telling init to kill the old framework will suffice.
Bug: 7271212
Change-Id: Ie971cd04abbc6f3f6500b4acd79d3b3b26d9561c
The kernel seems to return from umount(2) sometimes before it has
released the underlying block device. So until the kernel is fixed,
try up to 10 times to load the crypto mapping table, waiting 500 ms
between tries.
bug: 7220345
Change-Id: Iad3bbef37cbe2e01613bb8a8c4886babdecb8328
When creating a new file using open(..., O_CREAT), it is an error
to fail to specify a creation mode. If a mode is not specified, a
random stack provided value is used as the "mode".
This will become a compile error in a future Android change.
Change-Id: I761708c001247d7a2faac2e286288b45bfecc6f7
Now that forward locked apps are stored on /data as asec image files
that are mounted, they need to be unmounted before /data can be unmounted
so it can be encrypted.
Change-Id: I7c87deb52aaed21c8ad8ce8aceb7c15c2338620a
The new filesystem manager is in charge of mounting the block devices now,
removing much of the knowledge from init.<device>.rc. This also let us
clean up some init code dealing with encryption, so this change updates
vold to work with that. More cleanup is possible, but the main goal of the
filesystem manager was to enable e2fsck, not a full cleanup of encryption.
Change-Id: I00ea80a923d14770ed8fdd190e8840be195f8514
The new filesystem manager is in charge of mounting the block devices now,
removing much of the knowledge from init.<device>.rc. This also let us
clean up some init code dealing with encryption, so this change updates
vold to work with that. More cleanup is possible, but the main goal of the
filesystem manager was to enable e2fsck, not a full cleanup of encryption.
Change-Id: I00ea80a923d14770ed8fdd190e8840be195f8514
Needed for headless devices that need to recover with no user intervention
Bug: 5556856
Change-Id: I0f85591df513a6893324fb057bde114ac1df044b
Signed-off-by: Mike Lockwood <lockwood@google.com>
If there is filesystem damage on a non-encrypted device, and /data is not
mountable, and if the device stores the keys in a file on a different
partition (like on Crespo) then, vold would return an error which caused
the crypto UI to present an option to the user to wipe the device because
it assumed encryption had failed. This fixes it to not do that.
Change-Id: Ibff6299787b45768416dbc4052de7db3b140b808
This vold command returns 0 if the given password matches the password
used to decrypt the device on boot. It returns 1 if they don't match,
and it returns -1 on an internal error, and -2 if the device is not encrypted.
Also check the uid of the sender of the command and only allow the root and
system users to issue cryptfs commands.
Change-Id: I5e5ae3b72a2d7814ae68c2d49aa9deb90fb1dac5
If a raw block is specified for key storage, do not try to force the size
of the file to 16 Kbytes when writing the keys, and do not complain if
the size is not 16 Kbytes when reading the keys. Only do them if the
keyfile is a regular file.
Change-Id: I4de1cb7c3614479d93289d4f2767ca6ce1bbbc73
Add the force_and_revert option to the unmount command which will force
the unmount, and revert a crypto mapping. This is used during factory
reset so that when the internal sdcard volume is formatted, it formats
the raw device, not the encrypted mapping.
Change-Id: I36b6ff9bb54863b121de635472a303bf4a2334a9
Mounting was already not allowed, but also unshare before starting
encryption, and don't allow sharing or formatting to be initiated
during encrytion.
Change-Id: Ida188d81f025739ba4dd90492b3e66088735991e
Forgot to include the size of the userdata partition when computing
the total size of vold managed volumes to encrypt.
Change-Id: I237548439d4380b4225ffbc603fa972c3b1c5bae
Add support for keeping the keys in a separate file on another partition,
for devices with no space reserved for a footer after the userdata filesystem.
Add support for encrypting the volumes managed by vold, if they meet certain
criteria, namely being marked as nonremovable and encryptable in vold.fstab.
A bit of trickiness is required to keep vold happy.
Change-Id: Idf0611f74b56c1026c45742ca82e0c26e58828fe
Fix for bug 3415286. Trigger an action in init.rc to load the persistent
properties after /data has been decrypted and mounted.
Change-Id: I5fe3b481bcc6963113e830728c204b22ffc3b722
The new android_reboot() function is a nicer way to reboot.
It can optionally sync(2) and remount as read-only writable
filesystems. This fixes bug 3350709.
Change-Id: I4618bd5e8cccdce08494a7ca3f40ef72b2875e68
Need to detect if the encryption process didn't finish successfully, and if
so, provide a way for the UI to detect that and give the user an option to
wipe the system clean. Otherwise, the user is stuck in a reboot loop, and
they will need to do magic button presses to enter recovery and wipe the
device to get out of it.
Change-Id: I58253e1e523ee42bdd1a59aa7d8a9d20071bd18b
Bug 3384231 is punted to MR1, but the code to set the flag is already
in the tree, so this CL does 3 things:
1. Comments out the lines that set the flag
2. Removes the change to the checkpw that was added in the last change.
3. Implements a new command to check the flag (which no one is calling
yet and the flag won't be set anyhow).
When MR1 comes, it will be a simple matter to enable the flag setting
code and start testing it.
The fear is a false positive detection of incomplete encryption could
cause people to be prompted to wipe their data when MR1 comes out and
the flag is checked. Not setting this for first release, and testing
this more before MR1, will give us confidence that the code will not
detect false positives of encryption failure.
Change-Id: I6dfba11646e291fe5867e8375b71a53c815f3968
For the case there encryption failes to complete because of a kernel
crash or the user power cycling the device, define a flag in the
crypto footer that says encryption is in progress. Set it when starting
the actual encryption, and clear it when it successfully completes.
When the user is asked for the disk password, if the flag is set,
return a special error to the caller so the UI can know to tell the
user there is no valid data on the disk, and present a button to
wipe and reset the device.
Change-Id: I3723ec77f33437d94b3ac9ad5db0a5c950d11648
The Progress bar UI grabs a full wakelock when encrypting, but we've seen
a case where it looks like the progress bar UI crashes, and the wakelock is
lost, and then all hell breaks loose. The enablecrypto command has a lot of
work to do, and it will take some time, so it should grab a wakelock to
ensure it can finish without being interrupted and put to sleep.
It grabs a partial wake lock, as it doesn't need the screen to be on to do
its work. If the UI wants to keep it on, it should also grab a full wakelock,
which it does. If the UI crashes, the screen may turn off, but the encryption
will keep going, and vold will reboot the device when it's done.
Change-Id: I51d3a72b8c77383044a3facb1604c1ee510733ae
If the already existing filesystem encompasses the entire /data partition
and does not leave the last 16 Kbytes for the crypto footer, refuse to
do encrypt in place and return an error. This is only an issue for folks
with early development systems trying to encrypt an old /data. This should
not be seen in released devices.
Also, if there is an error, try to report back to the UI what the error was
so it can deal with it.
Change-Id: If66781a4fe03034c96c3dd12075240deb8663db0
The master key is now stored unhashed in memory. This
is needed because certain operation like remote reseting
of passwords the old password is not avaliable.
The changepw interface has been changed to only take
the new password as the only argument. When this is
called we reencrypt the master key with the new password
and old salt.
Bug: 3382129
Change-Id: I9a596b89013194605d6d7790067691aa0dc75e72
In order to prevent rainbow table attacks on decrypting the master key,
create a 16 byte "salt" by reading /dev/urandom. This is done right after
reading urandom to get the master key for the filesystem. The salt is
stored 32 bytes after the end of the key (a padding added to help prevent
accidental overwriting of the salt) and the salt is fixed at 16 bytes long.
This change will make existing encrypted filesystems unusable.
Change-Id: I420549d064c61d38aea78eef4d86c88acb265ca3
Maintain and query some internal state to know if it's OK to run
the various cryptfs commands. Do not allow enablecrypto to run if
the device is already encrypted. Do no allow restart to run if
we have already run it before or if the password has not been
validated. Do not allow checkpw to run if not encrypted, or it
has already validated the password.
This is an extra layer of safety on top of the checks up in the
UI code agains possible DoS attacks on the device.
Change-Id: I9afc8d42773020e82a512e6b637feede101d1362
Also, change the value that triggers the progress bar framework from
"startup" to "0" in the property vold.encrypt_progress.
Change-Id: I3890e66a95283ce2ceeca82f516859b083919b9e
Update the enable inplace API to allow the UI to show a progress bar.
Add new command changepw (whichis currently not working)
Internal restructuring of code to support these two features.
Some minor cleanup of the code as well.
Change-Id: I11461fc9ce66965bea6cd0b6bb2ff48bcf607b97
In order to make the animations and the UI look right, we need to change
the cryptfs checkpw command to return a status if the password was
correct or not, and not have it automatically restart if it's correct.
There is a new command restart that will restart the framework with the
encrypted filesystem.
Change-Id: Ia8ae00d7ed8667699aa58d05ad8ba953cca9316e
Now that the framework shuts down quickly, remove the 30
second sleep when enabling crypto. Also, stop spewing
the secret master key to the disk in the system log!
Change-Id: Icb3f9456ababe3dff8de52cbbae92da0e9e5dd2f
There are still a few hacks and performance issues related
to shutting down the framework in this code, but it is
functional and tested. Without the UI changes, it requires
cryptic adb shell commands to enable, which I shall not
utter here.
Change-Id: I0b8f90afd707e17fbdb0373d156236946633cf8b
