Set up dm-verity even if kernel configuration doesn't have
CONFIG_DM_VERITY_FEC set. Fall back to the always safe EIO
mode if dm-verity doesn't support feature arguments.
Bug: 21893453
Change-Id: I4812bd74801c0abc8da479230f48b752858f9cd8
If the device is corrupted, set up dm-verity in EIO mode instead of
logging mode. This prevents corrupted blocks from being returned to
user space. Note that restart mode is used by default and a warning
will be displayed to the user after corruption is first detected.
Bug: 19277516
Change-Id: I38966d73eb814836bc34b4bad1192583e5010b36
Set properties on verity_update_state even if verity state management
is not used.
Bug: 24865045
Change-Id: Ic68a9e1a230c959eeb2a769260ff7d8e100cb1e1
(cherry picked from 0eb0516665678aec7712d88b51c96aaf8b312060)
The if (read(...size) != size) pattern is unreliable, switch
to the android base ReadFully which wraps read in a loop.
Change-Id: I2324e4c45da3c9b53b18df6eb09ce69a6604b5d1
This is the minimal change just to keep it building, and doesn't
attempt to clean up any of the code.
Change-Id: I975710322ae33d8946497df25bf85b2fe28976a4
Currently, the device doesn't mount verified partitions if the
verity table signature is invalid, which usually means it fails to
boot. This change instead sets up dm-verity with an invalid root
hash and triggers device-specific error handling to recover from
the corruption.
Bug: 24256506
Change-Id: I6d693306fa0e7459c5500b028e433df61ecea6fb
(cherry picked from commit 47caa5c386)
Instead of falling back to suffix _a, we now error out if neither the
kernel commandline nor the misc partition specifies the suffix. It's
cleaner this way.
Change-Id: I3f58928a664433504ebdf8d0ee05a319be5097cf
This will make fs_mgr look in the misc partition for the A/B suffix to
use if one of more fstab entries is using the slotselect option and the
bootloader doesn't specify the suffix.
Change-Id: I24233195f60dd352bf8e7ac32b0d95dcd3323156
Allow partitions to be marked as A/B partitions
using the slotselect flag in fstab. The partitions
can be identified by appending the correct suffix
to the block device listed in the fstab. The suffix
is provided by the bootloader through a command line
parameter or the device tree, and can be found in
ro.boot.slot_suffix or read from the boot_control HAL.
Change-Id: I6846d80e857f95bfb8f282f4ab81167394613bbe
Signed-off-by: Daniel Rosenberg <drosen@google.com>
and run fsck with -f on clean shutdown instead.
With -f, fsck.f2fs always performs a full scan of the /data
partition regardless of whether the partition is clean or not.
The full scan takes more than 2 seconds on volantis-userdebug
and delays the OS boot.
With -a, the command does almost nothing when the partition
is clean and finishes within 20-30ms on volantis-userdebug.
When the partition has an error or its check point has
CP_FSCK_FLAG (aka "need_fsck"), the command does exactly the
same full scan as -f to fix it.
Bug: 21853106
Change-Id: I126263caf34c0f5bb8f5e6794454d4e72526ce38
We need to have partition.*.verified properties even when bootloader
is managing dm-verity mode, because we may have failed to set up the
verified partition and need a property to indicate this.
This means we still need to run fs_mgr_update_verity_state and walk
through all the partitions to verify the device mapper status, just
without updating verity mode.
Bug: 22489805
Change-Id: Iaf28185adb8b80e5452447e54e1f4e4417a34168
Using a getenv('OUT') in such a deep down function is a wrong design
choice. Replacing with explicit parameter that may be NULL in case
device specific files can be accessed from /.
Since TARGET_COPY_OUT_SYSTEM may be defined to something different than
system we also ensure that we use a path relative to TARGET_OUT to
compute path to fs_config_* files.
Bug: 21989305
Bug: 22048934
Change-Id: Id91bc183b29beac7379d1117ad83bd3346e6897b
Signed-off-by: Thierry Strudel <tstrudel@google.com>
If verity state is managed by bootloader, it will pass the verity
mode to the kernel in the androidboot.veritymode command line
parameter. Init copies the value to the ro.boot.veritymode property.
Check for ro.boot.veritymode in fs_mgr and use the value to set
dm-verity mode. If this property is not set, store verity state in
metadata as before, if a storage location is specified in fstab.
Bug: 21605676
Change-Id: Ife3c978c133248432c302583d3b70e179605fe42
(cherry picked from commit ac5c1224cf)
If verity state is managed by bootloader, it will pass the verity
mode to the kernel in the androidboot.veritymode command line
parameter. Init copies the value to the ro.boot.veritymode property.
Check for ro.boot.veritymode in fs_mgr and use the value to set
dm-verity mode. If this property is not set, store verity state in
metadata as before, if a storage location is specified in fstab.
Change-Id: Ife3c978c133248432c302583d3b70e179605fe42
This option only exists for ext4 filesystems, so it shouldn't be
used when mounting ext2/ext3.
This bug would cause the mount system call in check_fs to always fail
with ext2/ext3 filesystems.
Change-Id: I3c8938029357a4a4170355118b6757f61ff4b227
Using logical op on unitialized memory is a bad thing. Good thing
is that this bug is dead because the structure is completely
cleared later via create_verity_device() -> verity_ioctl_init().
Change-Id: Idf5515a888bc6216eda0e23885a789f9b0320bac
Sami Tolvanen