Don't use the FDE flow to support metadata encryption; just use the
vold service which directly mounts the volume.
Bug: 63927601
Test: Boot Taimen to SUW with and without metadata encryption.
Change-Id: Idf9c27a69872cd7a9e2fb76df09a91d8e5ef4896
If we're setting up the number of reserved blocks, we also want to
set our new AID_DISK_RESERVED as the GID that's allowed to use those
blocks.
Test: builds, boots
Bug: 62024591
Change-Id: Iaabfa7d63ad9ff0b9732e2b9996937607d622fe2
Previously there is no vboot 1.0 metadata for ENG builds. It relies on
is_device_secure() to query "ro.secure" and skip setting up dm-verity
if the value is 0 (meaning ENG build).
This change will be submitted together with other changes to add vboot
1.0 metadata for ENG builds with a "disable magic". The resulting
metadata will be the same as triggering an "adb disable-verity" on an
USERDEBUG image.
Bug: 63056044
Test: boot sailfish eng/userdebug builds
Change-Id: I35eef771e1b30bfc6d01b8ed76b40c942fe7b783
This is needed if they will ever handle ro. properties that have
values longer than 92 characters.
Bug: 23102347
Bug: 34954705
Test: read and write properties with value length > 92 characters
Change-Id: I44aa135c97ec010f12162c30f743387810ae2c5d
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>
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
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>
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
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
Current first stage mount for AVB requires specifying a common prefix of
by-name symlink for all AVB partitions. It limits all AVB partitions to be on
the same block device.
firmware {
android {
compatible = "android,firmware";
vbmeta {
compatible = "android,vbmeta";
parts = "vbmeta,boot,system,vendor";
by_name_prefix="/dev/block/platform/soc.0/f9824900.sdhci/by-name" <-- *removing this*
};
fstab {
compatible = "android,fstab";
vendor {
compatible = "android,vendor";
dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor";
type = "ext4";
mnt_flags = "ro,barrier=1,inode_readahead_blks=8";
fsmgr_flags = "wait,avb";
};
};
};
};
For normal mount with AVB, it extracts the by-name prefix of /misc
partition and use it as the prefix for all other partitions:
- /dev/block/platform/soc.0/f9824900.sdhci/by-name/misc ->
- /dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor_a
Fix this by adding an internal map in FsManagerAvbOps to record the mapping
from partition name to its by-name symlink:
ByNameSymlinkMap["vendor_a"] = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor_a"
Two overloaded factory methods are then provided for FsManagerAvbUniquePtr:
- FsManagerAvbUniquePtr Open(ByNameSymlinkMap&& by_name_symlink_map):
for first stage mount, where the by-name symlink map will be
constructed externally, from the uevents processed by init, before
invoking this factory method.
- FsManagerAvbUniquePtr Open(const fstab& fstab): for normal mount,
where the by-name symlink map will be constructed from the input fstab
internally.
Bug: 37552224
Test: first stage mount /vendor with vboot 1.0
Test: first stage mount /vendor with vboot 2.0 (AVB)
Test: normal mount /vendor with vboot 2.0 (AVB)
Change-Id: Id17e8566da87ea22b8923fcd6e47db8d45bc7d6a
- It was using blk dev name from fstab and quota / super block check was always
failing for FDE
bug: 37913441
Test: reboot and confirm quota
Change-Id: I8a9e890ef2787f2959e6a0225c6b21d35602f19e
- Returns FS_MGR_MNTALL_FAIL for failure paths in fs_mgr_mount_all()
- Removes the 'goto out' in fs_mgr_do_mount() as there is nothing to do in
the 'out' label now. Also removes the "ret = FS_MGR_DOMNT_FAILED;" and
just return FS_MGR_DOMNT_FAILED directly for the default failure path.
- Changes some LERROR to PERROR
Test: Use fs_mgr_do_mount() to mount /system with AVB
Change-Id: I126a0124a5c9d61302f40ab9db16989500d9777e
In a A/B device, system partition is mounted by kernel as root.
In vboot 1.0, the dm device name of system partition is "system" with
the following configuration in kernel command line:
- dm="system none ro,0 1 android-verity /dev/sda34"
In AVB, the dm device name is switched to vroot as:
- dm="1 vroot none ro 1,0 5201456 verity 1 ..."
When sending ioctl DM_TABLE_STATUS to query status, we should use "vroot" as the
dm device name for AVB. But still pass "system" for the callback function to set
property [partition.system.verified] instead of [partition.vroot.verified].
Bug: 36900078
Test: Use AVB to mount system in a A/B device, checks the property exists
[partition.system.verified]
Test: Use vboot 1.0 to mount system in a A/B device, checks the property exists
[partition.system.verified]
Test: Checks 'adb remount' will output warning message:
- dm_verity is enabled on the system and vendor partitions.
- Use "adb disable-verity" to disable verity.
Change-Id: Iaee7eb2b00b03729bc07fa24f1b449488716d2ea
- Do not use -f if it was cleanly shutdown.
- For unclean shutdown or other operation failures like
mount, tune2fs failure, run full check.
- Still old image will run full check once in 5 reboots
while new image will not run full check unless something
fails.
- Add retry for final mount. If mount fails once, run full fsck
once and try again.
bug: 32246772
bug: 35366616
Test: many reboots
Change-Id: I86949732ffe1955636ac179d553c91e52910f73e
- moved __android_log_is_debuggable to a new public header
(log_properties.h)
- vendor version of sched_policy uses ALOG* instead SLOG*
Test: (sanity) liblog-unit-tests
Test: (sanity) libcutils_test (noting b/b/32972117, two tests continue
to fail)
Test: system/core as a whole makes with BOARD_VNDK_VERSION := current
now with no problems.
Test: boots/works on internal marlin
Bug: 33241851
(cherry picked from commit 1f83aa424f)
Merged-In: I5bc1f348dc0f0c8814bec5b5c3d2c52c825ab640
Change-Id: I5bc1f348dc0f0c8814bec5b5c3d2c52c825ab640
fs_mgr_update_verity_state() is invoked by 'verity_update_state' in
init.rc. It will then set property "partition.system.verified" and
"partition.vendor.verified" to verify_mode. We should support this for
AVB as well.
Also change the order of static libs in init to fix the build error
after this change:
system/extras/ext4_utils/ext4_crypt.cpp:69: error: undefined reference to 'property_get'
Bug: 35416769
Test: Mount /system and /vendor with vboot 2.0 (AVB), check the following properties exist.
- [partition.system.verified]: [2]
- [partition.vendor.verified]: [2]
Test: Mount /system and /vendor with vboot 1.0, check the following properties exist.
- [partition.system.verified]: [0]
- [partition.vendor.verified]: [0]
Change-Id: I4328d66a8cb93f26e7960e620a0b2292d5f15900
- mount, e2fsck, tune2fs will all fail if magic number does not match.
- mismatch always happen for FDE and is wasting boot-up time to try
all and fail always.
- skip mount steps if it has invalid magic number and do not record
fs_stat either.
- For ext4 fs with corrupt superblock, e2fsck refuses to do anything if
superblock magic is invalid. So simply running e2fsck does not help
anyway.
bug: 36231950
Test: reboot ane check fs_mgr log from dmesg
Change-Id: I9ad9e0cd30fd074b3bbf8f450bd401b133d5771a
Several changes in this CL:
- Moves class FsManagerAvbHandle to public API
- Adds a parameter 'wait_for_verity_dev' for FsManagerAvbHandle::SetUpAvb()
to allow not to wait for verity device gets created
- Adds FsManagerAvbHandle::AvbHashtreeDisabled() to query whether AVB is disabled
- Adds fs_mgr_is_avb() to query whether a fstab_rec has MF_AVB flag
Bug: 33254008
Test: test AVB on bullhead
Change-Id: I89c43ca574ae632db8a700fc2590a1f80212c993
Adds two classes FsManagerAvbhandle and FsManagerAvbVerifier to replace the
following functions or struct:
- fs_mgr_load_vbmeta_images() -> FsManagerAvbhandle::Open()
- fs_mgr_unload_vbmeta_images() -> deleted
- fs_mgr_setup_avb() -> FsManagerAvbhandle::SetUpAvb()
- androidboot_vbmeta -> FsManagerAvbVerifier
- load_vbmeta_prop() -> FsManagerAvbVerifier::Create()
- verify_vbmeta_images() -> FsManagerAvbVerifier::VerifyVbmetaImages()
And only invokes FsManagerAvbhandle::Open() when there is a fstab entry having
'avb' flag (need HASHTREE descriptor). fs_mgr_is_avb_used() can be
removed as it only checks system property "ro.boot.vbmeta.hash_alg" to
decide whether vbmeta needs to be loaded, which might not be accurate.
For example, there are only HASH descriptors in the verified chain but
no HASHTREE descriptors. In this case, the fs_mgr doesn't have to do
anything because it only takes care of HASHTREE descriptors.
Also adds a new class FsManagerAvbOps to provide the C++ binding
FsManagerAvbOps::AvbSlotVerify() for libavb->avb_slot_verify().
Bug: 33254008
Test: test AVB on bullhead
Change-Id: I8fe15ba01c277152630a2a5c1c5c7f25fbf34030
- Old tool will set it to 10 while mke2fs will set it to -1.
- For now, only tag it.
- TODO: possibly add different policy per image tool version.
bug: 32246772
Test: check dmesg after reboot
Change-Id: Ib763f8ba64957412d2b02a9d6e3fc2bfcf55851e
mount_with_alternatives should set errno to match the 1st mount failure.
Bug: N/A
Test: run `fs_mgr -a <fake_fstab>` and check dmesg log
Change-Id: If4148d327f75c659b843e95f85568ea49c5d0180
Signed-off-by: NIEJuhu <niejuhu@xiaomi.com>
- This is to collect data to understand if e2fsck -f option
can be dropped wholly based on information from fs.
- Ideally e2fsck should not fix fs if it was clean shutdown
or if it is not enabling quota.
- The log is added to /dev/fscklogs/log and other system components
can collect it later.
TODO: add mechanism to distinguish old vs new fs generation tool.
bug: 32246772
Test: reboot and check saved logs under different shutdown conditions (clean, non-clean)
Change-Id: Id00fad4c5f8ebbb9f9908164a1026e415df06721
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>
