This reverts commit c89b4e4314.
Reason for revert: reland the feature with bug fixed
Bug: 293313353
Test: Enter recovery with data wipe command
Change-Id: I2e1cfb91966c1af0145aac43cf11629cef9380d2
recovery mode does not have key services, so formatting volumes in
recovery would result in an unencrypted image.
If init detects an unencrypted /data image, encrypt_inplace would be
called. We would like to avoid using `encrypt_inplace` in production.
So do not format /data in recovery for regular data wipes.
Test: th
Bug: 293313353
Change-Id: I401da2a876ed22b426872c80c231397c12ec0737
For 16K dev options, we might need to reformat /data partition as ext4
before enabling the feature. Add necessary support to recovery.
Test: Trigger reboot with --wipe_data --reformat_data=ext4, make sure
/data is reformatted with ext4 on next boot
Bug: 293313353
Change-Id: I3cb67a62635a2df578472cd48cf6d2f5e04b5f82
This is in conjunction with enabling the project id for internal directories. The check whether project ids should be used or not, is done in installd process. If they cannot be used, then the installd process falls back to previous approaches.
Bug: b/215154615
Test: atest installd/StorageHostTest
Test: atest installd/installd_service_test.cpp
Change-Id: I9a45a14cf10c040f7ce84f78c5e9c8ce60c17958
Eric pointed that metadata_key_dir is what specifies that metadata encryption
is enabled, whereas metadata_encryption is the metadata encryption options,
which don't have to be specified if the default options are sufficient.
Bug: 208161227
Fixes: 80a1d8e341 ("Avoid to format raw disk if metadata encryption is enabled")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I390450ba49c528b1f465c247d32174d36c7937a2
The current flow is
1. factory reset formatted raw disk.
2. next boot tries to convert it to metadata encryption
2.a mount sda27
2.b umount sda27
2.c encrypt_inplace()
2.d fsck on dm-x
2.e mount dm-x
The #2 flow is unnecessary, if we know the disk will be encrypted. And, that
gives a change of the failure when unmounting the raw disk by starting some
file operations on /data. That can cause the entire encryption failure.
Bug: 208161227
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: Iaedfeb74bb6abb667efee6dcadf8d66272466ee0
Support for FDE is being removed from Android, having been replaced by
FBE. This CL removes the FDE-specific code from recovery_utils:
- Remove the code that wiped FstabEntry::key_loc if it is a block
device, since key_loc was only used by FDE.
- Remove support for reserving a crypto footer when formatting volumes,
since crypto footers were only used by FDE.
Bug: 191796797
Change-Id: I90b1e4cacd2f3e5cce77a82a0af744fcc7da9400
Requires to add "metadata_csum" in fsmgr_flag of fstab.
Bug: 149039306
Change-Id: I2b95dcaaf2ba224135ad51f117b7b01bbf342b7e
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
This sets up devices to have casefolding and project quotas if they have
enabled the relevant product properties. For ext4, we must set wide
inodes at makefs time, but other things are enabled by fs_mgr with
tune2fs at boot time.
Bug: 138321217
Bug: 138322712
Test: Enable on a device.
Reformat from recovery. Check that /data has the expected values
using tune2fs/f2fs.fsck
Change-Id: If706a3cad591f311eb904df4deca531d0b3fe0c4
C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: I6f8d658448f7e5dd980bf95b890b15cb0aab7407
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
A number of utility functions are intended for serving recovery's own
use. Exposing them via libotautil (which is a static lib) would pass the
dependencies onto libotautil's users (e.g. recovery image, updater, host
simulator, device-specific recovery UI/updater extensions etc). This CL
finds a new home for the utils that are private to recovery.
Test: mmma bootable/recovery
Change-Id: I575e97ad099b85fe1c1c8c7c9458a5a43d4e11e1
