Glibc >=2.32 exposes a gettid() which clashes with libcutils
thread.h, so add a check to not expose it if building against
newer glibc (ChromiumOS will still use glibc 2.27 besides 2.32).
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1182060
Test: Builds without errors on both glibc 2.32 and 2.27.
Change-Id: Ib71fa1bc9fa185e3668002407dbed05a80c87740
This instance will be used to monitor the error_report_end tracing
events sent by kernel tools in the case of a memory corruption.
Bug: 172316664
Bug: 181778620
Test: manual runs with KFENCE enabled
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: Ibc5cd3b60fb99030cc55db6b490d6d4bbbca3963
update_engine and libsnapshot must agree on CowOptions parameters,
otherwise the COW size estimation may be incorrect.
Bug: N/A
Test: vts_libsnapshot_test
apply OTA, snapshotctl dump
Change-Id: I219ae458dfa19e4b3c96360d3b847edb2a01ebc8
Revert "Selinux policy for bootreceiver tracing instance"
Revert submission 1572240-kernel_bootreceiver
Reason for revert: DroidMonitor: Potential culprit for Bug 181778620 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted Changes:
Ic1c49a695:init.rc: set up a tracing instance for BootReceive...
I828666ec3:Selinux policy for bootreceiver tracing instance
Change-Id: I5c2ccfe3eeb8863086b7cb9b3de43c6e076d995a
ConfirmationUI messages are a higher-level abstraction than TIPC
messages (which is what TIPC fuzzer fuzzes).
Bug: 174402999
Test: trusty_confirmationui_msg_fuzzer
Change-Id: I1e1e2c7070b87b78d6236993330df65202840ce6
This instance will be used to monitor the error_report_end tracing
events sent by kernel tools in the case of a memory corruption.
Bug: 172316664
Test: manual runs with KFENCE enabled
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: Ic1c49a695ff7df4147a7351051db7b6707c86e0a
I828ce999be6d786bf46dd5655dfda81d046906ab made a slight behaviral change
that fstab is searched and read before /first_stage_ramdisk is mounted
as root. Without this change, the attempt to read fstab from / fails at
the moment, leaving an empty fstab object. But as a side effect of the
attempt, DoCreateDevices() is not called again even after
/first_stage_ramdisk is mounted as root and the fstab is found under /.
This change fixes the problem by adding /first_stage_ramdisk to the list
of places to find the fstab file.
Bug: N/A
Test: Watch TH
Change-Id: I9826610cce436ba706aaea14c9a991822d2bae96
Some devices, such as the Essential PH-1, don't have an
updated bootloader and the bootloader is appending an extra
underscore.
This patch works around that issue by sanitizing the slot to be
inline with modern expectations.
Offending commit: 42b18a518b
Most of the commit above is not needed because an underscore + slot
is automatically appended when flashing to a partition. Normally, this
would result in something like boot__b instead of boot_b, where b is the
current slot.
Test: flash an image on mata without specifying slot, boots
Change-Id: Ia0b7cee603a4f9ba2e3a61ce6e369ca8c07a7caf
This addresses bugs where unexpected edge cases in the snapshot state
could prevent a merge or data wipe from completing in recovery.
Invalid snapshots (eg on the wrong slot) are now ignored in
CheckMergeState(). This prevents those snapshots from being detected as
"cancelled" and thus falling into RemoveAllUpdateState.
ProcessUpdateState will no longer call RemoveAllUpdateState in recovery.
Furthermore, when RemoveAllUpdateState fails, we will no longer return
the "old" state. If this state is Merging, ProcessUpdateState can
infinite loop.
Finally, HandleImminentDataWipe now guarantees the final state will be
either MergeFailed or None. For testing purposes, the old mechanism was
too susceptible to state machinery changes. And for practical purposes,
either we're going to wipe data (which removes the OTA), or a merge
failed and we can't. So the effective outcome is always no update or a
failed update.
Bug: 179006671
Test: vts_libsnapshot_test
Change-Id: Idcb30151e4d35cbeccf14369f09707ae94a57c66
QuerySnapshotStatus assumes IsSnapshotDevice() would return true.
Additionally, recovery does not have access to /dev/loop-control, which
cannot be used by libfiemap anyway. Access it on-demand instead of
preemptively.
Bug: N/A
Test: manual test
Change-Id: I0f746870d7a8ec6d666f0bdd2fef3464b214928b
