Right now there is a bug in second-stage-init that screws up the
overlayfs overrides. This happens because:
1. second-stage-init mount_all might be executed in the "bootstrap"
mount namespace.
2. In order to move (MS_MOVE) submounts in fs_mgr_overlayfs_mount_all(),
we change the mount propagation type of overridden filesystems to
MS_PRIVATE.
3. This means that the "default" mount namespace would not receive the
mount events of the overlayfs overrides.
4. After /data is mounted, init would switch to the "default" namespace.
This means any new processes spawned after this period would not be
able to see the overlayfs overrides.
We fix this by changing the mount order of second-stage-init mount_all
to mount the overlayfs override of a partition immediately after the
partition is mounted. This way we don't need to move any submounts as
there can't be any, thus we don't need to set any mountpoint to
MS_PRIVATE so the mount event of the overlayfs would be propagated to
the "default" mount namespace, too.
Bug: 309407859
Bug: 306124139
Test: adb-remount-test
Test: verify that overlayfs tookover successfully from second-stage-init
Change-Id: If2ff4852516292ccbc7abdeebe0e9a7c1c7ba606
"Do not reboot with commit failure when ext4 userdata is wiped" has
caused a regression in cuttlefish on f2fs. Overlay.img rapidly grows to
the full userdata size. This updates that CL to only affect partitions
marked for block based checkpointing.
Test: Boot Cuttlefish, monitor overlay.img for 5 minutes
Bug: 285019395
Change-Id: I7d8634e6535ee1531a0df9fb51c6f9c410cbfe92
Allow us to check if check_at_most_once is set for any partitions.
This property should be false for any device with a reasonable amount of
RAM and a modern CPU. Enabling check_at_most_once violates AVB best
practices, it should only be allowed on performance limited devices.
Bug: 253033920
Test: Ensure that avbHashtreeNotUsingSha1 CTS test still passes
and that partition.system.verified.check_at_most_once is set.
Change-Id: I8174adf81111cc0df547ea01f81b0dfaca32631f
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
* Categorize functions in fs_mgr_overlayfs.h into three classes:
- Type 1: common and non-critical utilities.
- Type 2: internal routines for facilitating remount.
- Type 3: external entry points for users of fs_mgr_overlayfs, like
fs_mgr_overlayfs_mount_all().
* Move type 1 to common utils header fs_mgr_priv.h & fs_mgr.cpp.
* Move type 2 to new private header fs_mgr_priv_overlayfs.h.
* Keep type 3 in fs_mgr_overlayfs.h.
* Move set-verity-state.cpp under fs_mgr so it can include
fs_mgr_priv_overlayfs.h. File is reformatted as a result. We should
eventually merge and dedup set-verity-state and fs_mgr_remount.
* Add myself to OWNERS for remount-related maintenance work.
Bug: 241179247
Bug: 241688845
Test: Full build -user and -userdebug build.
Test: Presubmit
Test: Treehugger run v2/android-gki/adb_remount
Change-Id: Id5fd0e2b12c693939d712a586dd553cc4d8bfeb1
This patch eliminates errno as part of the return contract for
fs_mgr_overlayfs_teardown().
The non-standard use of implicit errno makes it extremely difficult to
reason about how these functions can fail. As it turns out,
fs_mgr_overlayfs_teardown has been consistently failing for a long time,
but in a place where errno isn't set, which meant "enable-verity" never
saw the failure.
The failure was originating from umount2(MNT_DETACH) which guaranteed
that DeleteBackingImage would fail with EBUSY, and DeleteBackingImage is
a binder call that doesn't set errno.
This patch switches to umount() and returns a "busy" status if the
unmount fails with EBUSY. In this case it will also disable the scratch
partition. There is a long-standing existing bug where, for non-VAB
devices, it will delete the underlying scratch partition off super. This
is pretty risky with MNT_DETACH, but that path is left unchanged here.
Some duplicated code in set-verity-state was refactored as well, since
the return value of fs_mgr_overlayfs_teardown is now more complex.
Bug: 241179247
Test: adb-remount-test.sh
Change-Id: I2ca75332b75a302622ba9b86d122a6f2accdda3e
The use of errno in this function is very difficult to reason about, and
leads to a lot of complexity (eg saving and restoring errno on a case by
case basis).
This CL adds explicit logging in error paths and simplifies the return
state to "succeeded" or "failed".
In addition, the "change" outparam has been simplified as well.
Previously it indicated that *anything* in the filesystem changed. This
is not super useful since the only thing callers care about is whether
or not overlayfs went from "disabled" to "enabled". The outparam now
reflects that.
Bug: 241179247
Test: remount
Change-Id: I5a2b4dcc942e6807c9965cd484de152b47022c4e
Cuttlefish's combined fstab has two entries for every partition, which
causes a lot of error spam when remount fails. Fix this by only
remounting entries that match an actual mount point (if such a mount
point exists).
Bug: 241179247
Test: remount on broken kernel
Change-Id: I3ddab553706f98b45f83221fd195f481dfdcc5c0
FDE is no longer supported, so there's no longer any need to ever
reserve a crypto footer.
Bug: 191796797
Change-Id: I79121188b0bcb7b00c16fda03b68b20c40c1e240
It's requested by the partner engineering team to uniquely
identify a partition.
Bug: 197973981
Test: boot the device and check props
Change-Id: I0f7aa34dd0087f0698fe90b9df6c0eae06fc4f5d
Currently there is no socket for daemon instances launched during the
selinux phase of init. We don't create any sockets due to the complexity
of the required sepolicy.
This workaround will allow us to create the socket with very minimal
sepolicy changes. init will launch a one-off instance of snapuserd in
"proxy" mode, and then the following steps will occur:
1. The proxy daemon will be given two sockets, the "normal" socket that
snapuserd clients would connect to, and a "proxy" socket.
2. The proxy daemon will listen on the proxy socket.
3. The first-stage daemon will wake up and connect to the proxy daemon
as a client.
4. The proxy will send the normal socket via SCM_RIGHTS, then exit.
5. The first-stage daemon can now listen and accept on the normal
socket.
Ordering of these events is achieved through a snapuserd.proxy_ready
property.
Some special-casing was needed in init to make this work. The snapuserd
socket owned by snapuserd_proxy is placed into a "persist" mode so it
doesn't get deleted when snapuserd_proxy exits. There's also a special
case method to create a Service object around a previously existing pid.
Finally, first-stage init is technically on a different updateable
partition than snapuserd. Thus, we add a way to query snapuserd to see
if it supports socket handoff. If it does, we communicate this
information through an environment variable to second-stage init.
Bug: 193833730
Test: manual test
Change-Id: I1950b31028980f0138bc03578cd455eb60ea4a58
Ban weird paths such as /../system or //vendor in first stage mount.
Add utility function fs_mgr_create_canonical_mount_point() that:
* mkdir(mount_point) to ensure mount_point's existence
* Test that realpath(mount_point) =?= mount_point
Bug: 188898525
Test: Presubmit
Test: Boot CF
Change-Id: Iaf2ec52701277f26cc81f3e15a47b6083a788334
Rename fs_mgr_overlayfs_mount_fstab_entry() to
fs_mgr_mount_overlayfs_fstab_entry() and move it out of
fs_mgr_overlayfs.cpp to make it available for user builds.
Add checks to unsure overlayfs mount point doesn't contain symbolic
link or /../.
Check the mount point with an allowlist if user build. The mount point
should either be /vendor, /product ... or their submounts, or strict
submounts of /mnt/vendor and /mnt/product.
Bug: 188862155
Test: Boot test with overlayfs mount entries on user build
Change-Id: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
* Add logs.
* Append "override_creds=off" overlayfs mount flag only if
fs_mgr_overlayfs_valid() returns kOverrideCredsRequired.
Pre-4.6 kernels or kernels without the override_creds patch don't
need or don't recognize the override_creds mount flag.
(Background: I832c8ca3fce0269bdef4ce988541adb7ba9662ed)
* mkdir(mount_point) before mount() to ensure the mount point exists.
This could happen if the mount point is in a tmpfs, such as /mnt.
Bug: 186342252
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I1a05696346610d7fd61de6d25c379520fd58ca9b
This is used in cts tests to verify that algorithms in blocklist aren't
used to build the hashtree. The system properties are required to perform
the check on unrooted devices.
Bug: 175236047
Test: flash, getprop; atest CtsNativeVerifiedBootTestCases
Change-Id: I2dcfdb06f85dbe92cde45e836dd68e7bd835020f
Right now fs_mgr_overlayfs_teardown() does slightly different things
when called from the userspace or recovery. This is accomplished by many
runtime checks, runtime assumptions and conditional execution of code.
This makes the control flow of the function very hard to follow, and
assumptions becomes more fragile as the function becomes more complex.
This CL forks fs_mgr_overlayfs_teardown() and removes "recovery" bits
from it. A new entry point TeardownAllOverlayForMountPoint() is added
for recovery.
Recovery (fastbootd) should call TeardownAllOverlayForMountPoint() to
teardown overlays of all sources (cache dir, scratch device or DSU).
While fs_mgr_overlayfs_teardown() should only be called from the
userspace.
Also apply some linter suggestions.
Bug: 165925766
Test: adb-remount-test.sh
Change-Id: I7ff7e3409c910782e1ec207fcd02b967a9762bc1
During boot sequence there can be multiple calls to mount_all. For the
userspace reboot to correctly remount userdata, we need to store the
return code of the one that was responsible in mounting userdata.
Test: adb root
Test: adb shell setprop init.userspace_reboot.is_supported 1
Test: adb reboot userspace
Test: checked dmsg
Bug: 166353152
Change-Id: Id0ae15f3bcf65fa54e4e72b76f64716c053af7fb
Use realpath as a canonical representation of block devices. This makes
it easier to reason about block devices. This also fixes a bug, in which
fs_mgr_get_mounted_entry_for_userdata didn't properly work on devices
that don't support metadata encryption.
Test: atest CtsFsMgrTestCases
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 153363818
Change-Id: I139c2be46336a632bbaee86667019c075d7de814
Logic of unwinding dm-device stack to figure out what entry was used to
mount userdata turned out to be a little bit more involved, and it
shouldn't be part of libfstab
This CL just moves code around and cleans API a little bit, actual fix
will be in the follow-up CL.
Test: atest CtsFsMgrTest
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 148612148
Change-Id: If0f8a765dba63adb0e6a711eb81fffdcabea3480
Merged-In: If0f8a765dba63adb0e6a711eb81fffdcabea3480
(cherry picked from commit 8f50cfc28d)
Currently, this is only enabled for Virtual A/B devices. When /data uses
F2FS, then proper pinning support must be enabled.
Because /data cannot be mounted in recovery, we can't delete the scratch
image backed by /data while in fastbootd. Instead, we mark it as
disabled in /metadata. The remount command now has an init script that
checks for and removes a disabled scratch partition.
Bug: 134949511
Test: adb remount on V A/B device with patched F2FS
Change-Id: Ifc8720378259654472d3822e97059b6c366f601d
This reverts commit b20aa434a3.
Bug: 146403375
Reason for revert: broken build 6078429 on git_master on walleye-user
Change-Id: Idc3b1c0ad5228d63298ce84811624b23d0cea434
It has too many arguments.
Also fixed CreateLogicalPartitionParams::InitDefaults because
it doesn't use the provided partition opener to read metadata
(which breaks tests).
Test: libsnapshot_test
Test: liblp_test
Change-Id: I74cf8d468274f741c6f3743438fe8855b2aef15b
Currently, we replace snapshot-merge with a linear device wrapping the
base device. This is not efficient. This patch reads LpMetadata for the
underlying partition, and duplicates its table into the snapshot-merge
device. This removes a layer of stacking and also allows removing the
base device.
Note that snapshot_test is growing a bit unwiedly, because it's starting
to implement pieces of libsnapshot that will be filled in later for
update_engine. (MapUpdatePartitions is a good example of this.) When
those pieces land in libsnapshot, snapshot_test will be cleaned up to
remove much of this manual fiddling.
Bug: 139090440
Test: libsnapshot_test gtest
Change-Id: I3872dc51d9e5980803303806f42a5c7e74b0b78a
With this patch, init can mount snapshots in the first stage by
performing the following operations:
1. First, check if SnapshotManager::kBootIndicatorPath exists.
2. If so, call SnapshotManager::NewForFirstStageMount.
3. If NeedSnapshotsInFirstStageMount returns true,
4. Call CreateLogicalAndSnapshotPartitions().
When called, this replaces any calls to CreateLogicalPartitions().
Rather than split this into multiple functions (to generate uevents as
needed), we instead use major:minor strings for device-mapper tables.
This means we don't have to wait for paths to resolve.
Bug: 139204329
Test: libsnapshot_test gtest
Change-Id: Ia7ec196a62e51748d6f01a66fe4e9eef25f2898f
IPartitionOpener is useful for writing gtests, however, it can't easily
be used with CreateLogicalPartition. fs_mgr assumes the super partition
name will map to /dev/block/by-name/super whereas in tests we want to
redirect it to a different block device.
This CL makes two changes. First, it adds a new method to IPartitionOpener
to return a "device string" for a device name. The string must either be
an absolute path (for example /dev/block/by-name/super) or a major:minor
sequence, since device-mapper will accept either.
Second, CreateLogicalPartition now accepts an optional IPartitionOpener.
When converting block devices to paths, it uses the opener instead of
automatically prepending /dev/block/by-name.
Bug: 139204329
Test: liblp_test gtest
libsnapshot_test gtest
Change-Id: Id6b3120cc2ef5c0dd941b29ff96215ad3c8ec848
Introduce a parameter struct to eliminate parameter explosion, and refactor
existing callers to use the new helper.
Test: manual test
Bug: 135752105
Change-Id: I0c5ebe4e084ad7503c2ac6c65886a71505d50d00
This is no longer needed as CreateLogicalPartition() ensures the
obtained path will not race with device deletion.
Bug: 135771280
Test: device builds, flashes
Change-Id: I821290aa08fede99d5c51cd68681c351a1ea97bc
When both ext4 user data checkpoints and metadata encryption are
enabled, we are creating two stacked dm devices. This had not been
properly thought through or debugged.
Test: Enable metadata encryption on taimen (add
keydirectory=/metadata/vold/metadata_encryption to flags for userdata in
fstab.hardware)
Unfortunately metadata is not wiped by fastboot -w, so it is
necessary to rm metadata/vold -rf whenever you wipe data.
fastboot flashall -w works
fastboot reboot -w works
A normal boot works
Disable checkpoint commits with
setprop persist.vold.dont_commit_checkpoint 1
vdc checkpoint startCheckpoint 10
adb reboot
wait for device to fully boot then
adb reboot
Wait for device to fully boot then
adb logcat -d | grep Checkpoint shows the rollback in the logs
This tests encryption on top of checkpoints with commit, encryption
without checkpoints, and rollback, which seems to be the key cases.
Bug: 135905679
Change-Id: I24387a2943dce28b918c34894f24911b20429be7
If we just disabled verity, take the step to setup the backing
storage for overlayfs.
Test: adb-remount-test.sh
Bug: 130131892
Change-Id: Ic56569eaf363e4417a0ce5df11ee5480a07b8b03
umount_all is the cleanup step for mount_all.
In particular, the mount_all builtin creates a verity device,
'postinstall-verity', for the following line:
system /postinstall ... ... slotselect_other,logical,avb_keys=...
cppreopt umounts /postinstall but doesn't destroy the postinstall-verity
device, causing OTA to fail (because it cannot destroy the
system_[other] device). umount_all also destroy the verity device.
Note that mount_all does not map system_[other]; it is mapped by
first stage init. Hence, umount_all doesn't destroy it either. The OTA
client is reponsible for unmapping the device itself.
Bug: 129988285
Test: flash, boot, then check `dmctl list devices`, then OTA
Change-Id: Id3ab65b3860b6ea6cfec310ab13652009c81f415
Merged-In: Id3ab65b3860b6ea6cfec310ab13652009c81f415
Bug: 126230649
Bug: 127953521
Test: GSI boots when installed to sdcard on hikey960
GSI boots when installed to /data/gsi
Change-Id: Id59926ebe363939c8c5745bb1bf5bd13722dae7e
Refactor fs_mgr_candidate_list into fs_mgr_overlayfs_candidate_list
that reports all the possible candidates. The caller is responsible
for filtering out any that have verity enabled.
Sundry improvements to the adb-remount-test.sh script to improve
stability and feedback.
Test: adb-remount-test.sh
Bug: 122602260
Change-Id: I2399f83d8ed77d8f3d2ad1405d0c187ccbace764
fs_mgr_update_verity_state() has two callers with generally different
intentions. One caller loops through all entries in the default fstab
to set partition.<mount_point>.verified properties. The other caller
is only interested in whether or a specific mount point has verity
enabled.
Given this, we refactor fs_mgr_update_verity_state() to
fs_mgr_get_verity_mount_point() which takes a single FstabEntry and
returns the mount point used for the dm-verity device or an empty
option if verity is not enabled on that mount point.
Test: adb-remount-test.sh test on blueline
Change-Id: Ic7dd8390509e95b2931b21e544c919a544138864
Particularly, capitulate that GetEntryForMountPoint() would be cleaner
than std::find_if() and update the rest of system/core to use it.
Test: build
Change-Id: I982b5a8552d44852d3ab22c20db83afcd4dd652b
And deprecate one more old style function that is not used after this
change.
Test: boot, disable and enable verity
Change-Id: Id509f479850120352b4ea4dc3b6c40f6e8e2e53e
