The android-4.14-stable and later kernels support the
FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY ioctls. This
has superseded the old way of adding fscrypt keys to the kernel, which
was to use the add_key() syscall to add keys to the "session" keyring.
On kernels that support the ioctls, Android doesn't use the obsolete
way. Since upgrading even just to Android 14 requires at minimum a
android-4.14-stable kernel (according to
https://source.android.com/docs/core/architecture/kernel/android-common#compatibility-matrix),
there is no need to support the obsolete way anymore.
Therefore, this commit removes the code that added and removed keys
to/from the session keyring. Now the ioctls are used unconditionally.
Flag: N/A for the following reasons:
- Removing obsolete code, which is fairly safe
- Very early code, so runtime flag cannot be used
- This topic also removes code from init, which cannot use aconfig
libraries because they do not support recovery_available
Bug: 311736104
Test: Build and boot Cuttlefish
Change-Id: I0d9abbda77b1ac838ea6f014dbe22ab032c0e5ae
We no longer support ro.apex.updatable=false case. Hence no need to read
it.
Bug: 297460439
Test: device boots
Change-Id: I9b71ea96052741073f092ca6abcfbe92a927128a
In this change, the logic to get the list of apexes is replaced with
the query to apexservice, which is the source of truth. This dedups
the manual scanning of /apex for the apex list, which should be
internal to apexd. (Note how vold_prepare_subdirs filtered out
directories with "@" character).
This also makes vold_prepare_subdirs immune to the upcoming changes:
/apex directory containing only bootstrap APEXes in the bootstrap NS.
Until now, getting the list of apexes by scanning /apex was okay
because of the accidental fact that /apex directory has directories
for all the apexes, not only bootstrap apexes.
Bug: 293949266
Bug: 293546778
Test: CtsPackageSettingHostTestCases
Change-Id: I3fe373ca6f4c2281439bb2449845a1a14357131e
These libraries are only used by vold on a device and gain no
benifit from being included as shared libraries.
Moving them to static saves disk space, memory, and cpu cycles from the
dynamic linker.
Checking on cuttlefish accross 3 reboots:
This saves 613827 bytes of storage from the installed-files, 44KB of
private dirty memory, 172KB of PSS when only looking at the
libraries, and 155KB of PSS when looking at libraries and heap/stack
with shomap.
go/shared-to-static for more info on how this was determined.
Test: m
Bug: 280829178
Change-Id: I29af66dd66f4087ff1820ca661dc6dc2ace841fc
This reverts commit 564f6c649a.
Reason for revert: Un-backporting.
Note: This is not a direct revert. We should keep the minor refactoring
in PublicVolume.cpp; no point making the code worse.
Test: Revert.
Change-Id: Ic03ed25ad15a2da974921542a20cd27224347f68
This CR, when paired with a functional NTFS implementation and the
corresponding SEPolicy updates, will allow NTFS USB drives to be mounted
on Android.
Bug: 254407246
Test: Extensive testing with an ADT-4 and NTFS USB drives.
Merged-In: If4197c4c588866c611cd6ba3483707d3cb0e0cf8
Change-Id: If4197c4c588866c611cd6ba3483707d3cb0e0cf8
Underscore character may cause bpf prog/map naming collision. For
example, x.o with map y_z and x_y.o with map z both result in x_y_z
prog/map name, which should be prevented during compile-time.
aosp/2147825 will prohibit underscore character in bpf source name
(source name derives the obj name). Existing bpf modules with underscore
characters in source name need to be updated accordingly.
Bug: 236706995
Test: build
Change-Id: Ie6ea47560b1d44de0a0d9d124e17616fee6b0922
The flag -warnings-as-errors embedded in tidy_flags
is difficult to process and error-prone.
They should be replaced with the new tidy_checks_as_errors list.
Bug: 229801437
Test: make tidy-system-vold
Change-Id: I801e73dce5f08fe1ca5bc49de633706ad2cdf986
Mounting encrypted OBB files has never worked reliably across devices,
partly due to its reliance on Twofish encryption support in the kernel.
This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been
required or even recommended for Android. It has never been enabled in
GKI, but even before GKI it wasn't required or recommended. Moreover,
this is now the only Android feature that still uses dm-crypt
(CONFIG_DM_CRYPT), and some devices don't have that enabled either.
Therefore, it appears that this feature is unused. That's perhaps not
surprising, considering that the documentation for OBBs
(https://developer.android.com/google/play/expansion-files) says that
they are deprecated, and also it explains OBBs as being app files that
are opaque to the platform; the ability of the platform to mount OBBs
that happen to be in a particular format is never mentioned. That means
that OBB mounting is probably rarely used even with unencrypted OBBs.
Finally, the usefulness of OBBs having their own encryption layer (in
addition to what the platform already provides via FBE) is not clear
either, especially with such an unusual choice of cipher.
To avoid the confusion that is being caused by having the broken code
for mounting encrypted OBBs still sitting around, let's remove it.
Test: atest StorageManagerTest # on Cuttlefish
Test: atest StorageManagerIntegrationTest # on Cuttlefish
Bug: 216475849
Change-Id: Iaef32cce90f95ea745ba2b143f89e66f533f3479
This allows for easier bumping of the KeyMint/Keystore2 version level.
At the moment this change should have no effect: the same dependency
is used, just reached via a default rather than explicitly.
However, when the Keystore2 version increases in the near future, using
this default should mean that no change is needed here: the default
definition will change to -V2 and this will be referenced here.
Test: TreeHugger
Change-Id: I7cec2cd8fac137e5ac7e95db06e738e94a3cc567
Ensure fuse_media gets included in every build
Bug: 202785178
Test: /system/etc/bpf/fuse_media.o is present
Change-Id: Ic9f88a1905eca66f67b94ce75a04b9b26b6ca7ca
Now that FDE is no longer supported, the "defaultcrypto" and "encrypt"
events are never triggered. Therefore, the actions in vdc.rc aren't
needed anymore.
Bug: 191796797
Change-Id: Icdff584ec664b3e038f0accdc826437d261fed51
The ndk_platform backend will soon be deprecated because the ndk backend
can serve the same purpose. This is to eliminate the confusion about
having two variants (ndk and ndk_platform) for the same 'ndk' backend.
Bug: 161456198
Test: m
Change-Id: I87554ce86da0f862568c5aa84a21e6613655eb25
The seed value is passed to vold early in startup so that the
key-encryption keys are bound to the seed. This is useful for systems
like auto, in which the Android device may not require credentials to
use. In that case, the device should be bound to the rest of the system
(the car, in the case of auto) to guard against theft.
Test: manual
Change-Id: I2e16387b0752a30ef226b5ddf32ebf955aa9610a
No longer needed now init listens for property changes on a
separate thread.
Bug: 186580823
Test: Cuttlefish boots successfully
Change-Id: I7dd1f85a73df6c2160ef8778703709e90309b9b4
Now that vold uses Keystore2 rather than the Keymaster HAL directly, and
also the new version of Keymaster is called "KeyMint" instead, replace
most of the references to Keymaster in vold with Keystore.
(I decided not to include the "2" in most places, as it seemed
unnecessarily precise in most places, and it would be something that
might need to keep being updated. Only Keystore.{cpp,h} really need to
care about the version number.)
I didn't rename many things in cryptfs.cpp, as that file will be going
away soon anyway. I also left "wait_for_keymaster" and "vdc keymaster
earlyBootEnded" as-is for now, as those are referenced outside vold.
Bug: 183669495
Change-Id: I92cd648fae09f8c9769f7cf34dbf6c6e956be4e8
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
This allows libincremental_aidl-cpp to be built via cc_library instead
of aidl_interface.
BUG: 181266844
Test: builds
Change-Id: I4f0bc82629c0df758467aa074274b30f9dc6718d
Added SPDX-license-identifier-Apache-2.0 to:
Android.bp
bench/inodeop_bench/Android.bp
tests/Android.bp
Bug: 68860345
Bug: 151177513
Bug: 151953481
Test: m all
Exempt-From-Owner-Approval: janitorial work
Change-Id: I91823c7097d7bee39a363a0c0cc30de13e4d7539
This reverts commit 8ed81fd9ca.
Reason for revert: Let me try one last time more carefully. According to https://googleplex-android-review.git.corp.google.com/q/%2522customize+stubvolume%2522 - this CL will flow to aosp branches (without vendor images) and 2 branches with vendor images. I have submitted the vendor CL for both branches now (ag/13366009 and ag/13371672). This should not break anything now.
Change-Id: I69aacceabfb70053387a3c156b49e06be65fe6e4
This reverts commit 0cf77b025d.
Reason for revert: The requird libarcvolume has been submitted to master (ag/13366009)
Change-Id: I86fada53aad2ec5faa497a9bcbce5435c35d040e
This allow ARC to customize StubVolume implementation in vendor
partition.
Bug: 132796154
Test: Customize the implementation of StubVolume and check on device.
Ignore-AOSP-First: Will cherry-pick to AOSP.
Change-Id: I626a7ed4113b6132bb456b3258ee4a93b4f8a72e
destroyDsuMetadataKey() / destroy_dsu_metadata_key() calls
android::gsi::GetDsuMetadataKeyDir() to query the DSU metadata
encryption key dir and destroy the key.
This releases the resource and allows consecutive DSU installations to
use the same key *directory*, but not the same key *blob*.
Bug: 168571434
Test: 1. Install a DSU system.
2. Boot the DSU system and reboot back to the host system.
3. Wipe the DSU installation.
4. DSU metadata key dir /metadata/vold/metadata_encryption/dsu/dsu is
destroyed.
Change-Id: Ib851177315a5a266807f46ccfd446de1848232cf
The interface which is imported by an unstable interface is 'unstable'
as well. Until now, the ODR violation checker in aidl has omitted an
interface imported, but it will be checked, accordingly, fix the current
problem
Bug: 146436251
Test: m nothing
Change-Id: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Merged-In: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Exempt-From-Owner-Approval: cp from internal
Regression introduced by
commit 7ebcc2bcfd
("Revert "[Vold] Conditional dependency to ARC++ ObbVolume"")
errantly removed the product_variables support for
-D__ANDROID_DEBUGGABLE__ when built for userdebug builds.
Restore stanza.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: adb-remount-test no longer reports a problem
Change-Id: Ia7e55d1174fa7fac2d934d4aac06d15e8be388af
This reverts commit aedae617fe.
Reason for revert: ArcObbVolume is not needed by ARCVM R and above.
Bug: 157885448
Test: trybot
Change-Id: I16395ac8b6902cedea263f51e306b297d719043f
This reverts commit dcbd4fcad2.
Reason for revert: ARC is migrating to ARCVM on R, which doesn't use AppFuse any more.
Change-Id: Ifd0bf92a79c0ff25d782bea44dd593f9502f1959
