Execute mke2fs to create empty ext4 filesystem.
Execute e2fsdroid to initialize selinux context.
Test: zero-out first 4k of data partition and reboot,
fs_mgr successfully formats /data.
Bug: 35219933
Change-Id: If6f72f62c618c64be703b83f0114a4dd0a2b079f
(cherry picked from commit f71bc0c152)
On platforms that use ACPI instead of Device Tree (DT), such as
Ranchu x86/x86_64, /proc/device-tree/firmware/android/ does not
exist. As a result, Android O is unable to mount /system, etc.
at the first stage of init:
init: First stage mount skipped (missing/incompatible fstab in
device tree)
Those platforms may create another directory that mimics the layout
of the standard DT directory in procfs, and store early mount
configuration there. E.g., Ranchu x86/x86_64 creates one in sysfs
using information encoded in the ACPI tables:
https://android-review.googlesource.com/442472https://android-review.googlesource.com/443432https://android-review.googlesource.com/442393https://android-review.googlesource.com/442395
Therefore, instead of hardcoding the Android DT path, load it from
the kernel command line using a new Android-specific property key
("androidboot.android_dt_dir"). If no such property exists, fall
back to the standard procfs path (so no change is needed for DT-
aware platforms).
Note that init/ and fs_mgr/ each have their own copy of the Android
DT path, because they do not share any global state. A future CL
should remove the duplication by refactoring.
With this CL as well as the above ones, the said warning is gone,
but early mount fails. That is a separate bug, though, and will be
addressed by another CL.
Test: Boot patched sdk_phone_x86-userdebug system image with patched
Goldfish 3.18 x86 kernel in patched Android Emulator, verify
the "init: First stage mount skipped" warning no longer shows
in dmesg.
Change-Id: Ib6df577319503ec1ca778de2b5458cc72ce07415
Signed-off-by: Yu Ning <yu.ning@intel.com>
clang is the default compiler since Android nougat
Test: mma & verified it´s still build with clang
Change-Id: I34adaeef2f6558a09f26027271222bad94780507
Signed-off-by: Lennart Wieboldt <lennart.1997@gmx.de>
* changes:
fastboot: add mke2fs and e2fsdroid to build package
fastboot: call mke2fs tools to generate ext4 image
fs_mgr: call format_f2fs correctly with -f
init: require e2fsdroid and mke2fs when building init
init: rename mke2fs tools with _static suffix
Because full disk encryption make surper block is not except contents. Only
judge the magic number can prevent most of encrypted surper block.
In particular, magic number plaintext may be equal ciphertext. In order to
avoid this situation, we add the judgment of adaptive situation of the
s_rev_level, s_log_block_size and EXT4_INODE_SIZE.
Test: 1. Config fstab,userdata add flags: forceencrypt=footer,reservedsize=128M
2. build a new target files, and flash all image.
3. Config encrypt userdata surperblock,set magic number is 0xEF53
4. reboot system and check log of fs_mgr.
Change-Id: I925584d58f17afabbb3aa91f8be2302518172bb2
Signed-off-by: katao <katao@xiaomi.com>
This patch formats f2fs with -f option.
Change-Id: I3fc415f35d81f22cbf1eadebc619465d36205927
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
(cherry picked from commit 0331c2cf77)
On a A/B device, the image combination in VTS is:
- system.img (userdebug): provided by Google (system as root)
- vendor.img (user): provided by the OEM
The generic system.img provided by Google doesn't have /verity_key.
So verified boot will fail when it tries to verify the signature of
vendor.img. This CL allows signature verification error (including
no verity_key) when the device is unlocked.
This CL also changes the return value to FS_MGR_SETUP_VERITY_SKIPPED when
signature verification failed in logging mode. Otherwise, first stage
mount will fail because it assumes verity device initialization should be
successful when receiving FS_MGR_SETUP_VERITY_SUCCESS.
Bug: 63821912
Test: boot generic system.img on a A/B device
Change-Id: I33e5ef753913ae9f0c8b02c518ae94d4c8505611
Upstream kernels (v4.9+, v4.4.67+) have started to enforce that
encryption policies cannot be set on ext4 directories unless
EXT4_FEATURE_INCOMPAT_ENCRYPT is set in the filesystem superblock, as
was the original design. Since Android's userspace was not setting this
flag, it was not possible to use "file-based encryption" (FBE) on
devices whose kernels enforce this constraint. Fix this by updating
fs_mgr to set the flag if needed, similar to how it enables the quota
feature if needed.
Note that it would, eventually, be simpler to set this flag at mkfs
time. But that seems infeasible for now, given the many different ways
the userdata filesystem can be formatted --- including via 'fastboot',
which I believe is expected to still be compatible with old devices
whose kernel and/or e2fsprogs don't support the 'encrypt' flag.
Bug: 36231741
Change-Id: Ibafb9a7116fc853b62f8ee074a78499399f290a6
There were several duplications in the code that runs before a
filesystem is mounted. This made it difficult to start running tune2fs
to set the encryption feature flag. Refactor to deduplicate the logic,
and improve the log messages.
Bug: 36231741
Change-Id: I90846dad9c5ec85b3c5460615dec4cc19cb7e198
During mount operations, fs_mgr_wait_for_file() is invoked to
ensure the device file exists before starting to mount it. Adding
logs when the wait fails and also skip mounting as it won't be
successful. Also merge fs_mgr_test_access() and wait_for_file()
as fs_mgr_wait_for_file().
Test: Boot device and manually trigger the timeout issue
Test: Check and confirm whether timeout log info is inside ksmg.
Change-Id: Ide6d7fdca41e03e169e4400f91b7dea327985aaf
To boot with generic system.img for project Treble, we should allow no verity
metadata when the device is unlocked. The previous fix checks system property
"ro.boot.flash.locked" but it's unavailable during first stage mount.
This CL checks "androidboot.verifiedbootstate" in kernel command line instead.
Bug: 63268209
Test: boot sailfish without metadata on /vendor
Change-Id: Ifd1dbeb2a2f09cd06903ecdd59bc94b3905a3fbd
Need to know why the mount failed. clang_format adjustment.
Basically change LINFO to PINFO to cause the log message for the mount
report to be accompanied by a strerror(errno) message appended to the
end so that it is clear why the mount was rejected.
Test: manual
Bug: 63100799
Change-Id: Ic958299759befe5d5b11bdc95fea5d64cad86412
Test: I solemnly swear I tested this conflict resolution.
Merged-In: If8fc73e4ae4c2f8281c41a12f1c18079aab8baa2
Change-Id: Ie7feb839c9da2a11579ed850680c044c9fc3432a
libfstab is a subset of libfs_mgr, intended for vendors to use. It
exposes APIs for reading fstab. Note this 'visible to vendor' does not
mean that the API should be stable forever. The API can be changed in
later releases of Android, ,but the newer Android must not cause
run-time error when there is an older version of this static library
being used somewhere.
Bug: 62990533
Test: BOARD_VNDK_VERSION=current m -j libfstab.vendor
Change-Id: I371174fa1f6b4de6d6dd437b84ce4ed1e8740672
Merged-In: If8fc73e4ae4c2f8281c41a12f1c18079aab8baa2
The generic system.img released from project Treble can't contain any verity
metadata (e.g., vboot 1.0, AVB, or any other implementation) because it's
*generic*. To make any device can boot with it, `avbctl disable-verification`
is introduced to set a new flag AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED
in the top-level vbmeta to disable the entire AVB verification process. This
should be done prior to flash the generic system.img. See the following link
for details:
https://android-review.googlesource.com/#/c/418399/
This CL checks whether AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED is
set in the top-level vbmeta. When set, skip verifying the vbmeta structs
against androidboot.vbmeta.{hash_alg, size, digest} because it will be
absent in kernel cmdline. Also, only top-level vbmeta struct is read then
returned by libavb in this case.
Note that another flag AVB_VBMETA_IMAGE_FLAGS_HASHTREE_DISABLED, usually
set by `adb disable-verity`, is used to signal fs_mgr to skip setting up
dm-verity, but libavb still verifies all vbmeta structs. fs_mgr will
also verify all vbmeta structs against androidboot.vbmeta.{hash_alg,
size, digest} from kernel cmdline as well.
Also rename SetUpAvb() to SetUpAvbHashtree() to better fit its usage.
This function will return kDisabled when any of the above two flags is set.
Finally, regardless of which flag is set or not set, we still only allow two
return values from avb_slot_verify():
- AVB_SLOT_VERIFY_RESULT_OK: it's still possible to get this value
when any of these flags are set in build time. e.g.,
BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS=--flags 2
- AVB_SLOT_VERIFY_RESULT_ERROR_VERIFICATION: in most cases we should
get this value, because the flags are likely set at run time.
Bug: 62523303
Test: boot device with 'avbctl disable-verification'.
Test: boot device with 'avbctl enable-verification'.
Test: boot device with 'adb disable-verity'.
Test: boot device with 'adb enable-verity'.
Test: build image with BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS=--flags 2, then boot device.
repeat the above steps to boot device again.
Change-Id: Ie8436f3e0e82c78490208f3b85eac5238a9fdfdb
In case of non-secure builds (eng variant) fs_mgr_setup_verity() skips
verity checks regardless of fstab options. This is slightly different
than 'adb disable-verity' where it would first read the verity metadata
to check if verity is disabled.
So, this change adds a new return value of FS_MGR_SETUP_VERITY_SKIPPED
instead of piggy backing on the FS_MGR_SETUP_VERITY_DISABLED.
Bug: 62864413
Test: Boot sailfish
Change-Id: I42bf2bdce0ecb18b4c3b568e2bc96bf1590dfb35
Signed-off-by: Sandeep Patil <sspatil@google.com>
The value of PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION will be included
in the verity metadata of an image. For example:
PRODUCT_VENDOR_VERITY_PARTITION := /dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
This makes the image cannot be shared for devices with different by-name
prefix:
/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
/dev/block/platform/soc.0/7824900.sdhci/by-name/vendor
This change supports using a generic PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION to
build image and replace it with the actual path at run time:
PRODUCT_VENDOR_VERITY_PARTITION := /dev/block/bootdevice/by-name/vendor ==>
/dev/block/platform/soc.0/7824900.sdhci/by-name/vendor
Bug: 62171170
Test: Boot sailfish with PRODUCT_VENDOR_VERITY_PARTITION := /dev/block/bootdevice/by-name/vendor
Change-Id: I2789d2a025e80a628a1b4e7419818065c209fb7f
Current first stage mount only allows three mount points: system, vendor
and/or odm. This was introduced by project Treble to mount those
verified partitions early. However, there might be some other custom
partitions needs to be mounted early as well. This CL removes the
restriction and does first stage mount for whatever specified in
fstab-dt.
Bug: 62423887
Test: first stage mount /vendor with vboot 1.0
Test: first stage mount /vendor with vboot 2.0 (AVB)
Change-Id: I6c146c64e673c35c2823523ccbde193590430c48
Because the zram_size type is unsigned int.so if ZRAM size great
than 2^31 -1, zram_fp will receive a negtive integer, while the
ZRAM driver only accept natural number.We need to use printf
formatting %u instand of %d.
Test: 1. Config the zramdisk size 2348810240 and build a ramdisk
2. Reflash device and check below command:
$adb shell dumpsys meminfo
$ adb shell cat /sys/block/zram0/disksize
ZRAM info display will be abnormal
3. Config the zramdisk size 2348810240 and apply with this
patch.
4. Retest to step 2 and the ZRAM info will be ok.
Change-Id: I473de33fbd0b66cf13eac3172684e9fef11b6ef0
For an fstab entry in device tree, fs_mgr now honors the status property
as done by linux. i.e. the node (in this case, the fstab entry) is
enabled if status is not set, "ok" or "okay". For every other value, the
node is considered as disabled.
Merged-In: I5ff8f710de2c54afc76b4af28108ca9075357ad1
Bug: 62127741
Test: Test sailfish w/ no status property, result: boots
Test: Test with status = "disabled", result: skips mounting /vendor
Test: Test with status = "ok", result: boots
Change-Id: I5ff8f710de2c54afc76b4af28108ca9075357ad1
Signed-off-by: Sandeep Patil <sspatil@google.com>
(cherry picked from commit be4302bf58)
For an fstab entry in device tree, fs_mgr now honors the status property
as done by linux. i.e. the node (in this case, the fstab entry) is
enabled if status is not set, "ok" or "okay". For every other value, the
node is considered as disabled.
Bug: 62127741
Test: Test sailfish w/ no status property, result: boots
Test: Test with status = "disabled", result: skips mounting /vendor
Test: Test with status = "ok", result: boots
Change-Id: I5ff8f710de2c54afc76b4af28108ca9075357ad1
Signed-off-by: Sandeep Patil <sspatil@google.com>
fstab_rec.fs_options might be nullptr when printing error message.
Use android::base::StringPrintf() to '(null)' when needed.
Bug: 37759782
Test: Boot device and manaully trigger the output
Change-Id: I1bdf4ba57331aaea9dd5e790f6bf9d9b8bdc8b53
Merged-In: I1bdf4ba57331aaea9dd5e790f6bf9d9b8bdc8b53
(cherry picked from commit 59af33c9ed)
