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)
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
Bug: 22507568
Change-Id: Iaf28185adb8b80e5452447e54e1f4e4417a34168
(cherry picked from commit 2f42554f18)
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 the zramsize entry has a % size at the end, as in the following example:
/dev/block/zram0 none swap defaults zramsize=25%
then we will set the value as that percentage of total RAM, as read by scanning
/proc/meminfo.
b/20760266 Seed common build allocated too much for zRAM-backed swap
Change-Id: I17c91d311ba99ae7adae112bfe1b38542ea69b80
Signed-off-by: Iliyan Malchev <malchev@google.com>
Move fastboot's format logic into fs_mgr, to consolidate the knowledge
about how to do this (and when to wipe metadata).
Try to format these formattable paritions if they are wiped.
If formatting fails, we will fall out to let recovery mode handle it.
Bug: 20082763
Change-Id: I397cc197550e78d932e8a154fd234695c46dbe7b
- Cleanup the code to get filesystem size in a block device
- Add support to reading size of squashfs in a block device
Change-Id: I3848a705ed4dc2fc9afad20331f0fdecfee545c5
Signed-off-by: Mohamad Ayyash <mkayyash@google.com>
Fix build break caused by original change
This reverts commit 84b0bab58f.
(cherry picked from commit bbb4c85bdcc9a1bce315ed9d61a228bb1b992a1c)
Change-Id: If0ead0f2656b69f33f72c64b03a05784455a4143
Store verity state separately for each verified partition, and store
a hash of the last verity table signature for each partition. If the
signature changes, assume the partition has been reflashed and reset
verity state.
Bug: 20006638
Change-Id: I1c85fb816bfec1a54b1033c938bf1fdaf572f849
Set the verity mode as the value for partition.%s.verified to make it
easier for userspace to determine in which mode dm-verity was started.
Change-Id: Icc635515f8a8ede941277aed196867351d8387cb
Specify the location of verity metadata in fstab, and use a
type-length-value format for the metadata that allows other
data to be stored in the same location in an extensible way.
Change-Id: Id8711f7d51dc1e4e9a4d84f9951240f64528e69d
Add file encryption flag to fstab.
If file encryption flag set in fstab, handle identically to block
encrypted volumes.
Requires matching change:
https://googleplex-android-review.git.corp.google.com/#/c/642778/
Change-Id: I28c236959f2d7d5f0dccc8ea45c325ea0cf871fc
Add a command that updates dm-verity state and sets partition.%.verified
properties used by adb remount.
This is needed in init since fs_mgr cannot set properties:
I6a28cccb1ccce960841af20a4b20c32d424b5524
Change-Id: I0fdf5bc29c56690dcadff9d0eb216d3c68483538
Both init and libcutils define a property_set function. The init
version sets the property directly while libcutils simply calls
__system_property_set, which sends a message to init to set the
property.
Since libfs_mgr is statically linked to libcutils, any calls to
property_set end up sending a message to init and waiting for a
response. When libfs_mgr is further statically linked to init,
this leads to init sending a message to itself when property_set
is called in fs_mgr.
Because send_prop_msg in bionic only waits for a response for
250ms, this does not cause a deadlock. However, using libcutils
to set a property in the init process is hardly a good idea.
This change removes the property_set call from fs_mgr_verity.c.
If this property is required later, it should be set elsewhere.
Change-Id: I6a28cccb1ccce960841af20a4b20c32d424b5524
Sami Tolvanen