sgdisk --android-dump fails with error code 8 when there is no partition
table. Don't stop us from creating a new partition table.
Can be reproduced with
1. adb shell sm set-virtual-disk true
2. Format from UI
3. Observe fake "success" message with SD still unformatted
Fixes: ad5b4f9 ("vold: skip first disk change when converting MBR to GPT")
Test: CtsOsTestCases android.os.storage.cts.StorageManagerTest#testGetStorageVolumeSDCard
Change-Id: I3262bb2e28de438beba541a97038a06432643a65
ext4/f2fs partitions are usually created using the Linux partition
type on GUID partition tables, which is not recognized by vold.
Add the Linux partition type GUID to vold so ext4/f2fs partitions
on external SD cards with GPT are detected correctly.
Change-Id: I5e3947bb6b086eec4e5aa8a4825aaa93b7e9d99d
This commit is a forward port of following commits:
Author: Michael Stucki <mundaun@gmx.ch>
Change-Id: Ia34ad91444951e62f6d17374f480dcbdfa34cca3
Author: Tom Marshall <tdm@cyngn.com>
Change-Id: I05d9b57cc28ffd1f8deb8148d81c7f6fad0aa8db
Author: Pawit Pornkitprasan <p.pawit@gmail.com>
Change-Id: I1364f37018b25d79b1826c85849def64e868d72f
Author: Pawit Pornkitprasan <p.pawit@gmail.com>
Change-Id: I873af4dc2309d3d0942ce466b8acf8158abb85ae
Author: Jorge Ruesga <jorge@ruesga.com>
Change-Id: Ic0bb314b30e42489c45caec29d35d6896c9849eb
Signed-off-by: Michael Bestas <mikeioannina@cyanogenmod.org>
Change-Id: I9699643987c53d8e2538720f33da28de35230dfe
* Save mount options and fstype for DiskPartition objects
* Pass mount options and fstype to PublicVolume ctor
* Pass mount options to ext4::Mount/f2fs:Mount
* Use specified/default fstype if blkid fails
This is trivially extensible for other fs types.
[mikeioannina] Adapt for Pie and Q
Change-Id: Ie5dd27f26a4a7129dd9efe6a7ad0a589928282a0
* Support nonremovable disks and expose a nonremovable flag in the
DiskCreated message.
* New DiskPartition class to hold single partitions. DiskPartition is
used when the fs_mgr entry has a partnum (eg. when fs_mgr_flags
contains voldmanaged=label:#). Override disk partitioning methods
to prevent destroying the emmc.
Change-Id: Id7ec3ea409b5c96e691730604e4b1e9cc3aa9d33
vold: Correct base header paths
These headers were moved to android-base
Change-Id: I3eaa8316006b9017c5f5e31cd1e91efc2862106d
DiskPartition.cpp: Add sysmacros.h dependency for major/minor
Change-Id: I22c267c8f12b40fb3e2295becd88f12b75907b69
Signed-off-by: Adrian DC <radian.dc@gmail.com>
[mikeioannina] Adapt for Pie and Q
Change-Id: Id7ec3ea409b5c96e691730604e4b1e9cc3aa9d33
* Fsck was hitting a neverallow on public volumes not formatted in vfat
because it was always using the trusted context
* Always run trusted fsck for private volumes and untrusted for public
Change-Id: I0a6ee9aea907bae9ed097b920df0559df7b45d7d
* Add exfat and ntfs support based off f2fs and ported to use
fuse
* Add support for both along with f2fs and ext4 to PublicVolume
* Also attempt to mount any volume if it's been determined that
the kernel supports it
Change-Id: I0a83761cefd97791e3ec84a18e199dfd27a5ed0b
vold: fs: Fix build errors
* Migrate from base to android-base
* Add missing , in Ext4 Mount function
[AdrianDC] Ignore unpatched ext4 arguments
[mikeioannina] Update for Pie native exfat
Change-Id: I875b5763c472aa7da2976ec7c5db7cf28c913876
vold: ntfs: Use strlcat
Clang now enforces length checking :/
Change-Id: I495b4cb2ee530e72b1084248f0549d63589523b0
Change-Id: I0a83761cefd97791e3ec84a18e199dfd27a5ed0b
* While this is/will be correct in the long term
support for ExFat, currently the tools aren't mature enough
to forcelly try fixing all supported errors
* Go back to their "known" safe/working set
* Newer versions of exfatprogs added support for -a
argument
This reverts commit bc2566c837.
Change-Id: I9c8e2b581002c59231cc36c0dce79715fe16238b
ensure_subdirectory_unmounted() was ignoring the return value from
umount(), so it wasn't possible to tell whether it succeeded or failed.
Make it log an error message on failure.
Also, there might be cases where ensure_subdirectory_unmounted() fails
initially but would succeed later, e.g. due to files in a subdirectory
mount being open and requiring processes to be killed. To make this
more robust, keep calling ensure_subdirectory_unmounted() before each
attempt of umount("/data").
I'm not sure whether this will actually fix bug 189250652, as it hasn't
been root-caused yet, but this might help.
Bug: 189250652
Change-Id: I979b12d3c6a88fe3335ff548b1f8a5db43683c4f
(cherry picked from commit 895343006417e62b82ba6f758cf43643f529af2f)
Merged-In: I979b12d3c6a88fe3335ff548b1f8a5db43683c4f
In wait_and_unmount(), kill the processes with open files after umount()
has been failing for 2 seconds rather than 17 seconds. This avoids a
long boot delay on devices that use FDE.
Detailed explanation:
On FDE devices, vold needs to unmount the tmpfs /data in order to mount
the real, decrypted /data. On first boot, it also needs to unmount the
unencrypted /data in order to encrypt it in-place.
/data can't be unmounted if files are open inside it. In theory, init
is responsible for killing all processes with open files in /data, via
the property trigger "vold.decrypt=trigger_shutdown_framework".
However, years ago, commit 6e8440fd50 ("cryptfs: kill processes with
open files on tmpfs /data") added a fallback where vold kills the
processes itself. Since then, in practice people have increasingly been
relying on this fallback, as services keep being added that use /data
but don't get stopped by trigger_shutdown_framework.
This is slowing down boot, as vold sleeps for 17 seconds before it
actually kills the processes.
The problematic services include services that are now started
explicitly in the post-fs-data trigger rather than implicitly as part of
a class (e.g., tombstoned), as well as services that now need to be
started as part of one of the early-boot classes like core or early_hal
but can still open files in /data later (e.g. keystore2 and credstore).
Another complication is that on default-encrypted devices (devices with
no PIN/pattern/password), trigger_shutdown_framework isn't run at all,
but rather it's expected that the relevant services simply weren't
started yet. This means that we can't fix the problem just by fixing
trigger_shutdown_framework to kill all the needed processes.
Therefore, given that the vold fallback is being relied on in practice,
and FDE won't be supported much longer anyway (so simple fixes are very
much preferable here), let's just change wait_and_unmount() in vold to
use more appropriate timeouts. Instead of waiting for 17 seconds before
killing processes, just wait for 2 seconds. Keep the total timeout of
20 seconds, but spend most of it retrying killing the processes, and
only if the unmount is still failing.
This avoids the long boot delays in practice.
Bug: 187231646
Bug: 186165644
Test: Tested FDE on Cuttlefish, and checked logcat to verify that the
boot delay is gone.
Change-Id: Id06a9615a87988c8336396c49ee914b35f8d585b
(cherry picked from commit b4faeb8d444611a6e49b6e3d1364620bd02f22df)
Bug: 189250652
Merged-In: Id06a9615a87988c8336396c49ee914b35f8d585b
Otherwise only the pids are shown, and it's hard to tell which
processes actually got killed.
Bug: 187231646
Change-Id: Icccf60d0ad4439d702f36ace31abe092df1c69c2
(cherry picked from commit c78ae6008713ab2a1d64d0831ac9e139ed49ae10)
Bug: 189250652
Merged-In: Icccf60d0ad4439d702f36ace31abe092df1c69c2
* Commit 740377dda5 added back older create_crypto_blk_dev function
renamed as create_crypto_blk_dev_hw for QCOM HW FDE devices,
however it only switched to this function for ICE-enabled devices.
* Using create_crypto_blk_dev_hw in all cases fixes encryption on older
devices that do not support ICE.
* Matches android 10 code, which is working.
Change-Id: Id06dce34120c26fecd48f1328fee7a1b456fc421
Fixed compilation failures noticed when perf
flag (HW_DISK_ENCRYPT_PERF) is disabled.
CRs-Fixed: 2832825
Change-Id: Idbaf34a95ba30618c3a2dd91255f8dfceac81760
When converting a public (MBR) partition to private (GPT) partition,
'sgdisk --zap-all <path>' triggers a disk change netlink event
when converting from MBR to GPT. Then, 'sgdisk --new=....' triggers
another disk change netlink event.
vold informs clients a new volume is created after the first disk
change event occurs. system server reacts by requesting to mount
the volume. If this request is honored before the second disk change
event, the volume will be unmounted immediately after system server's
request to mount is honored. The next time system server performs
an operation (createnewuser) on this volume, it will fail due to
the volume being unmounted.
This is reproduced by running the following commands in a loop:
adb shell sm partition <disk> private
adb shell sm partition <disk> public
adb shell sm forget all
OR
run cts -c com.android.cts.appsecurity.AdoptableHostTest -m testPackageInstaller
This change causes vold to delay notifying clients that the volume is
ready until after it's actually partitioned.
CYNGNOS-2283
Change-Id: I457cc1508573d73ef2be2f0cfdc5c2237bfabad7
* Before moving to binder, 'changepw' was
supported, and people used it to set
different FDE decryption pwd from the
lockscreen one. This change adds it back.
Change-Id: Id83ebb8eafe15263d8a694da9a3353866f912e3f
dm-req-crypt driver is not yet tested/adapted to libdm
interfaces so enable req-crypt based HW disk encryption without
libdm. Drop the older APIs once dm-req-crypt driver is tested
for latest user interface based on libdm.
CRs-Fixed: 2530207
Change-Id: Id80a7d98f29bcb5e0dba1aa92f84c594cfad67ae
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Crypto block device is needed for device mapper based data
encryption for any partition. Close the device file pointer
when data packet is encrypted.
CRs-Fixed: 2417032
Change-Id: I0fa7c4829665b8a505a5abf598bb54b7835f71e0
Use get_crypto_info instead of fs_mgr_*
Test: builds and boots
Original Change-Id: I9c6803fb228f4f62e67b05f24b849048216e2a63
Change-Id: I7242e33f39b7f0558c44a0328d10569cf1a64253
Metadata encryption essentially encrypts userdata filesystem metadata
using Inline crypto engine based block disk encryption concept. New
Inline crypto engine based block disk encryption design do not create
crypto block device. When metadata encryption was enabled it needed
crypto block device to encrypt the metadata. So if metadata partition
is mounted on device block disk encryption did not work. Fix this by
checking whether crypto block device was created or not to switch
between two data encryption calls.
CRs-Fixed: 2389467
Change-Id: Ic46244ab08f31e71865636f1a2470f914ca88547
Fix random failures while running CtsAppSecurityHostTestCases with
adoptable storage due to a format failure. The crypto_blkdev node
might not be immediately available after create sometimes. Adding
a wait in create to make sure the node is available.
CRs-Fixed: 2324063
Change-Id: I8a7599a9253ac530b05a97ed34829dad1f7f7a40
Crypto block device is not required for ICE based
HW FDE solution. This introduces additional delay
and is redundant since data is encrypted inline.
CRs-Fixed: 2210986
Change-Id: I67c044c35e92d2aa9413bc3448b6193f6b6a01d7
Add HW FDE changes to new tip along with soong rules for
conditional compilation.
Following changes for HW FDE as well ported:
- Restart Android framework after HW FDE key has been created
- Add support of Inline Cryto Engine
- Use new HW FDE apis to update password
- vold: Tie HW FDE keys with Root of Trust(ROT)
- vold: Fix HW FDE OTA support on SW FDE encrypted device
- vold: Fix return value from get_keymaster_hw_fde_passwd()
- vold: Remove creation of new keymaster key for password update
- vold: Fix password update issue with HW FDE
- vold: hw_fde: fix OTA issues from L to M
- vold: Branch out SW and HW FDE paths to improve boot up time
- cryptfs: Use lower case alphabets for hex key during OTA upgrades
- vold: Improve device boot up time (Tune sleep calls)
- Retry mount if mount fails after setting HW FDE key
- cryptfs: Fix compilation error
- cryptfs: Fix mount failure when encryption triggered from settings
- cryptfs: fix issue that caused problems with forced HW encryption
- cryptfs: fix wrong password set by user during bootup.
CRs-Fixed: 2210986
Change-Id: I77279fc7e309ac94535123a2b2dbcb228bb47251
During OTA upgrades if security state or ROT changes then Keymaster
keys requires upgrade. So for such usescases, if the FBE ephemeral
key export fails, check whether KM key requires upgrade and try for
exporting ephemeral key again.
CRs-Fixed: 2632902
Change-Id: I3ee2fcd97a56b628dc4304867c8f2b8da875f883
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Legacy wrapped key support was dropped while merging changes
to support multiple versions of dm-default key driver in kernel.
Fix this by calling legacy API to check wrapped key support for
metadata encryption.
CRs-Fixed: 2678344
Change-Id: I7d9efec09ddf7169cf0b1114b4e16b9fe38cad4b
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Commit 77df7f207d / http://aosp/1217657 ("Refactor to use
EncryptionPolicy everywhere we used to use raw_ref") unintentionally
made fscrypt_initialize_systemwide_keys() start specifying keepOld=true
(via default parameter value) when retrieving the system DE key, and
likewise for read_or_create_volkey() and volume keys.
As a result, if the associated Keymaster key needs to be upgraded, the
upgraded key blob gets written to "keymaster_key_blob_upgraded", but it
doesn't replace the original "keymaster_key_blob", nor is the original
key deleted from Keymaster. This happens at every boot, eventually
resulting in the RPMB partition in Keymaster becoming full.
Only the metadata encryption key ever needs keepOld=true, since it's the
only key that isn't stored in /data, and the purpose of keepOld=true is
to allow a key that isn't stored in /data to be committed or rolled back
when a userdata checkpoint is committed or rolled back.
So, fix this bug by removing the default value of keepOld, and
specifying false everywhere except the metadata encryption key.
Note that when an affected device gets this fix, it will finally upgrade
its system DE key correctly. However, this fix doesn't free up space in
Keymaster that was consumed by this bug.
Test: On bramble:
- Flashed rvc-d1-dev build, with wiping userdata
- Flashed a newer build, without wiping userdata
- Log expectedly shows key upgrades:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /metadata/vold/metadata_encryption/key
D vold : Upgrading key: /data/unencrypted/key
D vold : Upgrading key: /data/misc/vold/user_keys/de/0
D vold : Upgrading key: /data/misc/vold/user_keys/ce/0/current
- Rebooted
- Log unexpectedly shows the system DE key being upgraded again:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" unexpectedly still exists:
$ adb shell find /data /metadata -name keymaster_key_blob_upgraded
/data/unencrypted/key/keymaster_key_blob_upgraded
- Applied this fix and flashed, without wiping userdata
- Log shows system DE key being upgraded (expected because due to the
bug, the upgraded key didn't replace the original one before)
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" expectedly no longer exists
$ adb shell find /data /metadata -name keymaster_key_blob_upgraded
- Rebooted
- Log expectedly doesn't show any more key upgrades
$ adb logcat | grep 'Upgrading key'
Bug: 171944521
Bug: 172019387
(cherry picked from commit c493903732d0c17b33091cf722cbcc3262292801)
Merged-In: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
Change-Id: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
We previously only set +F for /data/media, but adopted storage needs
this as well. Instead we add support for adding attrs to PrepareDir.
Bug: 163453310
Test: sm set-virtual-disk true
follow UI setup and confirm +F on /mnt/expand/*/media
Change-Id: I08f13b57a4de3538e88b38eb95b0ac115a5a5ce8
Merged-In: I08f13b57a4de3538e88b38eb95b0ac115a5a5ce8
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
Merged-In: Ic090bf4e88193b289b04c5254ddf661ef40b037e
Change-Id: Ic090bf4e88193b289b04c5254ddf661ef40b037e
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
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
yova
nift4
lambdadroid
Jani Lusikka
Sam Mortimer
Tom Marshall
Michael Bestas
Dan Pasanen
Luca Stefani
Eric Biggers
Kevin F. Haggerty
chrmhoffmann
Phanindra Babu Pabba
Michael Bestas
Scott Mertz
LuK1337
Bruno Martins
Neeraj Soni
Yifan Hong
Shivaprasad Hongal
AnilKumar Chimata
Pig
android-build-team Robot
Martijn Coenen
TreeHugger Robot
Daniel Rosenberg
Will Shiu