When mounting fstab entries it is practical to be able to specify
for example LABEL=data instead of a specific block device.
This is particularly important for the new Android Emulator code base,
which uses virtio block devices for the various partitions
(system,data,cache), because there is no defined ordering between the
way the filesystems are specified to the emulator and how they are
enumerated by the android kernel as /dev/vdX.
Change-Id: I12c3db0ba6a515dc8e917e0349afd257888d3aef
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
This allows a vendor to force encryption on devices via a vendor
partition flag:
ro.vold.forceencryption 1
Bug: 18764230
Change-Id: Id0049ce64e34e4f6f96e593aadd70c277ac131c8
If the system partition is larger than 2G, the device fails to read
verity metadata, because fseek accepts only a 32-bit signed offset.
Switch from fseek to lseek64 to allow seeking using a 64-bit offset,
which solves the problem. At the same time, move away from stdio in
the function.
(cherry-pick of 4cafe2ff89b49329e0e880900195d8e061bd3750.)
Bug: 17705619
Change-Id: I226320498dcb750ec6cde84411c7fe0774c9cab7
This reverts commit 152d2d4234.
Fixed build error, and also fixed memory leak spotted from warning.
(cherry-pick of bbb36319119edde9377fb80015235893c30d2bc9.)
Bug: 17691572
Change-Id: I23b5ba537f7b557432041d4338b38b9be434e981
The return value of read_verity_metadata is propagated to caller
even if the verity metadata is invalid, provided that it can be
read from the device. This results in devices with invalid verity
metadata signatures to be mounted normally, which is not desirable.
This change fixes the bug by changing the return value in case of
verification failure to FS_MGR_SETUP_VERITY_FAIL.
Bug: 15984840
Bug: 18120110
Change-Id: Ic29f37a23cb417c2538d60fb05de9dd310d50f4a
(cherry picked from commit c95e9da396)
If the system partition is larger than 2G, the device fails to read
verity metadata, because fseek accepts only a 32-bit signed offset.
Switch from fseek to lseek64 to allow seeking using a 64-bit offset,
which solves the problem. At the same time, move away from stdio in
the function.
Bug: 17705619
Change-Id: I226320498dcb750ec6cde84411c7fe0774c9cab7
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
Clang compiler is picky about partial initialization and
here we only need to initialize the 'len' field.
BUG: 17410010
Change-Id: I718582cef96d5f4076b5ff1c7b8162327e7809b6
If the encryptable partition is wiped (4KB worth of 0 or 0xff),
then reboot into recovery to format /data+/cache
This is while waiting for the Mac OS support to format f2fs.
The flashstation running on Mac OS will currently just erase userdata
and not format it with f2fs.
Bug: 15720406
Bug: 15747366
Change-Id: Ib7cca3e1701483a09573457a835750f34da71ee0
Move the code that attempts to mount alternative fstab entries
into its own function.
Clarify return codes.
Suggest wipe via recovery in error messages.
Bug: 15747366
Change-Id: I3634477cd4d1d73f974f3e906c53285f0d9e0eac
Signed-off-by: JP Abgrall <jpa@google.com>
MF_FORCECRYPT claimed same flag value as existing MF_NOEMULATEDSD.
MF_FORCECRYPT also crashes if no "=" in the option.
Modify MF_NOEMULATEDSD flag value to unique, and reformat comment to keep
the definition near the other defines.
Change-Id: Iec86f40ff43eea14b791d3d19c0ae11fd4b5f784
Without this, the wrong mount point is flagged as being mounted.
Which leads to:
<6>[ 3.278040] fs_mgr: __mount(source=/dev/block/platform/msm_sdcc.1/by-name/userdata,target=/data,type=ext4)=-1
<7>[ 3.278834] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
<6>[ 3.278925] fs_mgr: fs_mgr_mount_all(): skipping fstab dup mountpoint=/persist rec[3].fs_type=ext4 already mounted.
Bug: 15925030
Bug: 15976144
Change-Id: I0bc617f11dfc97c32bb2d0e52b94ec19282568eb
During encryption and decryption, art is pumping out data via
dex2oat into the /data that is actually a tmpfs.
It currently needs ~195MB.
So we increase the tmpfs from 128MB to 256MB.
Bug: 15909689
Change-Id: I5d518a87d7b4eccf32fcd77f61980646ee8a3d35
Signed-off-by: JP Abgrall <jpa@google.com>
Moving the vendor symlink down was causing issues with some devices.
Moved it back up, and adjusted mount to remove symlinks if necessary.
Change-Id: I77126d77cfbef32250012bea3960c99b55db4cbb
Signed-off-by: Daniel Rosenberg <drosen@google.com>
When looking for partitions to encrypt, it would setup a tmpfs
onto the mount point. But with multi-type mount points it would
repeat the mount.
This would lead to having and extra tmpfs mounted on /data, as
only one would get removed.
Change-Id: I28f2c2c4955906f1172342ea07e0795d6880986b
Signed-off-by: JP Abgrall <jpa@google.com>
Modified fastboot to flash vendor.img as well. Moved symlink
for /vendor to occur after mounting partitions. Changed mount
to also create the mount point.
Change-Id: I78e1ba24e6bb8b4af96a67ee0569af579439e682
Signed-off-by: Daniel Rosenberg <drosen@google.com>
We do the recovery+wipe if
- the mount fails and
- the partition is forceencrypt
- the partition seems wiped (== the 1st 4KB are all 0x00 or 0xFF).
This is a hack until we get the flashstation up and running with f2fs.
Bug: 15731906
The alternative would be for the user to manually enter
recovery and wipe his device.
Bug: 15747366
Change-Id: Ic8f3ef59f3d7d01d5d93d8e4c01502080f422157
Signed-off-by: JP Abgrall <jpa@google.com>
Previous attempt was broken.
It would incorrectly be affected by mount failures.
This changes allows an fstab to contain multiple lines for a given
mount point.
The lines sharing a mount MUST be after each other.
The 1st matching line is the primary when it comes to mounting
and look ups for wiping.
Mounting based on a mount_point will attempt each dup in turn
until one succeeds.
The reported error will be that of the last failed attempt.
This is to allow quick experimentation between different FSes.
Bug: 15702546
Change-Id: I378d68ad13eb0098ec1ccb8dcf108b82acbe9ebb
Signed-off-by: JP Abgrall <jpa@google.com>
This is apparently breaking N5, so reverting for now.
This reverts commit a794f86522.
Bug: 15709256
Change-Id: I37a5160eead17e153e2c83fa94632ffa5d8553c2
This changes allows an fstab to contain multiple lines for a given
mount point.
The lines sharing a mount MUST be after each other.
The 1st matching line is the primary when it comes to mounting
and look ups for wiping.
Mounting based on a mount_point will attempt each dup in turn
until one succeeds.
This is to allow quick experimentations between different FSes.
It does not deal with checkfs yet, because the underlying invocation
of fs-type appropriate fsck does not handle the error code.
Only the primary FS (1st in the dups) is checked.
Change-Id: I8329737454b53e2681436fe85cd00a9bc522676b
Signed-off-by: JP Abgrall <jpa@google.com>
Elliott Hughes