History log of /system/vold/cryptfs.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
92736efab068bdbfeb1177544907b84511fb04e0 18-Oct-2012 Ken Sumrall <ksumrall@android.com> Another fix for encryption

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
/system/vold/cryptfs.c
9dedfd473dc59e0277004e5b917e4eced02c8af5 09-Oct-2012 Ken Sumrall <ksumrall@android.com> Fix encryption on certain devices

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
/system/vold/cryptfs.c
b77bc4696b19d9b1ef82810f8d5f671c963d1dc1 01-Oct-2012 Jeff Sharkey <jsharkey@android.com> Update environment variable for multi-user.

Bug: 7260040
Change-Id: I96d821e11a3f0be32bfe92a4151f00f2b15d100e
/system/vold/cryptfs.c
e919efea94b178ed214ed2e78ef0d008727d62ab 30-Sep-2012 Ken Sumrall <ksumrall@android.com> Workaround a kernel race when loading dmcrypt table

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
/system/vold/cryptfs.c
7382f81fba895f1ac970ac2fad875f35836b8082 23-Aug-2012 Jeff Sharkey <jsharkey@android.com> Unmount external storage on multi-user devices.

Bug: 7044670
Change-Id: If1f99968b0392cae9420d067c75bfc18d1067b2c
/system/vold/cryptfs.c
912d0b07555eb691f0320530c4e0f6ab85521e95 29-Jun-2012 Ken Sumrall <ksumrall@android.com> Merge "Fix a typo in cryptfs.c"
319369ac111aec79b42668477c998c36b5f3be06 28-Jun-2012 Ken Sumrall <ksumrall@android.com> Fix a typo in cryptfs.c

Change-Id: If629fa996b135e432bc89da7518b0c1f02750b45
/system/vold/cryptfs.c
4684e58a8d1d502012c48295233e6663043cfb0b 27-Jun-2012 Nick Kralevich <nnk@google.com> Add mode when open(O_CREAT) is used.

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
/system/vold/cryptfs.c
425524dba1552ab3d2ad39e205e65d0a2af997f2 15-Jun-2012 Ken Sumrall <ksumrall@android.com> Unmount all asec apps before encrypting

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
/system/vold/cryptfs.c
e5032c42da3c33a854df0a24a7968b4ab54190b9 02-Apr-2012 Ken Sumrall <ksumrall@android.com> Changes to encryption to work with the new filesystem manager

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
/system/vold/cryptfs.c
f0679f0da4970f04e1cb03f4cb0fcde29e3e7098 02-Apr-2012 Ken Sumrall <ksumrall@android.com> Changes to encryption to work with the new filesystem manager

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
/system/vold/cryptfs.c
d02a47239c6a92a16530fd7101c53fd39eeae05c 10-Mar-2012 Ken Sumrall <ksumrall@android.com> Merge "Fix to not return a bogus decryption error when a device is not encrypted."
ee6d8c42f337ea1446a319df53f6d1a96afbd209 15-Feb-2012 Mike Lockwood <lockwood@google.com> Add support for wiping data immediately if crypt fails

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>
/system/vold/cryptfs.c
e1a458578474954ea38456aacedbaf2ddfd37988 15-Dec-2011 Ken Sumrall <ksumrall@android.com> Fix to not return a bogus decryption error when a device is not encrypted.

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
/system/vold/cryptfs.c
3ad9072a5d6f6bda32123b367545649364e3c11d 05-Oct-2011 Ken Sumrall <ksumrall@android.com> Add the new verifypw command to vold/cryptfs

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
/system/vold/cryptfs.c
3be890f59c04f94537f2f66f1d2841ed591f1a6e 15-Sep-2011 Ken Sumrall <ksumrall@android.com> Fix cryptfs to work with a raw block device for key storage

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
/system/vold/cryptfs.c
0b8b59719357fb80c330442787f7d5b1e332263b 01-Sep-2011 Ken Sumrall <ksumrall@android.com> Add the ability to revert a crypto mapping when unmounting a volume

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
/system/vold/cryptfs.c
3b17005083be230509480ea65ae67c237142fada 12-Jul-2011 Ken Sumrall <ksumrall@android.com> Prevent sharing or formatting of a vold managed volumes during encryption.

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
/system/vold/cryptfs.c
128626fc5aa3bf12d1ae5981c7f84f63625e8972 29-Jun-2011 Ken Sumrall <ksumrall@android.com> Fix to display the proper percentage complete during encryption.

Forgot to include the size of the userdata partition when computing
the total size of vold managed volumes to encrypt.

Change-Id: I237548439d4380b4225ffbc603fa972c3b1c5bae
/system/vold/cryptfs.c
319b1043bbbd410aa2d572d88b5936f26072d026 14-Jun-2011 Ken Sumrall <ksumrall@android.com> Don't abort the encryption process if an internal volume is present but unmounted.

It is not a failure if the SD card is not mounted.

Change-Id: If954f77c55ac124b9b7b39c89ffbafb4e5ea9e98
/system/vold/cryptfs.c
29d8da8cefa99e436c13295d4c9bad060ca18a6d 19-May-2011 Ken Sumrall <ksumrall@android.com> vold: allow to store key in a file on another partition

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
/system/vold/cryptfs.c
ad2ac33460d6ee1436b68bab1f820e3b6d3efeb4 09-Mar-2011 Ken Sumrall <ksumrall@android.com> Load persistent properties after mounting an encrypted /data partition.

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
/system/vold/cryptfs.c
c290eaf6852c6318584926c5e39b27672638891f 08-Mar-2011 Ken Sumrall <ksumrall@android.com> Teach vold to use the new android_reboot() function.

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
/system/vold/cryptfs.c
cd235da6fb36a5c7c90faf91e7d65a587f146f92 15-Feb-2011 Ken Sumrall <ksumrall@android.com> Enable detection of failed encryption process, for bug 3384231.

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
/system/vold/cryptfs.c
7f7dbaa2784c10fd2989fb303e5edfb8136d53dc 02-Feb-2011 Ken Sumrall <ksumrall@android.com> Improve detection of incomplete encryption

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
/system/vold/cryptfs.c
d33d417e3a057fffad22c23f5f002177531db2a5 01-Feb-2011 Ken Sumrall <ksumrall@android.com> Detect when encryption failed to complete

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
/system/vold/cryptfs.c
5d4c68e40700424b65a4331be75620706a0dd49c 31-Jan-2011 Ken Sumrall <ksumrall@android.com> Have vold grab a partial wakelock when encrypting

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
/system/vold/cryptfs.c
3f476690eaef3b824255813ed335284ef9a90e91 30-Jan-2011 Ken Sumrall <ksumrall@android.com> Merge "Don't try to encrypt in place a filesystem that is too large and return proper errors" into honeycomb
3ed8236de11a1be8b45d4c37b2208682f5e97c72 29-Jan-2011 Ken Sumrall <ksumrall@android.com> Don't try to encrypt in place a filesystem that is too large and return proper errors

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
/system/vold/cryptfs.c
70a4b3fd7a84a84bbe6e9d6d4ca3ee2098259fd9 28-Jan-2011 Jason parks <jparks@google.com> Change cryptfs changepw to only require a new password.

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
/system/vold/cryptfs.c
e87440703663f5ee326326f6438f3b00ea315623 19-Jan-2011 Ken Sumrall <ksumrall@android.com> Create and use a salt when calling pbkdf2 to encrypt/decrypt the master key.

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
/system/vold/cryptfs.c
0cc166385a7e1d3026bbcb62f094e419f779e872 19-Jan-2011 Ken Sumrall <ksumrall@android.com> Verify that it's OK to run the various cryptfs commands

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
/system/vold/cryptfs.c
7df84120b25dca713f623528801385b00208c2aa 18-Jan-2011 Ken Sumrall <ksumrall@android.com> Don't wait for the framework to come up before starting to encrypt in place.

Also, change the value that triggers the progress bar framework from
"startup" to "0" in the property vold.encrypt_progress.

Change-Id: I3890e66a95283ce2ceeca82f516859b083919b9e
/system/vold/cryptfs.c
57b63e61cb41e377708a4fdf18ecc80eb1b2b521 18-Jan-2011 Ken Sumrall <ksumrall@android.com> Minor tweaks to logging for the cryptfs changepw command.

Change-Id: I87ff9788a56de6d461002407bf6c3cd4c6f900ee
/system/vold/cryptfs.c
8ddbe40a8a8708dac7c472fa8c098c8f7b24534c 18-Jan-2011 Ken Sumrall <ksumrall@android.com> Updates to cryptfs framework.

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
/system/vold/cryptfs.c
6864b7ec94a57b73c300457955d86dc604aeddf5 15-Jan-2011 Ken Sumrall <ksumrall@android.com> Change the cryptfs command to separate out checking the password and restarting

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
/system/vold/cryptfs.c
2eaf7138528d30c331d83ab8346a97e66b5499e2 14-Jan-2011 Ken Sumrall <ksumrall@android.com> Cleanup a few issues with the cryptfs code.

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
/system/vold/cryptfs.c
8f869aa1bc685b505c58e97b4e11a9c7491a16f9 03-Dec-2010 Ken Sumrall <ksumrall@android.com> Support for encrypting /data on Stingray.

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
/system/vold/cryptfs.c