During early mount property area is not initialized, and as a result an
'eng' build will always incorrectly be detected as a 'secure' build by
early mount code path resulting into verity error and consequent boot
loop.
The change here makes sure the is_device_secure() check works with /
without properties based on the 'eng' build based build flag so the
early mount code works fine both ways.
Bug: 35791581
Bug: 27805372
Test: Boot sailfish-{eng,userdebug} builds successfully w/ early
mount enabled
Change-Id: Icd101ccad56b669f49b60bbb3005d5be9f53b02b
Signed-off-by: Sandeep Patil <sspatil@google.com>
depending on when fs_mgr is trying to read the configuration passed into
the kernel commandline, it may be able to read it successfully.
Specially in the case when init has not initialized properties.
This change adds a new fs_mgr_get_boot_config() API to be used by all
fs_mgr code in order to get filesystem parameters specified in kernel
command line or device tree. This way the fs_mgr code doesn't have to
handle the "early" cases separately anywhere.
Test:
Tested angler boot with both /system and /vendor mounted in init
first stage.
Tested sailfish to make sure /vendor can be continued to be
mounted early without verity
Change-Id: I9a44cdfc32681f714c5d73ae55c3deda95c02545
'slot_suffix' for A/B devices *must* be provided in kernel command line
or in device tree. The removed code was unnecessarily looking it up in
the 'misc' partition.
b/33254008
Test: Boot sailfish
Change-Id: I329af2d9a98c34a941596779eb78d14337b864e5
Signed-off-by: Sandeep Patil <sspatil@google.com>
This reverts commit 22e8199175.
- revert for now. will collect more data to check safety.
bug: 32246772
Test: reboots
Change-Id: Ibbb39005c64b26e9990c271b0b949feafae17773
This is the minimal change just to keep it building, and doesn't
attempt to clean up the code.
Bug: 34336098
Test: check device can boot
Change-Id: I5ff897874f1f14a9a5d1f14fedf1b0749e86dbb3
external/avb/libavb provides the new Android Verified Boot (AVB) flow.
It has different verity metadata format than previous formats in
fs_mgr_verity.cpp fs_mgr should support using libavb to read the metadata
(a.k.a. HASHTREE descriptor in AVB) to enable dm-verity in kernel.
Two important files in this commit:
- fs_mgr_avb_ops.c: an implementation of struct AvbOps* for libavb to do
platform dependent I/O operations, e.g., read_from_partition.
- fs_mgr_avb.cpp: it reads the metadata (a.k.a. vbmeta images in AVB) from
all partitions, verifies its integrity against the values of
androidboot.vbmeta.{hash_alg, size, digest} passed from bootloader in
kernel command line. Then enable dm-verity for partitions having the
corresponding HASHTREE descriptor and with an 'avb' fstab flag.
Bug: 31264231
Test: Enable dm-verity on /system partition
Test: Enable dm-verity with FEC on /system partition
Change-Id: I4652806984fe5a30c61be0839135b5ca78323d38
This commits moves some common functions out of fs_mgr_verity.cpp to be
reused by other verified boot flows. It includes:
- Move common functions into fs_mgr.c
- Move dm_ioctl related functions to a new file: fs_mgr_dm_ioctl.cpp
Bug: 31264231
Test: check device can boot with dm-verity
Change-Id: Iaa0d8031efbaae12aa28f872f62d3fc3d3763b51
This now combines all the "libsparse" libraries into the same soong
target. A minor side-effect of this change is that the libsparse
static library depends on the libz shared library instead of the libz
static library. This minor change has no effect since targets using
the static libsparse library need to explicitly include either the
static libz or the shared one.
Bug: 34220783
Change-Id: I8f41586cf4c3336791cfa57ab4f5ae59a76d7ffa
- Drop forced (-f) e2fsck check when the product has
enabled new ext4 generation by setting TARGET_USES_MKE2FS.
- The new generation tool is supposed to give better stability,
thus justifying dropping -f.
- This should help reducing boot-up time as full check (-f) can
increase boot-up time significantly depending on amount of data.
bug: 32246772
Test: many reboots
Change-Id: I631525bf7504bbfb025e170c8d24ad9d3ef3532e
When fs_mgr_do_format() is executed, fs_mgr creates a new
blank data file system. However, that filesystem is not
labeled and causes some unlabeled denials on early boot.
Example Denial:
avc: denied { search } for pid=2535 comm="logd" name="/" dev="mmcblk0p9" ino=2 scontext=u:r:logd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir permissive=1
To correct this, pass sehandle to the internal ext4 routine.
This way the ext4 filesystem will be labeled at creation and
the root inode will have a label.
Change-Id: Ieeecaa8bbc258e6d743d281dd956bdaca98b365f
Signed-off-by: William Roberts <william.c.roberts@intel.com>
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
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
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>
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
Move fstab parsing into fs_mgr_fstab.c so that it compiles into a
separate compilation unit. uncrypt links against it but doesn't
need to pull in the rest of the dependencies on fs_mgr.c.
Change-Id: I6bffe1cd42720151533e958028259d1931aaa4bf
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
A recent change to how libcutils is built requires liblog
to be explicitly included in the link list if it's needed.
Change-Id: I8547f5e65c488c8f6e314ccd4eb96606742272be
Currently, the output of e2fsck is not saved, and we have no insight
into how many errors e2fsck is finding and fixing. Using the new
abbreviated logging feature in liblogwrap, up to the first 100 lines,
and last 4K bytes of the output of e2fsck is captured by fs_mgr, and
added to the kernel log.
Usually, the filesystem will be clean, and this will only add a few
lines to the kernel log on boot, but when things go wrong, it should
save enough to indicate what the problem is, without potentially
filling the kernel log with only e2fsck output if the filesystem is
really corrupted.
Change-Id: I9c264798e6fe721c8f818b5ce15d0975027ddbdd
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
Sandeep Patil