The name "pre_gki_level" is causing some confusion because not all
devices launching with Android R are subject to the GKI requirement.
(See b/161563110#comment11.) E.g., devices that use a 4.14-based kernel
are exempt from GKI. However, the encryption requirements still apply.
Just use __ANDROID_API_Q__ directly instead.
No change in behavior.
Change-Id: Id02ae1140845ac1ae7cf78be4e57fe34da028abf
Block groups with EXT4_BG_BLOCK_UNINIT still have backup superblocks
(and backup block group descriptors). Fix EncryptInPlace to encrypt
these backup superblocks rather than leave them unencrypted.
Previously leaving the backup superblocks unencrypted didn't cause any
problems, but due to system/core commit 72abd7b246f7 ("Try to recover
corrupted ext4 /data with backup superblock") it is causing problems.
Bug: 162479411
Bug: 161871210
Change-Id: Ic090bf4e88193b289b04c5254ddf661ef40b037e
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
Now that Bionic's copy of <linux/fscrypt.h> has been updated, there's no
need for vold to carry its own fscrypt_uapi.h.
Test: build
Change-Id: I61581ac74f7cf77bc8a835e64d96553a9d0c517a
Use C++'s built-in mechanism for one-time initialization rather than
implement it ourselves in a way that isn't thread-safe.
(It doesn't *actually* need to be thread-safe, since all callers of this
run under ACQUIRE_CRYPT_LOCK. But that's not easy to verify.)
Test: booted Cuttlefish and checked log for the one-time message
"Detected support for FS_IOC_ADD_ENCRYPTION_KEY"
Change-Id: I6ca5b143ca305fa95144e388efc9657e3507bf05
This reverts commit aedae617fe.
Reason for revert: ArcObbVolume is not needed by ARCVM R and above.
Bug: 157885448
Test: trybot
Change-Id: I16395ac8b6902cedea263f51e306b297d719043f
The emmc_optimized encryption flag is specifically designed for the
limitations of inline encryption hardware that follows the eMMC
standard. It isn't appropriate to use on other types of storage.
So, make vold enforce that it's not used on other types of storage.
Bug: 160639344
Test:
- Enabled emmc_optimized on Cuttlefish and verified it no longer boots
- Using a modified version of this change, verified that
IsEmmcStorage() works as expected on various devices including
Cuttlefish, Cuttlefish booted in GSI image mode, a device with eMMC
storage, and a device with UFS storage.
- Verified that VtsKernelEncryptionTest still passes
Change-Id: Ie27b80658db53b1a4207b3cbb4e309d05130812e
Merged-In: Ie27b80658db53b1a4207b3cbb4e309d05130812e
The emmc_optimized encryption flag is specifically designed for the
limitations of inline encryption hardware that follows the eMMC
standard. It isn't appropriate to use on other types of storage.
So, make vold enforce that it's not used on other types of storage.
Bug: 160639344
Test:
- Enabled emmc_optimized on Cuttlefish and verified it no longer boots
- Using a modified version of this change, verified that
IsEmmcStorage() works as expected on various devices including
Cuttlefish, Cuttlefish booted in GSI image mode, a device with eMMC
storage, and a device with UFS storage.
- Verified that VtsKernelEncryptionTest still passes
Change-Id: Ie27b80658db53b1a4207b3cbb4e309d05130812e
By default FUSE filesystems have a max_ratio of 1%, meaning only 1% of
dirty pages on the system can belong to a FUSE filesystem before we
start writing back pages (and throttling, if writeback can't keep up).
This limit is useful for untrusted filesystems, but in our case, we
trust the FUSE filesystem. Since FUSE writes result in writes to the
lower filesystem, FUSE should take at most 50%. Let's start with
changing max_ratio to 40%, to avoid needless throttling.
Bug: 159254170
Bug: 159770752
Test: inspect /sys/class/bdi manually after boot
Change-Id: I467e3770fc4afba0a08fa480c0b86aa054c8b875
Sometimes, during early boot, a public volume may be created before
the user is unlocked and the mount may fail. This mount failure does
not revert the lower fs mounts (sdcardfs and vfat). Subsequent
mount attempts will then fail because we'd attempt to mount vfat on
already mounted /mnt/media_rw/<volname>
Bug: 158489548
Test: Resilient to an artificial sleep in
StorageManagerService#completeUnlockUser to
delay user unlock longer than public volume mount
Change-Id: I9a1574596434a2eb6b2553c0c9220c2118c7e4fd
