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
Add support for dm-verity modes and storing persistent state in
a location specified by the following properties:
ro.verity.state.location
ro.verity.state.offset
If these properties do not exist, dm-verity is always loaded in
EIO mode. If the properties do exist, but the location does not
have valid state data, dm-verity is loaded in RESTART mode. The
mode is updated to LOGGING if a dm-verity triggered restart has
occurred.
Change-Id: Ibb82953594d234f81ad21c40f524190b88e4ac8f
Currently, when verity is set up on a block device, the underlying
device is still accessible directly. Change the existing function
fs_set_blk_ro visible to other fs_mgr modules, change the behavior
to match the comment above the function definition, and call it to
disable write access to the block device when setting up verity.
Bug: 18609347
Change-Id: I7884175df15f9161174788d74d20a08e4cd472ca
This reverts commit bda6272446.
The original fix seems to have led to boot failures in QA. Rather than
risk shipping, revert the change. Bug 18764230 reopened.
Requires change
https://googleplex-android-review.git.corp.google.com/#/c/629764/
Bug: 19278390
Bug: 19199624
Change-Id: I8b6ab585666f2b0f585ffb2a5f61ac2e3462e06e
Don't silently ignore umount errors. At a minimum, log them.
Add strerror(errno) to another umount call, to make sure we get
some actionable data.
check_fs: try 5 times umounting the filesystem. It appears that
the umount is failing, perhaps because some service is opening
the file on the device or other error. Try unmounting it multiple
times in case it's a transient problem and we can recover.
Bug: 19199624
Bug: 19156134
Change-Id: I7213eb52d55116fb2419a36494d26d5e159981a7
Delay mounting encryptable but unencrypted volumes until we can
check the ro.vold.forceencrypt flag, then optionally encrypt.
Requires matching vold change from
https://googleplex-android-review.git.corp.google.com/#/c/615309/
Bug: 18764230
Change-Id: If22008be8de6a4f3216b349f81ace49be1730314
This allows a vendor to force encryption on devices via a vendor
partition flag:
ro.vold.forceencryption 1
Bug: 18764230
Change-Id: Id0049ce64e34e4f6f96e593aadd70c277ac131c8
When mounting fstab entries it is practical to be able to specify
for example LABEL=data instead of a specific block device.
This is particularly important for the new Android Emulator code base,
which uses virtio block devices for the various partitions
(system,data,cache), because there is no defined ordering between the
way the filesystems are specified to the emulator and how they are
enumerated by the android kernel as /dev/vdX.
Change-Id: I7aef95f12e8f7b02ac2e33804ba7897fdcb9ad7f
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Delay mounting encryptable but unencrypted volumes until we can
check the ro.vold.forceencrypt flag, then optionally encrypt.
Requires matching vold change from
https://googleplex-android-review.git.corp.google.com/#/c/615309/
Bug: 18764230
Change-Id: If22008be8de6a4f3216b349f81ace49be1730314
When mounting fstab entries it is practical to be able to specify
for example LABEL=data instead of a specific block device.
This is particularly important for the new Android Emulator code base,
which uses virtio block devices for the various partitions
(system,data,cache), because there is no defined ordering between the
way the filesystems are specified to the emulator and how they are
enumerated by the android kernel as /dev/vdX.
Change-Id: I12c3db0ba6a515dc8e917e0349afd257888d3aef
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
This allows a vendor to force encryption on devices via a vendor
partition flag:
ro.vold.forceencryption 1
Bug: 18764230
Change-Id: Id0049ce64e34e4f6f96e593aadd70c277ac131c8
If the system partition is larger than 2G, the device fails to read
verity metadata, because fseek accepts only a 32-bit signed offset.
Switch from fseek to lseek64 to allow seeking using a 64-bit offset,
which solves the problem. At the same time, move away from stdio in
the function.
(cherry-pick of 4cafe2ff89b49329e0e880900195d8e061bd3750.)
Bug: 17705619
Change-Id: I226320498dcb750ec6cde84411c7fe0774c9cab7
This reverts commit 152d2d4234.
Fixed build error, and also fixed memory leak spotted from warning.
(cherry-pick of bbb36319119edde9377fb80015235893c30d2bc9.)
Bug: 17691572
Change-Id: I23b5ba537f7b557432041d4338b38b9be434e981
The return value of read_verity_metadata is propagated to caller
even if the verity metadata is invalid, provided that it can be
read from the device. This results in devices with invalid verity
metadata signatures to be mounted normally, which is not desirable.
This change fixes the bug by changing the return value in case of
verification failure to FS_MGR_SETUP_VERITY_FAIL.
Bug: 15984840
Bug: 18120110
Change-Id: Ic29f37a23cb417c2538d60fb05de9dd310d50f4a
(cherry picked from commit c95e9da396)
If the system partition is larger than 2G, the device fails to read
verity metadata, because fseek accepts only a 32-bit signed offset.
Switch from fseek to lseek64 to allow seeking using a 64-bit offset,
which solves the problem. At the same time, move away from stdio in
the function.
Bug: 17705619
Change-Id: I226320498dcb750ec6cde84411c7fe0774c9cab7
Sami Tolvanen