The UFS support got rebased on top of the RPMB socket support
improperly. As a result, RPMB socket support was broken due to an
unconditional rmpb_fd = rc which would set the rpmb_fd to be connect()'s
error code in the case of an RPMB socket.
Bug: 146903427
Test: Boot Trusty+Android with the rpmb_dev mock, check for liveness
Change-Id: Ib1220dc49392f1a10369eed7716e44680bd83a66
The previous refactoring did not uncover the full breadth of issues that
arise when trying to use /data for adb remount. In fact, there are a few
distinct use cases for the scratch device, and one function cannot
sensibly provide them all.
(1) First-stage init needs to know if there are dependent devices. This
would be userdata, super_<other>, or system_<other>. This knowledge
is dependent on the state in /metadata, fstab, and the kernel
command-line.
(2) First-stage init and fastbootd need to know where the scratch
partition is. If it's not in super_<other> or system_<other>, and
there is no indicator on /metadata, then it might be in a dynamic
partition.
(3) "adb remount" needs to find a place to put scratch, which
effectively amounts to the first writable space it can find.
However, for Virtual A/B, devices, scratch wants to be stored in
/data, which requires more complex checks and binder calls.
Trying to encapsulate all of this into one function is too difficult, so
instead, this patch breaks GetScratchStrategy into separate functions:
one to return a physical location if a candidate exists, and another to
deduce the "boot" scratch device.
"adb remount" no longer calls GetScratchDevice, since it only needs to
know whether or not a physical candidate was possible.
fs_mgr_overlayfs_teardown calls GetBootScratchDevice, but now only
attempts to make a dynamic "scratch" partition if one definitely exists.
This makes the functionality clearer and reduces fastbootd uart spam.
Bug: 134949511
Test: adb_remount_test.sh on coral
adb_remount_test.sh on crosshatch
adb_remount_test.sh on walleye
Change-Id: I5f6a3677bc6adcaaf54c8ab3594643e4f285c04e
This adds a helper for first-stage init to easily map partitions backed
by /data. This can be used for the scratch partition as well as DSU
partitions.
Bug: 134949511
Test: fiemap_image_test
Change-Id: I46246b41ce19442d1476b9959e34df0e1bff58c3
Remove prebuilt ld.config.txt to use linker config from generator only,
including legacy and vndk_lite case.
Bug: 139638519
Test: m -j passed
Change-Id: I043d51daca8cde1977236f9fbda919176a18618d
We were doing "return -1" in an error case from a function that
returns bool. Since it's non-zero, this gets implicitly cast to
'true', which almost certainly isn't what we wanted here.
Test: TreeHugger
Change-Id: I76c188c22d907fc425cf4d5b0b1575f640a78ee3
This is needed for adb remount, to find the scratch device if it is
already mapped. Note that on devices without metadata encryption, this
cannot be done by querying device-mapper, since scratch will be a loop
device.
Bug: 134949511
Test: fiemap_image_test
Change-Id: Ia25d279c6f8a4838be32a8c01aefc67b5ec1e002
ImageManager can map images in recovery, but not delete them, because
/data is not mounted. libsnapshot handles this by storing extra state
files, but this is complex to manage and inconvenient for
fs_mgr_overlayfs.
Instead, this patch introduces two new calls:
- DisableImage(), which indicates the image should not be used. This is
implemented by adding a new DISABLED attribute to
LpPartitionMetadata. CreateLogicalPartitions ignores this flag, and
thus recovery/fastbootd can disable the scratch partition and
communicate that it can be deleted. This cannot be called from binder
since it is intended for recovery/first-stage init only.
- RemoveDisabledImages(), which walks the images for a given folder on
/metadata and deletes any that are disabled. This can be called from
binder.
Note that there is no metadata version bump for this flag. It's
considered to be included in the flag list for minor version 1, and
currently is not used for the actual super partition.
Bug: 134949511
Test: adb remount, fastboot flash system
Test: fiemap_image_test
Change-Id: Iaeca2d1eddb5637dd9a20202cafd11ae60b4d0e3
This eliminates libfiemap as a standalone library and instead bundles it
into libfs_mgr. All consumers of libfiemap need libfs_mgr, and having
them tightly coupled reduces linkage complexity.
When to use libfs_mgr: In recovery, first-stage-init, or when libfiemap
or overlayfs is not used.
When to use libfs_mgr_binder: When not in recovery/first-stage init, and
overlayfs or libfiemap is needed. In this case, IImageManager will proxy
over binder to gsid.
Bug: 134949511
Test: builds, fiemap_writer/image_test passes.
Change-Id: I4c1a5698afdbf9b3bf87accec98254c1fb6f4e0e
Some objects may log when they're destructed, so don't destroy the
global std::mutex in fake_log_device.cpp.
Test: AAPT works with a log in VectorImpl::finish_vector()
Change-Id: Ie5a0ac9fc4e6a137e9516059a831e499d55d5ddb
This CL enables storageproxyd to run on UFS device.
The proxy prepares and sends SECURITY PROTOCOL IN/OUT commands to UFS
device.
Bug: 143636526
Test: Trusty storage tests
Change-Id: Ibe16578c12b978c9a95deccfb1873081e8d0e994
Since I was there, added two more properties to reset, and switched
ordering of sys.init.updatable_crashing and
sys.init.updatable_crashing_process_name setprops to make sure that
process name is already set when apexd/PackageWatchdog get's notified
about sys.init.updatable_crashing.
Also fixed a typo in what HandleUserspaceReboot function.
Test: adb reboot userspace
Bug: 135984674
Change-Id: I954ec49aae0734cda1bd833ad68f386ecd808f73
Rather than use a std::vector for backing memory, allocate the memory
using a new with nothrow, and in MemoryBuffer use realloc. Since
the size field is coming from the elf, it could be corrupted or
intentionally crafted to cause problems.
In addition, add some other protections to make sure that overflows
don't occur.
Bug: 146215949
Test: Ran unit tests with jemalloc and scudo to verify that they
Test: both behave the same way.
Change-Id: If14243ce382ba5403a6bacd0ec673452c6b7c3be
There are two namespaces from init - bootstrap and default - and those
will have different set of APEX modules. To support difference between
two namespaces, linker config should be generated per namespace and each
namespace should use its own linker configuration. As a first step of
the work, this change will create different mount point for each
namespace, and re-generate linker config after APEX mount from each
namespaces.
Bug: 144664390
Test: m -j passed & tested from cuttlefish
Change-Id: Iac2e222376ec4b0ced6c29eed18b21d39ff0b1ba
Tom Cherry