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 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
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
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
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
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 reverts commit 152d2d4234.
Fixed build error, and also fixed memory leak spotted from warning.
(cherry-pick of bbb36319119edde9377fb80015235893c30d2bc9.)
Bug: 17691572
Change-Id: I23b5ba537f7b557432041d4338b38b9be434e981
This reverts commit 152d2d4234.
Fixed build error, and also fixed memory leak spotted from warning.
Bug: 17691572
Change-Id: I23b5ba537f7b557432041d4338b38b9be434e981
Build is broken.
system/core/fs_mgr/fs_mgr_verity.c: In function 'fs_mgr_setup_verity':
system/core/fs_mgr/fs_mgr_verity.c:103:20: error: 'verity_table_signature' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!RSA_verify(key,
^
system/core/fs_mgr/fs_mgr_verity.c:374:11: note: 'verity_table_signature' was declared here
char *verity_table_signature;
^
cc1: all warnings being treated as errors
make: *** [out/target/product/minnow/obj/STATIC_LIBRARIES/libfs_mgr_intermediates/fs_mgr_verity.o] Error 1
make: *** Waiting for unfinished jobs....
This reverts commit d4cea0bc16.
Change-Id: I6862cc79ef9d944a2472b6fb2e46dae514cea8ce
If the encryptable partition is wiped (4KB worth of 0 or 0xff),
then reboot into recovery to format /data+/cache
This is while waiting for the Mac OS support to format f2fs.
The flashstation running on Mac OS will currently just erase userdata
and not format it with f2fs.
Bug: 15720406
Bug: 15747366
Change-Id: Ib7cca3e1701483a09573457a835750f34da71ee0
Move the code that attempts to mount alternative fstab entries
into its own function.
Clarify return codes.
Suggest wipe via recovery in error messages.
Bug: 15747366
Change-Id: I3634477cd4d1d73f974f3e906c53285f0d9e0eac
Signed-off-by: JP Abgrall <jpa@google.com>
Previous attempt was broken.
It would incorrectly be affected by mount failures.
This changes allows an fstab to contain multiple lines for a given
mount point.
The lines sharing a mount MUST be after each other.
The 1st matching line is the primary when it comes to mounting
and look ups for wiping.
Mounting based on a mount_point will attempt each dup in turn
until one succeeds.
The reported error will be that of the last failed attempt.
This is to allow quick experimentation between different FSes.
Bug: 15702546
Change-Id: I378d68ad13eb0098ec1ccb8dcf108b82acbe9ebb
Signed-off-by: JP Abgrall <jpa@google.com>
This is apparently breaking N5, so reverting for now.
This reverts commit a794f86522.
Bug: 15709256
Change-Id: I37a5160eead17e153e2c83fa94632ffa5d8553c2
This changes allows an fstab to contain multiple lines for a given
mount point.
The lines sharing a mount MUST be after each other.
The 1st matching line is the primary when it comes to mounting
and look ups for wiping.
Mounting based on a mount_point will attempt each dup in turn
until one succeeds.
This is to allow quick experimentations between different FSes.
It does not deal with checkfs yet, because the underlying invocation
of fs-type appropriate fsck does not handle the error code.
Only the primary FS (1st in the dups) is checked.
Change-Id: I8329737454b53e2681436fe85cd00a9bc522676b
Signed-off-by: JP Abgrall <jpa@google.com>
This change adds a "verify" fs_mgr flag specifying that
the device in question should be verified.
Devices marked with this flag are expected to have a
footer immediately after their data containing all
the information needed to set up a verity instance.
Change-Id: I10101f2c3240228ee0932e3767fe35e673d2e720
Instead of specifying in init what to mount, and having various hacks in init
itself to deal with encryption, use a filesystem manager library to do the
work, that can also be invoked by vold when mounting an encrypted volume.
Keep all the magic filesystem info an a device specific fstab file.
Change-Id: Ib988f1e4fb0638ba1d5fd98407fa6d8cf862aaca
Sami Tolvanen