2021-02-12 23:24:10 +01:00
|
|
|
package {
|
|
|
|
|
default_applicable_licenses: ["Android-Apache-2.0"],
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-23 22:38:55 +02:00
|
|
|
cc_defaults {
|
|
|
|
|
name: "vold_default_flags",
|
|
|
|
|
|
|
|
|
|
cflags: [
|
|
|
|
|
"-Wall",
|
|
|
|
|
"-Werror",
|
|
|
|
|
"-Wextra",
|
|
|
|
|
"-Wno-missing-field-initializers",
|
|
|
|
|
"-Wno-unused-parameter",
|
|
|
|
|
"-Wno-unused-variable",
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
clang: true,
|
|
|
|
|
|
|
|
|
|
tidy: true,
|
|
|
|
|
tidy_checks: [
|
|
|
|
|
"-*",
|
|
|
|
|
"cert-*",
|
|
|
|
|
"clang-analyzer-security*",
|
2019-03-30 00:07:58 +01:00
|
|
|
"android-*",
|
2017-10-23 22:38:55 +02:00
|
|
|
],
|
|
|
|
|
tidy_flags: [
|
|
|
|
|
"-warnings-as-errors=clang-analyzer-security*,cert-*",
|
|
|
|
|
],
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cc_defaults {
|
|
|
|
|
name: "vold_default_libs",
|
|
|
|
|
|
|
|
|
|
static_libs: [
|
2019-11-27 11:53:51 +01:00
|
|
|
"libasync_safe",
|
2017-10-23 22:38:55 +02:00
|
|
|
"libavb",
|
|
|
|
|
"libbootloader_message",
|
2019-05-13 22:02:54 +02:00
|
|
|
"libdm",
|
2019-06-27 22:40:09 +02:00
|
|
|
"libext2_uuid",
|
2017-10-23 22:38:55 +02:00
|
|
|
"libfec",
|
|
|
|
|
"libfec_rs",
|
2018-11-29 15:15:08 +01:00
|
|
|
"libfs_avb",
|
2017-10-23 22:38:55 +02:00
|
|
|
"libfs_mgr",
|
|
|
|
|
"libscrypt_static",
|
|
|
|
|
"libsquashfs_utils",
|
|
|
|
|
"libvold_binder",
|
|
|
|
|
],
|
|
|
|
|
shared_libs: [
|
2018-10-03 02:40:44 +02:00
|
|
|
"android.hardware.boot@1.0",
|
2017-10-23 22:38:55 +02:00
|
|
|
"libbase",
|
|
|
|
|
"libbinder",
|
|
|
|
|
"libcrypto",
|
|
|
|
|
"libcrypto_utils",
|
|
|
|
|
"libcutils",
|
|
|
|
|
"libdiskconfig",
|
|
|
|
|
"libext4_utils",
|
|
|
|
|
"libf2fs_sparseblock",
|
2020-10-07 08:20:00 +02:00
|
|
|
"libgsi",
|
2017-10-23 22:38:55 +02:00
|
|
|
"libhardware",
|
|
|
|
|
"libhardware_legacy",
|
2019-12-02 19:50:12 +01:00
|
|
|
"libincfs",
|
2017-10-23 22:38:55 +02:00
|
|
|
"libhidlbase",
|
|
|
|
|
"libkeyutils",
|
|
|
|
|
"liblog",
|
|
|
|
|
"liblogwrap",
|
|
|
|
|
"libselinux",
|
|
|
|
|
"libsysutils",
|
|
|
|
|
"libutils",
|
|
|
|
|
],
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cc_library_static {
|
|
|
|
|
name: "libvold_binder",
|
|
|
|
|
defaults: ["vold_default_flags"],
|
|
|
|
|
|
|
|
|
|
srcs: [
|
2017-11-25 17:47:19 +01:00
|
|
|
":vold_aidl",
|
2017-10-23 22:38:55 +02:00
|
|
|
],
|
|
|
|
|
shared_libs: [
|
|
|
|
|
"libbinder",
|
|
|
|
|
"libutils",
|
|
|
|
|
],
|
|
|
|
|
aidl: {
|
|
|
|
|
local_include_dirs: ["binder"],
|
2019-12-02 19:50:12 +01:00
|
|
|
include_dirs: [
|
|
|
|
|
"frameworks/native/aidl/binder",
|
2020-01-20 04:37:52 +01:00
|
|
|
"frameworks/base/core/java",
|
2019-12-02 19:50:12 +01:00
|
|
|
],
|
2017-10-23 22:38:55 +02:00
|
|
|
export_aidl_headers: true,
|
|
|
|
|
},
|
2019-12-02 19:50:12 +01:00
|
|
|
whole_static_libs: [
|
2021-01-26 14:35:14 +01:00
|
|
|
"libincremental_aidl-cpp",
|
2019-12-02 19:50:12 +01:00
|
|
|
],
|
2021-02-26 00:16:11 +01:00
|
|
|
export_shared_lib_headers: [
|
|
|
|
|
"libbinder",
|
|
|
|
|
],
|
2017-10-23 22:38:55 +02:00
|
|
|
}
|
|
|
|
|
|
2017-11-27 10:01:35 +01:00
|
|
|
cc_library_headers {
|
|
|
|
|
name: "libvold_headers",
|
2019-10-02 08:31:17 +02:00
|
|
|
recovery_available: true,
|
2017-11-27 10:01:35 +01:00
|
|
|
export_include_dirs: ["."],
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-23 22:38:55 +02:00
|
|
|
// Static library factored out to support testing
|
|
|
|
|
cc_library_static {
|
|
|
|
|
name: "libvold",
|
|
|
|
|
defaults: [
|
|
|
|
|
"vold_default_flags",
|
|
|
|
|
"vold_default_libs",
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
srcs: [
|
2018-11-01 04:59:47 +01:00
|
|
|
"AppFuseUtil.cpp",
|
2017-10-23 22:38:55 +02:00
|
|
|
"Benchmark.cpp",
|
2018-08-28 10:58:49 +02:00
|
|
|
"Checkpoint.cpp",
|
2020-02-07 21:45:20 +01:00
|
|
|
"CryptoType.cpp",
|
2017-10-23 22:38:55 +02:00
|
|
|
"Devmapper.cpp",
|
|
|
|
|
"EncryptInplace.cpp",
|
2017-06-15 17:59:43 +02:00
|
|
|
"FileDeviceUtils.cpp",
|
2018-10-23 22:06:55 +02:00
|
|
|
"FsCrypt.cpp",
|
2017-10-23 22:38:55 +02:00
|
|
|
"IdleMaint.cpp",
|
|
|
|
|
"KeyBuffer.cpp",
|
|
|
|
|
"KeyStorage.cpp",
|
|
|
|
|
"KeyUtil.cpp",
|
|
|
|
|
"Keymaster.cpp",
|
|
|
|
|
"Loop.cpp",
|
|
|
|
|
"MetadataCrypt.cpp",
|
|
|
|
|
"MoveStorage.cpp",
|
|
|
|
|
"NetlinkHandler.cpp",
|
|
|
|
|
"NetlinkManager.cpp",
|
|
|
|
|
"Process.cpp",
|
|
|
|
|
"ScryptParameters.cpp",
|
|
|
|
|
"Utils.cpp",
|
|
|
|
|
"VoldNativeService.cpp",
|
2020-03-25 07:49:02 +01:00
|
|
|
"VoldNativeServiceValidation.cpp",
|
2017-10-23 22:38:55 +02:00
|
|
|
"VoldUtil.cpp",
|
|
|
|
|
"VolumeManager.cpp",
|
|
|
|
|
"cryptfs.cpp",
|
2018-01-19 02:55:18 +01:00
|
|
|
"fs/Exfat.cpp",
|
2017-10-23 22:38:55 +02:00
|
|
|
"fs/Ext4.cpp",
|
|
|
|
|
"fs/F2fs.cpp",
|
|
|
|
|
"fs/Vfat.cpp",
|
|
|
|
|
"model/Disk.cpp",
|
|
|
|
|
"model/EmulatedVolume.cpp",
|
|
|
|
|
"model/ObbVolume.cpp",
|
|
|
|
|
"model/PrivateVolume.cpp",
|
|
|
|
|
"model/PublicVolume.cpp",
|
2018-10-29 00:52:56 +01:00
|
|
|
"model/StubVolume.cpp",
|
2020-02-07 21:45:20 +01:00
|
|
|
"model/VolumeBase.cpp",
|
2020-02-07 21:51:56 +01:00
|
|
|
"model/VolumeEncryption.cpp",
|
2017-10-23 22:38:55 +02:00
|
|
|
],
|
2020-07-17 17:17:50 +02:00
|
|
|
product_variables: {
|
2021-01-20 06:53:15 +01:00
|
|
|
arc: {
|
|
|
|
|
exclude_srcs: [
|
|
|
|
|
"model/StubVolume.cpp",
|
|
|
|
|
],
|
|
|
|
|
static_libs: [
|
|
|
|
|
"libarcvolume",
|
|
|
|
|
],
|
|
|
|
|
},
|
2020-07-17 17:17:50 +02:00
|
|
|
debuggable: {
|
|
|
|
|
cppflags: ["-D__ANDROID_DEBUGGABLE__"],
|
|
|
|
|
},
|
|
|
|
|
},
|
2018-08-10 22:50:46 +02:00
|
|
|
shared_libs: [
|
2018-09-19 19:28:16 +02:00
|
|
|
"android.hardware.health.storage@1.0",
|
2021-01-26 14:35:14 +01:00
|
|
|
"android.hardware.health.storage-V1-ndk_platform",
|
Make vold use keystore2 instead of keymaster
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
|
|
|
"android.system.keystore2-V1-ndk_platform",
|
|
|
|
|
"android.security.maintenance-ndk_platform",
|
2021-01-14 02:27:42 +01:00
|
|
|
"libbinder_ndk",
|
Make vold use keystore2 instead of keymaster
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
|
|
|
"libkeymint_support",
|
2018-08-10 22:50:46 +02:00
|
|
|
],
|
Don't unmount /storage for early native processes
Motivation:
Early processes launched before the runtime APEX - that hosts the bionic
libs - is activated can't use the bionic libs from the APEX, but from the
system partition (which we call the bootstrap bionic). Other processes
after the APEX activation should use the bionic libs from the APEX.
In order to let both types of processes to access the bionic libs via
the same standard paths /system/lib/{libc|libdl|libm}.so, some mount
namespace magic is used.
To be specific, when the device boots, the init initially bind-mounts
the bootstrap bionic libs to the standard paths with MS_PRIVATE. Early
processes are then executed with their own mount namespaces (via
unshare(CLONE_NEWNS)). After the runtime APEX is activated, init
bind-mounts the bionic libs in the APEX to the same standard paths.
Processes launched thereafter use the bionic libs from the APEX (which
can be updated.)
Important thing is that, since the propagation type of the mount points
(the standard paths) is 'private', the new bind-mount events for the
updated bionic libs should not affect the early processes. Otherwise,
they would experience sudden change of bionic libs at runtime. However,
other mount/unmounts events outside of the private mount points are
still shared across early/late processes as before. This is made possible
because the propagation type of / is 'shared' .
Problem:
vold uses the equality of the mount namespace to filter-out processes
that share the global mount namespace (the namespace of the init). However,
due to the aforementioned change, the early processes are not filtered
out because they have different mount namespaces. As a result,
umount2("/storage/") is executed on them and this unmount event
becomes visible to the global mount namespace (because as mentioned before /
is 'shared').
Solution:
Fiter-out the early processes by skipping a native (non-Java) process
whose UID is < AID_APP. The former condition is because all early
processes are native ones; i.e., zygote is started after the runtime
APEX is activated. The latter condition is to not filter-out native
processes created locally by apps.
Bug: 120266448
Test: m; device boots
Change-Id: I054deedc4af8421854cf35be84e14995523a259a
2019-01-04 05:35:25 +01:00
|
|
|
whole_static_libs: [
|
|
|
|
|
"com.android.sysprop.apex",
|
2020-02-18 15:06:37 +01:00
|
|
|
"libc++fs"
|
Don't unmount /storage for early native processes
Motivation:
Early processes launched before the runtime APEX - that hosts the bionic
libs - is activated can't use the bionic libs from the APEX, but from the
system partition (which we call the bootstrap bionic). Other processes
after the APEX activation should use the bionic libs from the APEX.
In order to let both types of processes to access the bionic libs via
the same standard paths /system/lib/{libc|libdl|libm}.so, some mount
namespace magic is used.
To be specific, when the device boots, the init initially bind-mounts
the bootstrap bionic libs to the standard paths with MS_PRIVATE. Early
processes are then executed with their own mount namespaces (via
unshare(CLONE_NEWNS)). After the runtime APEX is activated, init
bind-mounts the bionic libs in the APEX to the same standard paths.
Processes launched thereafter use the bionic libs from the APEX (which
can be updated.)
Important thing is that, since the propagation type of the mount points
(the standard paths) is 'private', the new bind-mount events for the
updated bionic libs should not affect the early processes. Otherwise,
they would experience sudden change of bionic libs at runtime. However,
other mount/unmounts events outside of the private mount points are
still shared across early/late processes as before. This is made possible
because the propagation type of / is 'shared' .
Problem:
vold uses the equality of the mount namespace to filter-out processes
that share the global mount namespace (the namespace of the init). However,
due to the aforementioned change, the early processes are not filtered
out because they have different mount namespaces. As a result,
umount2("/storage/") is executed on them and this unmount event
becomes visible to the global mount namespace (because as mentioned before /
is 'shared').
Solution:
Fiter-out the early processes by skipping a native (non-Java) process
whose UID is < AID_APP. The former condition is because all early
processes are native ones; i.e., zygote is started after the runtime
APEX is activated. The latter condition is to not filter-out native
processes created locally by apps.
Bug: 120266448
Test: m; device boots
Change-Id: I054deedc4af8421854cf35be84e14995523a259a
2019-01-04 05:35:25 +01:00
|
|
|
],
|
2017-10-23 22:38:55 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cc_binary {
|
|
|
|
|
name: "vold",
|
|
|
|
|
defaults: [
|
|
|
|
|
"vold_default_flags",
|
|
|
|
|
"vold_default_libs",
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
srcs: ["main.cpp"],
|
|
|
|
|
static_libs: ["libvold"],
|
2018-05-16 01:12:20 +02:00
|
|
|
init_rc: [
|
|
|
|
|
"vold.rc",
|
|
|
|
|
"wait_for_keymaster.rc",
|
|
|
|
|
],
|
2017-10-23 22:38:55 +02:00
|
|
|
|
|
|
|
|
required: [
|
|
|
|
|
"mke2fs",
|
|
|
|
|
"vold_prepare_subdirs",
|
2018-02-07 23:41:26 +01:00
|
|
|
"wait_for_keymaster",
|
2017-10-23 22:38:55 +02:00
|
|
|
],
|
2018-08-10 22:50:46 +02:00
|
|
|
|
|
|
|
|
shared_libs: [
|
2018-09-19 19:28:16 +02:00
|
|
|
"android.hardware.health.storage@1.0",
|
2021-01-26 14:35:14 +01:00
|
|
|
"android.hardware.health.storage-V1-ndk_platform",
|
Make vold use keystore2 instead of keymaster
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
|
|
|
"android.system.keystore2-V1-ndk_platform",
|
|
|
|
|
"android.security.maintenance-ndk_platform",
|
2021-01-14 02:27:42 +01:00
|
|
|
"libbinder_ndk",
|
Make vold use keystore2 instead of keymaster
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
|
|
|
"libkeymint_support",
|
2018-08-10 22:50:46 +02:00
|
|
|
],
|
2021-01-20 06:53:15 +01:00
|
|
|
|
|
|
|
|
product_variables: {
|
|
|
|
|
arc: {
|
|
|
|
|
exclude_srcs: [
|
|
|
|
|
"model/StubVolume.cpp",
|
|
|
|
|
],
|
|
|
|
|
static_libs: [
|
|
|
|
|
"libarcvolume",
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
},
|
2017-10-23 22:38:55 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cc_binary {
|
|
|
|
|
name: "vdc",
|
|
|
|
|
defaults: ["vold_default_flags"],
|
|
|
|
|
|
|
|
|
|
srcs: ["vdc.cpp"],
|
|
|
|
|
shared_libs: [
|
|
|
|
|
"libbase",
|
|
|
|
|
"libbinder",
|
|
|
|
|
"libcutils",
|
|
|
|
|
"libutils",
|
|
|
|
|
],
|
|
|
|
|
static_libs: [
|
|
|
|
|
"libvold_binder",
|
|
|
|
|
],
|
|
|
|
|
init_rc: ["vdc.rc"],
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-07 23:41:26 +01:00
|
|
|
cc_binary {
|
|
|
|
|
name: "wait_for_keymaster",
|
|
|
|
|
defaults: ["vold_default_flags"],
|
|
|
|
|
|
|
|
|
|
srcs: [
|
|
|
|
|
"wait_for_keymaster.cpp",
|
|
|
|
|
"Keymaster.cpp",
|
|
|
|
|
],
|
|
|
|
|
shared_libs: [
|
|
|
|
|
"libbase",
|
|
|
|
|
"libbinder",
|
Make vold use keystore2 instead of keymaster
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
|
|
|
"libbinder_ndk",
|
2018-02-07 23:41:26 +01:00
|
|
|
|
Make vold use keystore2 instead of keymaster
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
|
|
|
"android.system.keystore2-V1-ndk_platform",
|
|
|
|
|
"android.security.maintenance-ndk_platform",
|
2018-02-07 23:41:26 +01:00
|
|
|
"libhardware",
|
|
|
|
|
"libhardware_legacy",
|
|
|
|
|
"libhidlbase",
|
Make vold use keystore2 instead of keymaster
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
|
|
|
"libkeymint_support",
|
2019-06-12 22:27:20 +02:00
|
|
|
"libutils",
|
2018-02-07 23:41:26 +01:00
|
|
|
],
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-23 22:38:55 +02:00
|
|
|
cc_binary {
|
|
|
|
|
name: "secdiscard",
|
|
|
|
|
defaults: ["vold_default_flags"],
|
|
|
|
|
|
|
|
|
|
srcs: [
|
|
|
|
|
"FileDeviceUtils.cpp",
|
|
|
|
|
"secdiscard.cpp",
|
|
|
|
|
],
|
|
|
|
|
shared_libs: ["libbase"],
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cc_binary {
|
2017-10-20 17:17:54 +02:00
|
|
|
name: "vold_prepare_subdirs",
|
2017-10-23 22:38:55 +02:00
|
|
|
defaults: ["vold_default_flags"],
|
|
|
|
|
|
2017-10-20 17:17:54 +02:00
|
|
|
srcs: ["vold_prepare_subdirs.cpp", "Utils.cpp"],
|
2017-10-23 22:38:55 +02:00
|
|
|
shared_libs: [
|
|
|
|
|
"libbase",
|
|
|
|
|
"libcutils",
|
2017-10-20 17:17:54 +02:00
|
|
|
"liblogwrap",
|
2017-10-23 22:38:55 +02:00
|
|
|
"libselinux",
|
2017-10-20 17:17:54 +02:00
|
|
|
"libutils",
|
|
|
|
|
],
|
|
|
|
|
static_libs: [
|
|
|
|
|
"libvold_binder",
|
2017-10-23 22:38:55 +02:00
|
|
|
],
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-25 17:47:19 +01:00
|
|
|
filegroup {
|
|
|
|
|
name: "vold_aidl",
|
|
|
|
|
srcs: [
|
|
|
|
|
"binder/android/os/IVold.aidl",
|
|
|
|
|
"binder/android/os/IVoldListener.aidl",
|
2019-11-19 10:16:03 +01:00
|
|
|
"binder/android/os/IVoldMountCallback.aidl",
|
2017-11-25 17:47:19 +01:00
|
|
|
"binder/android/os/IVoldTaskListener.aidl",
|
|
|
|
|
],
|
2018-09-15 06:28:50 +02:00
|
|
|
path: "binder",
|
2017-11-25 17:47:19 +01:00
|
|
|
}
|
