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
