As the EXT4_MAX_BLOCK_SIZE defined as 65536 which reached maxium value
of unsigned int. The superblock value maybe larger than 65536. This is
found by the Integer Overflow Sanitizer.
This patch fixed below boot error when userdata is corrupted:
init: processing action (fs) from
(/vendor/etc/init/hw/init.freescale.rc:221)
init: [libfs_mgr]Invalid ext4 superblock on '/dev/block/by-name/userdata'
init: InitFatalReboot: signal 6 init: #00 pc 00000000000af7e8 /system/bin/init
(android::init::InitFatalReboot(int)+208) init: #01 pc 00000000000afbd0 /system/bin/init
(android::init::InstallRebootSignalHandlers()::$_22::__invoke(int)+32)
init: #02 pc 00000000000006bc [vdso:0000ffff9691b000] (__kernel_rt_sigreturn)
init: #03 pc 000000000004e070 /system/lib64/bootstrap/libc.so (abort+176)
init: #04 pc 000000000003427c /system/lib64/libfs_mgr.so
(read_ext4_superblock(std::__1::basic_string<char, std::__1::char_
traits<char>, std::__1::allocator<char> > const&,
android::fs_mgr::FstabEntry const&, ext4_super_block*, int*)+1804)
Test: boot with corrupted ext4 superblock
Change-Id: I58ed723afa9975d0e93f96fad7c55465e68b3edd
Signed-off-by: Haoran.Wang <elven.wang@nxp.com>
SnapshotUpdateTest uses a relatively small super partition, which
requires a small alignment and 0 alignment offset to work. For the
purpose of this test, hardcode the alignment and offset.
This test isn't about testing liblp or libdm.
Bug: 154355449
Bug: 157437632
Bug: 158718136
Bug: 157633441
Bug: 154646936
Test: atest on devices with alignment of data partition >= 512KiB
Change-Id: I1d0474f028cc824bd4197d0228350395239b3b81
If the superblock of /data is corrupted, fs_mgr would skip check_fs.
But, e2fsck actually may reference backup superblock to recover
the filesystem. This fix gives fs_mgr second chance to fix corrupted
ext4 /data.
Bug: 156200421
Test: boot with corrupted ext4 superblock
Signed-off-by: Randall Huang <huangrandall@google.com>
Change-Id: Ia39af3340c0e241f62557b7c2cc8b800443342f9
For partial update, the payload will not include all dynamic
partitions on the device, update the logic libsnapshot to better
handle such case.
Bug: 157778739
Test: run a partial OTA, unit tests pass
Change-Id: I4339a81ed31161bab3ba9666c1d05fb8bf57dbf9
Fix block-level checkpointing to work correctly when used in combination with
512 byte hardware sectors and metadata encryption with dm-default-key v2.
Bug: 153512828
Test: Parameter is passed to dm-bow based on first_api_level
Change-Id: Ic0a071221559271db20b06b2f17459b5b041e02d
Adding the function, fs_mgr_wait_for_file(), to ensure the
device file exists before to mount
Bug: 154278078
Change-Id: I74a68224073932773be18a79f9334d83ea5b6947
Enable libsnapshot to export the size of the COW image, representing the
fraction of the COW device that is temporarily created in the /data
partition, computed just before initializing a merge operation.
Thise additional information can be used by other components (i.e.,
update engine) to enrich Virtual A/B metrics.
Bug: 154016862
Test: manual OTA
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: I4faa0785f23884e26161e0d51268dd7a305d86bf
Merged-In: I4faa0785f23884e26161e0d51268dd7a305d86bf
When delivering single-stage, non-AB OTAs, the updater binary is built
on a newer OS than recovery is compiled with. libdm relies on newer ueventd
behavior which therefore breaks this model. As a workaround, we allow
libdm to fallback to the old ueventd logic if the following conditions
hold true: (1) we're in recovery, (2) the device is not an AB device,
and (3) the release is <= 10.
Since the old ueventd behavior can lead to races in libdm, this fallback
should stay as narrow as possible.
Bug: 156536673
Bug: 155202260
Test: manual test
Change-Id: I7f9da49e4ba8dfe165e0923d9918827d51d090cd
Currently the ReadDefaultFstab function, which calls GetFstabPath,
makes some assumptions about what the fstab will be called and where
it is located. This is being used by vold to set up userdata encryption
and for gsid, and is even used in the default boot control HAL, so it
has become quite baked.
The original way for a board to specify things to mount was to use the
"mount_all /path/to/fstab" command in init.rc. However, due to the
above functionality, the path after mount_all is no longer very useful,
as it cannot differ from the inferred path, or userdata encryption and
other features will be broken.
On Cuttlefish, we have an interest in being able to test alternative
userdata configurations (ext4 vs f2fs, encryption on/off, etc.) and
currently the only way to achieve this is to either a) modify the
ro.hardware or ro.hardware.platform properties, which breaks a bunch
of things like default HAL filenames, or regenerate our odm.img or
vendor.img filesystems. We can't simply install another fstab and
point to it with "mount_all".
This change allows the fstab path to be omitted from "mount_all", and
adds another property which overrides the existing checks for
fstab.${ro.hardware} and fstab.${ro.hardware.platform}. Specifying
${ro.boot.fstab_suffix} will cause fstab.${ro.boot.fstab_suffix}
to be checked first.
Bug: 142424832
Test: booted cuttlefish with 'mount_all ${ro.hardware} --late'
Test: booted cuttlefish with 'mount_all --late'
Test: booted cuttlefish with 'mount_all --late' and fstab_suffix=f2fs
Test: partially booted cuttlefish with 'mount_all ${ro.hardware}'
Test: partially booted cuttlefish with 'mount_all'
Change-Id: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
If the emmc_optimized filesystem flag is set, then like
inlinecrypt_optimized, we have to ensure that stable_inodes is set
on the filesystem.
Bug: 144046242
Test: Cuttlefish, ext4: set the flag in fstab, check for the
stable_inodes flag using tunefs -l
Change-Id: Id7f906564457c240ddf6677dd536698881385385
Because DSUs mount userdata via a fiemap, libfiemap has trouble creating
additional fiemaps on top of it. The complex stacking of dm-linear is
not supported. For other libfiemap tests we've hacked around this
limitation. If LpMetadata is in a folder named "test", we allow the
backing device search to stop at a dm node, whereas otherwise it would
need to stop at a physical device.
However this was not quite enough for vts_libsnapshot_test, because (1)
the test folder was not included in the pattern match, and (2)
CreateLogicalPartition() could not handle device-mapper names, as it
expects a named physical partition. Addressing both of these allows the
tests to pass on DSUs.
Bug: 156713441
Test: vts_libsnapshot_test on DSU
Change-Id: Ie7ee70e31dff0809a5f0c402ed132d80dd03d9b1
The GKI verification VTS test will need to examine the boot partition's
hash descriptor, so add support to access this descriptor.
Bug: 148800209
Test: atest AvbTest#Boot
Change-Id: I92e32f61a265671ae0940c44147391f73776e66a
Instead of unsetting gsid.mapped_images.* directly, properly unmap
them through image manager. This also avoids interference between
different fuzzer runs because the gsid.mapped_images.* properties
are not destroyed in SoftReset.
Test: libsnapshot_fuzzer_test then reboot, device can come up
Fixes: 156689792
Bug: 156380383
Change-Id: I7a198312f63b4b17d8ea96c7df2dd112a910d004
This reverts commit 254b9046f7.
Reason for revert: test fixed
Bug: 156689792
Test: run it then reboot
Change-Id: I33603e87b8f6b06fed2d18066ee5f00cdf45a52e
This reverts commit 51bfe08d84.
Reason for revert: Investigating possible connection to http://b/156689792
Change-Id: Idd779815940e3835bc0b86103ef016141d48ce7f
Add tests for the fuzzer itself. The test ensures that the
initial corpus is a good run on SnapshotManager (in the sense
that not only it doesn't crash, but also it executes as expected).
Also changed fuzz_utils so that impl functions return the
invocation result too, so that the test can check its values.
Test: run it
Bug: 154633114
Change-Id: I31ab7830f8c20a0575aaadabd038632d10f33962
Transform some of the tests in vts_libsnapshot_test
to corpus and use them as initial corpus to
libsnapshot_fuzzer.
The corpus alone gives us 50% of line coverage in snapshot.cpp.
Test: run it
Bug: 154633114
Change-Id: I8f3bf1d76ef64d710224e24c913990692481b65e
Ensure a clean env as much as possible. Otherwise,
previous crashes may affect subsequent runs.
Test: crash and run it again
Bug: 154633114
Change-Id: I0db690f420bef4a95d2e937f423c21ddf916e0d5
Add a test directive to mimic the behavior of switching
slots after rebooting. This changes the behavior of
SnapshotFuzzDeviceInfo and has nothing to do with the
API surface of ISnapshotManager. It also relies on the
fact that SnapshotManager does not record the current
slot suffix and always reads from IDeviceInfo.
Test: run with corpus
Bug: 154633114
Change-Id: I6ebb68afb8519feaa05bd3e4817f0e06596fc920
Mount a real data image and use it as the backing storage of
image manager. This is needed for ImageManager to DetermineMaximumFileSize.
Test: run with corpus
Bug: 154633114
Change-Id: I4802094d78459427f5d83102bcb716de590789e0
/metadata/ota/snapshots is created by init.rc at boot time.
Conditionally create it in the fuzz test
Test: run it
Bug: 154633114
Change-Id: Ice5e340b554ffd59861c4b21d9c4eb652ca60c55
Even though operation type ZERO is not used
in libsnapshot, add it so that the fuzzer has
an alternative operation type to use. Without
it, the fuzzer will only generate operations
SOURCE_COPY.
Test: pass
Bug: 154633114
Change-Id: I4fd36421b8b33ed68b94be2d739a6dd706b3829f
libsnapshot used to assume CoW images are always mapped
with device mapper, and call GetDeviceString directly.
However, in tests, it is possible that it is mapped as loop
devices. Fix the incorrect assumption and calls
IImageManager::GetMappedImageDevice instead.
Test: libsnapshot_fuzzer with corpus
Bug: 154633114
Change-Id: I1ec39744480e514ae7a7902643ed863e0ca0a340
libfiemap functionality is extensively tested via libsnapshot, gsid, and
fiemap_writer_test. However those tests rely on the configuration of the
device, and libfiemap has fairly different behavior based on whether FBE
or metadata encryption is in use. (The former will use loop devices, the
latter uses dm-linear).
To expand coverage, we added tests with very complicated nesting,
creating fiemaps on a rw partition mounted off a device backed by a
fiemap. Unsurprisingly, this was brittle to begin with, and now
consistently fails due to the intermediate partition not having
sepolicy.
Given the preference toward metadata encryption, and the fact that the
FBE mode will still be properly tested via VTS, let's just remove these
tests.
Bug: 148874852
Test: fiemap_image_test
Change-Id: I7be7d44dea81508505c050ed995b3b78086ad35f
When merging in recovery, the "imminent data wipe" code was used, which
made the assumption the /metadata and /data state would be zapped. This
caused future OTAs to error because the old snapshots were detected.
This CL allows OTAs to proceed even if unexpected snapshots are present.
It also forces the state to "MergeCompleted" after a merge in recovery,
so that the next normal boot can perform cleanup.
Bug: 155339165
Test: fastboot snapshot-update merge, then take another OTA
vts_libsnapshot_test
Change-Id: Ief6dea3ba76323044e61307272dda320a4494aea
* changes:
Enable automatic libsnapshot fuzzer runs
Also log corpus when aborted through libbase.
libsnapshot_fuzzer: Fuzz MapUpdateSnapshot.
libsnapshot_fuzzer: construct valid super partition metadata.
libsnapshot_fuzzer: Fuzz CreateUpdateSnapshots
libsnapshot_fuzzer: add additional tests for more APIs
libsnapshot_fuzzer: use protobuf
libsnapshot_fuzzer: map super image
This won't happen in practice because device size is never
zero. Hypothetically, if it is, PartitionCowCreator still
suggests that a CoW size of 8192 bytes needs to be created. In
reality, it is not necessary.
Test: libsnapshot_fuzzer
Bug: 155484992
Change-Id: I6c69f54820522d50c699384eec90c474ca3a9402
