GitLab

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

Change all function calls to strncpy to strlcpy.

Change-Id: I2bbefb7829d715847c5b26f4b9f0faddbd4c89d0

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

Change-Id: I31f5cd6fb4ff55d7cfe213f66955e3dbcbdff101

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

Bug: 18887435
Change-Id: Ibcb446fac954d9c42ebdfc4b684e6f3503337ab4

Change-Id: I53611cf8373daf638b0cc45b7b3d17e4d3e7247e

Since the dm_ioctl struct was being allocated on the stack as a large
character array, it was getting character alignment rather than the
proper alignment for the struct. GCC had been getting away with this
so far, but it's undefined behavior that clang managed to expose.

Bug: 18736778
Change-Id: Ied275dfad7fcc41d712b2d02c8a185f499221f57

-Wno-missing-field-initializers is used as well, but that is an
overzealous warning from initializing structs with {0} and not a
real warning.

bug 18736778 and 16868177

Change-Id: Iffde89cd7200d9a11193e1614f1819f9fcace30a

It looks like clang might have a miscompile that is causing SIGBUS in
`ioctl_init` when the device is encrypted. Move back to GCC until we
can sort this out.

Bug: 18736778
Change-Id: I21ae3b9d7d9ebff8679ecc1a828b7c59f27d0903

* commit '36859212':
  Move vold to libc++.

* commit '460a93a6':
  Move vold to clang so ASAN_ALL works.

Bug: 15193147
Change-Id: Ib868f1ed8145ca5cbfdb4cd60ed0c47a6182ac62

ASAN_ALL uses ASAN for anything built with clang. Since some of vold's
dependencies use clang, they will have unresolved ASAN symbols unless
vold is also built with clang. There's no harm in just moving this
project to clang.

Change-Id: Ia6f412beb7bf092121bff2a5a980531636adcdb9

* commit 'ab083da0':
  Set SELinux contexts on device nodes created by vold.

automerge: 512f0d52

* commit '512f0d52':
  cryptfs: [HACK] reboot if the crypto block dev failed to open

* commit '7776871d':
  cryptfs: extra debugging around crypto blockdev dm-... errors.

There are cases where the /dev/block/dm-0 fails to open.
This leads to the device not completing the boot up sequence.
Currently, the only way out is to reboot.

Bug: 17898962
Change-Id: If4583ebb1ef1ebdbaf680d69b876459aaec2f4ce
(cherry picked from commit 7fc1de8a)

Some times the /dev/block/dm-0 fails to open after it has been setup.
Log why.

Bug: 17576594
Bug: 17942270
Change-Id: If0bbfe22d84137f2029bacb10873832038f0d36c

* commit 'fc615041':
  Remove possibility of zero chars from passwords

scrypt pads the password with zeros. Our patterns use 0 to represent
the top left dot. So patterns that end there are equivalent to ones
that end one short.

After much thought, the best solution is to change the way we
represent patterns in keyguard. This, however, is a big change.

The short term solution is to change the pattern representation in vold
so that we are storing the correct thing. Later we will change keyguard
to handle patterns correctly and remove quite a few hacks from vold
(use of hex, this code). b/17840293 created to track this.

Bug: 17751714
Change-Id: I30cdffb0f0db406d2e2b6c54d4153d120d975318