If fstrim thread creation or detachment is failed, wakelock can be leaked.
So move wakelock acquire to do_fstrim_filesystems function
Change-Id: I4da3164343af83fae3e5b01700f43d1752661276
Signed-off-by: Young-ho Cha <ganadist@gmail.com>
This is to accomodate the new keymaster1_device_t, which has an entirely
different interface.
Soon I'll provide a libkeymaster which provides a unified (and nicer)
interface for dealing with both v0 and v1 keymaster implementations
using a v1 keymaster API. For now this change is just so that vold will
build and run.
Change-Id: I5c54282c12d1c4b8b22ed4929b6e6c724a94ede4
This is to accomodate the new keymaster1_device_t, which has an entirely
different interface.
Soon I'll provide a libkeymaster which provides a unified (and nicer)
interface for dealing with both v0 and v1 keymaster implementations
using a v1 keymaster API. For now this change is just so that vold will
build and run.
Change-Id: I5c54282c12d1c4b8b22ed4929b6e6c724a94ede4
This is to accomodate the new keymaster1_device_t, which has an entirely
different interface.
Soon I'll provide a libkeymaster which provides a unified (and nicer)
interface for dealing with both v0 and v1 keymaster implementations
using a v1 keymaster API. For now this change is just so that vold will
build and run.
Change-Id: I5c54282c12d1c4b8b22ed4929b6e6c724a94ede4
Changing the device lock (even from swipe to none) will cause the
master key to be re-encrypted.
If at that point keymaster fails (e.g. due to an incompatible keymaster update)
cryptfs will write back the now-incomplete crypto metadata.
Upon next reboot, userdata can't be decrypted.
Now we don't bother writing on keymaster failure.
Bug: 19301883
Change-Id: I2b9a1278f8b4d333ac8d567e17e2263005e99409
This reverts commit 6a69cfc411.
The original fix seems to have led to boot failures in QA. Rather than
risk shipping, revert the change. Bug 18764230 reopened.
Requires change
https://googleplex-android-review.git.corp.google.com/#/c/629950/
Bug: 19278390
Bug: 19199624
Change-Id: Ia858c4db0abb917f9364ec8048f59ca4fb48e233
Don't use faccessat(AT_SYMLINK_NOFOLLOW). In Android, AT_SYMLINK_NOFOLLOW
is ignored. In glibc, it returns counter intuitive results when a
symbolic link is encountered, returning true all the time even though
an open(O_NOFOLLOW) will eventually fail.
Instead, stat the file and check to see if it's a regular file,
not a directory or symlink or some other weirdness.
In addition, fix a bug where isAsecInDirectory would return
true ("-1") if the asec directory didn't exist. It should return
false.
Bug: 18867827
Change-Id: I33d90e9095fad36ce0f83fde105b70f72e4eaef4
The strncpy operation does not write a 0 termination
if the name is larger than the target buffer.
Ensure that zero termination is always written using
safe strlcpy function.
Change-Id: Idb68cdff7cd1a860c1dfac7494fa99f3d382cb91
Using lseek on 64-bit offset parameter caused failure
to write persistent data in crypto footer.
Changed calls to use lseek64 instead.
Change-Id: I4e4c397a6d36201b8b08be3017e17c9fac3b34e4
The structure crypt_persist_data was allocated,
but never freed.
Added free of allocated memory in normal and
error case.
Change-Id: I9aaa067e6f6501e8ce007f8659004b5dbcf2b246
Add maybeenabledefaultencryption function, that encrypts based
on the encryption flag and appropriate environment variable
Bug: 18764230
Change-Id: Id9a1967d09a7ae63a51240c0a5f3c41505af0e9a
The libcrypto and libssl modules (and their respective static and host
versions) use LOCAL_EXPORT_C_INCLUDE_DIRS thus just including the module
is sufficient.
Additionally, cryptfs.h was including an OpenSSL header just to get the
length of a SHA-256 hash. Rather than force all users of this header to
also depend on libcrypto, it's easier just to define that value in the
header file.
Change-Id: I3e3e0db906a212e1093944b298e4a8ff2e2fb07d
Add maybeenabledefaultencryption function, that encrypts based
on the encryption flag and appropriate environment variable
Bug: 18764230
Change-Id: Id9a1967d09a7ae63a51240c0a5f3c41505af0e9a