This commit replaces the double quotations for library headers with
angle quotations.
Test: cd system/vold && mma
Change-Id: I3c14cfcf80f29173669409df548af84c1b39b96d
Merged-In: I3c14cfcf80f29173669409df548af84c1b39b96d
This commit reorders the include directives in cryptfs.cpp so that
upcoming <cutils/log.h> change can be obvious.
Test: lunch aosp_walleye-userdebug && cd system/vold && mma
Change-Id: I9d2ea66c15b7b68014a67ba7c1420075953459ba
Merged-In: I9d2ea66c15b7b68014a67ba7c1420075953459ba
This commit adds <linux/types.h> to cryptfs.h because cryptfs.h uses
`__le16` and `__le32` which are defined in <linux/types.h>.
The absence of <linux/types.h> will become an error after we sort the
headers in the upcoming commits.
Test: cd system/vold && mma
Change-Id: I9930105ee86f80a29295b59596b21335c68a8e23
Merged-In: I9930105ee86f80a29295b59596b21335c68a8e23
This commit replaces <cutils/log.h> and <utils/Log.h> with <log/log.h>.
Background:
<cutils/log.h> has been moved to <log/log.h> for a while. Both
<cutils/log.h> and <utils/Log.h> simply includes <log/log.h> for
backward compatibility. This commit is a part of the effort to remove
<cutils/log.h> and <utils/Log.h> from the source tree eventually.
Bug: 78370064
Test: lunch aosp_walleye-userdebug && cd system/vold && mma
Change-Id: I1f9b7b132f9c35469e97556a30b521cc47e829d7
This commit replaces the double quotations for library headers with
angle quotations.
Test: cd system/vold && mma
Change-Id: I3c14cfcf80f29173669409df548af84c1b39b96d
This commit reorders the include directives in cryptfs.cpp so that
upcoming <cutils/log.h> change can be obvious.
Test: lunch aosp_walleye-userdebug && cd system/vold && mma
Change-Id: I9d2ea66c15b7b68014a67ba7c1420075953459ba
This commit adds <linux/types.h> to cryptfs.h because cryptfs.h uses
`__le16` and `__le32` which are defined in <linux/types.h>.
The absence of <linux/types.h> will become an error after we sort the
headers in the upcoming commits.
Test: cd system/vold && mma
Change-Id: I9930105ee86f80a29295b59596b21335c68a8e23
This activates device GCs in idle time.
F2FS GC = 7 mins
Trim = 1 mins
Dev GC = 2 mins
Bug: 63264275
Bug: 68721792
Change-Id: I843a742ef192ebe00d77c47a216d4200bc9ccb9d
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Until VerificationTokens are wired up, StrongBox can't work. Also,
this will reduce complications for early StrongBox testing.
Bug: 77338527
Test: Boot the device
Change-Id: I44a1577c388703aeecb2886e7db52084c17e2afd
Since we no longer have the Fuse Daemon, we won't ever
need to stop the daemon when unmounting.
Bug: 33808187
Test: Run "adb shell ps | grep -w Z"
The sdcard daemon should not be listed.
Change-Id: I6bb9341785b711d81553393f7c3b56115c435236
Due to rerouting ArcBridge call through System Server, Vold doesn't need
to depend on ArcBridge-related C++ library anymore.
Bug: 64500663
Test: Compiled.
Change-Id: Ic93cbc8cec8496784960d5093fb7b12d43574ced
This is needed to allow ARC++ Vold to interact with ArcBridgeService
through SystemServer.
Bug: 64500663
Test: Compiled, tested on device + cts in master-arc-dev (ag/3488659)
Change-Id: I3b05b0f456ec99be9163877a2d83cdbf2bb94991
Instead of hardcoding to "aes-cbc-essiv:sha256" with a 16 byte
key, we introduce a new property, "ro.crypto.fde_algorithm",
to allow the use of different crypto types. The only other
method we currently support is "speck128-xts-plain64" with
a 32 byte key, although new crypto types are easily added.
We intentionally derive things like the crypto name and the
keysize from the given property name. This means the code
must be changed for each new crypto type we want to support,
but that's worth it to remove the exploit vector of crypto
types with incorrect key sizes.
Due to previous refactoring CLs, this has minimal impact on
the current code other than changing what we return for
cryptfs_get_{keysize,crypto_name}.
Bug: 73079191
Test: Flashed onto a gobo device with the property set for SPECK, and confirmed via kernel debug output we were using SPECK on the device.
Change-Id: I9c9df61590344c5f62114dfbf679031b0c2ceb1f
Our external partitions have no crypto header/footer, so we
only get the keysize and key. Our code has been implicitly
assuming that this keysize off of disk matches the crypto
type we have in our code (and thus matches the keysize our
code is using as well). We now make this assumption
explicit, and check for this and no longer allow external
code to pass a keysize in to cryptfs.
Bug: 73079191
Test: Compiled and tested in combination with other CLs.
Change-Id: I1a1996187e1aaad6f103982652b1bcdfd5be33ce
Our code has places where we were reading in the crypt_mnt_ftr
struct from disk, but then proceeding to use a hardcoded constant
for the keysize. We plan to allow crypto with different sized
keys in the future, so we want to just trust the keysize we get
off of disk.
While doing this, we reject any crypt_mnt_ftr we read from disk
which has a keysize in excess of MAX_KEY_LEN. This defends us
against buffer overflows in the case of corrupt disk data.
Bug: 73079191
Test: Compiled and tested in combination with other CLs.
Change-Id: Id6f192b905960e5508833e9cd3b4668d4754dc7e
