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
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
Rather than use an integer and have a comment, we use a named
constant for sizing these master key buffers. This will help
avoid confusion when we switch to allowing different sized
master keys.
Bug: 73079191
Test: Build
Change-Id: Ifaffdd94d337bb2d5a178f818dfe00f9386ae03b
Some parts of the code were intermingling constants for the master
key and the intermediate key. That works at the moment because
these are the same size. But we'll be introducing logic allowing
different sized master keys, while keeping the intermediate the
same. To aid that introduction, we use separate constants for
the intermediate key.
Bug: 73079191
Test: Build
Change-Id: I22b1dbf18aff2f76229df1c898fc606d6c1af3ca
Instead of hardcoding to "aes-cbc-essiv:sha256", we introduce a
new property, "ro.crypto.crypt_type_name", to allow the use of
different crypt methods. The only other method we currently
support is "speck128-xts-plain64", although new methods are
easily added.
We intentionally derive things like the keysize from the given
crypt name, to reduce exploit vectors. We also only accept
crypt names the code has whitelisted.
The biggest impact is replacing the hard-coded KEY_LEN_BYTES.
For compile-time buffers, we use the MAX_KEY_LEN to assure they
will be big enough for any crypt type. For run-time sizing,
we use the value derived from our property.
Bug: 73079191
Test: On an encrypted gobo, booted successfully with (1) no property set, (2) proproperty set to invalid value (and confirmed we defaulted to aes), and (3) after wiping userdata, with property set to "speck128-xts-plain64", confirmed we were using SPECK.
Change-Id: Ic4e10840d6ee2a4d4df58582448e0f768e6f403f
Looking at the EVP_DecryptUpdate() documentation, we need a
buffer which isn't just the keysize, but also provides the
cipher block length minus one byte extra. For EVP_aes_128_cbc(),
that block length is 16, but we use the maximum block length to
be safe for any future cipher change.
For two of our decrypted_master_key usages, the buffer was
already sufficiently sized. But for one of our instances,
in cryptfs_enable_internal(), the buffer was previously
smaller than this. So this CL represents a possible behavior
change if we were ever overrunning that buffer.
Bug: 73079191, 73176599
Test: Flashed an encrypted sailfish and it booted.
Change-Id: Ic5043340910dc7d625e6e5baedbca5bd4b2bfb03
We're removing hardcoded buffer sizes in anticipation of allowing
different keysizes. In this case, our buffer was sufficiently
large for all current cases. But if we ever changed the
crypt_mnt_ftr struct to allow larger keys, this code will adjust
with the change.
Bug: 73079191
Test: Flashed an encrypted sailfish and it booted.
Change-Id: I261e729a77b351e287fbb55327564fe512a23d47
We were hardcoding the size of the ikey buffer, but then had logic
which used KEY_LEN_BYTES and IV_LEN_BYTES to offset into the array
and describe the length of its contents.
In anticipation of allowing the keysize to be set via a property,
instead of at compile time, we change this code to make the relation
between the keysize and the buffer size explicit.
Bug: 73079191
Test: Flashed an encrypted sailfish and it booted.
Change-Id: I109a5dc812662220e53163bfb4b5e51bf5abf185
We'll be allowing modifyable key sizes in the near future,
and want to remove this variable to reduce confusion with this
change.
Bug: 73079191
Test: None
Change-Id: I7047bb375553d8c46ff0724add697a5105ebc68c
During the analysis of b/72953784 it was noticed that vold was calling
keymaster abort() and failing, though vold was succeeding with its
keymaster operation. This had nothing to do with the bug, but the
presence of the error appeared to implicate keymaster, and it's bad
form in any case. This CL correctly clears the mDevice member during
a move, so the destructor will not attempt to call abort.
Test: Build & boot
Bug: 72953784
Change-Id: Ib0700f829e87f19b089396087085585ddd6b96a5
Don't use the FDE flow to support metadata encryption; just provide a
vold service which directly mounts the volume and use that.
Bug: 63927601
Test: Boot Taimen to SUW with and without metadata encryption.
Change-Id: Ifc6a012c02c0ea66893020ed1d0da4cba6914aed
This CL changes vold from using a KM3 device directly to using the KM4
support wrapper from the KM4 support library, which supports both KM3
and KM4 devices (KM0, 1 and 2 devices are still supported as well,
because the default KM3 device is a wrapper that uses them).
In addition, I found myself getting confused about which "Keymaster"
types were locally-defined vold keymaster types and which were from
the KM4 HAL and support library, so I changd the approach to
referencing the latter, so all of them are qualified with the "km::"
namespace reference.
Test: Build & boot
Change-Id: I08ed5425641e7496f8597d5716cb3cd0cbd33a7f
shipping API version:
For devices shipped before Android P nothing changes, data
is stored under /data/system/users/<user-id>/fpdata/...
Devices shipped from now on will instead store
fingerprint data under /data/vendor_de/<user-id>/fpdata.
Support for /data/vendor_de and /data/vendor_ce has been added to vold.
Bug: 36997597
Change-Id: I615e90d1c9ab08e768a8713968fa043598a0a526
Test: manually
Unfortunately, static library dependency is not transitive (even if the
dependency is a shared library). So I am wrapping the libarcobbvolume's
dependency as libarcmounter shared library.
Bug: 64500663
Test: Compile
Change-Id: I12be7a9d885c7c1c043185bd134e0148d420c6fd
Several partners have been requesting exFAT support. Android doesn't
natively support exFAT, but we're at least willing to try mounting an
exFAT filesystem if we detect the Linux kernel supports it, and if
helper binaries are present.
This CL is simple scaffolding, and it provides no actual
implementation of exFAT.
Test: builds, boots
Bug: 67822822
Change-Id: Id4f8ec3967b32de6e1c0e3c4b47fe6e43a6291ab
Remove FIDTRIM support, which isn't meaningful on UFS-based flash
devices. Modern devices require FBE/FDE which gives us better
protection against trimmed data lingering around.
Bug: 67041047
Test: builds, boots
Change-Id: I38d7d6961edf2047592b87c74b2a0f5906fb54e2
Merged-In: I4fb194c5d5ef13f413c02acedfbaaf79c567582b
This new flag isolates each user on a multi-user device for security
reasons.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.ExternalStorageHostTest#testSecondaryUsersInaccessible
Bug: 64672411
Change-Id: I3db8dde597a7715ca680779ac57957fb12a92f8e
This is how we tell CTS if the device has reserved blocks set aside
for system critical services.
Test: builds, boots
Bug: 62024591
Change-Id: I7c8ec2294b246eed54668b5717df00e72f13887a
This GID extends the ability to use reserved disk space, giving the
system a chance to be usable enough for the user to free up disk
space used by apps.
Test: builds, boots
Bug: 62024591
Change-Id: I8bc47911a71e1f399616caae83678e2914781c7e
Shawn Willden
Paul Crowley
Rubin Xu
Risan
TreeHugger Robot
Jeff Sharkey
Jaegeuk Kim
Greg Kaiser
Gao Xiang
Andreas Huber
Jeff Sharkey