This CL also adds namespace android::fs_mgr and remove FsManager* prefix
for class names. Note that android::fs_mgr::FsManagerAvbOps will be removed
in later CLs when fs_mgr doesn't rely on libavb->avb_slot_verify() to
parse vbmeta structs.
Some lingering sources for by_name_symlink_map_ are also removed.
Bug: 112103720
Test: boot crosshatch_mainline-userdebug
Change-Id: I2d1a5cc39bcd5a699da8d5539f191d8c7737c4af
The --fastdeploy switch caused errors when CRC collisions were present in the input apk and/or
an apk with a similar package name to the input apk was already installed on the device.
Test: mm -j 64
Test: adb install -r --fastdeploy --force-agent --local-agent /mnt/raid/boat-attack-apk/boat-attack-swappy.apk
Bug: 119934862
Change-Id: Ibfe0cec38bdbb7371803fc2f73b0ec1697cef624
On retrofit devices, if both slots contain dynamic partition builds,
then "flashall" will attempt to write secondary images to dynamic
partitions in the other slot. At worst, this can fail with an error. At
best, it will result in the "other" partition not being mounted on first
boot.
This patch therefore deletes logical partitions for secondary images, on
retrofit devices only. On a Pixel device on the "b" slot, this means
"system_a" and "vendor_a" will be deleted before flashing, and therefore
system_other and vendor_other will be flashed to physical partitions
instead.
Bug: 120034852
Test: fastboot set_active a
fastboot flashall
fastboot set_active b
fastboot flashall
Change-Id: I6affe9a6c639b0495bffc77fcf20f329b86ad159
Check if overlayfs is supplied in the kernel before proceeding to
determining if there is a disabled verity and an overlayfs filesystem
to deploy.
Test: adb-remount-test.sh
Bug: 119929969
Change-Id: I28116f0aa6959040bb9f38f46c058a221591f735
NIAP certification requires that all cryptographic functions
undergo a self-test during startup to demonstrate correct
operation. This change adds such a check.
If the check fails, it will prevent the device from booting
by rebooting into the bootloader.
Bug: 119826244
Test: Built for walleye. After device booted examined dmesg and
observed logs from init showing that the new task did
start. Further, when BoringSSL is built to fail its self
check the device did stop during a normal boot and enter
the bootloader, and did so before the boot animation stopped.
Change-Id: I07a5dc73a314502c87de566bb26f4d73499d2675
This reverts commit 055347e564.
Reason for revert:
init boots with XOM now. I think this was fixed when this boringssl patch got merged in earlier this week (init has a static dependency on libcrypto):
https://boringssl-review.googlesource.com/c/boringssl/+/33245
Change-Id: I70e15fad4a194c0d2087941bba70dfcd38abe8b5
Follow up to the change made for AVB2 devices in
I19371b05912240480dc50864a2c04131258a7103.
The same consideration must be made in the fall through case, which
is taken either if AVB is completely disabled, or the dm-verity / AVB1
mechanism is used.
Bug: 113175337
Test: boot test on cuttlefish
Change-Id: I99d46a2c2630c40f5f5c02279b11e423998a1e05
Some devices we want to test on, like cuttlefish, may not have a
partition table on any block device Android can see. The partitions are
simply exposed as separate block devices. This means we need to be able
to override the super_partition name to a regular block device name even
on non-A/B devices.
Bug: 113175337
Test: boot test on cuttlefish
Change-Id: I6ff460d0ba7b1e26cb5d60ba446737aa49549c18
When checking for existence of "super_empty.img" to determine if
flash image product set is meant for logical partitions, we die if
ANDROID_PRODUCT_OUT environment is unset or empty. This check
is done before we look at the flash image name to determine if it
is a candidate to look at the logical metadata.
Instead, allow this check to conservatively fail for now.
Test: export ANDROID_PRODUCT_OUT=
fastboot flash bootloader
Bug: 120041144
Change-Id: I43f124015f9d26c79a0feb9123522432fe937343
Merged-In: I43f124015f9d26c79a0feb9123522432fe937343
Non-treblized devices use ld.config.legacy.txt, which does not
support product partition, leading to access denial from/to product partition.
Declare directly /product since search paths are resolved in linker config.
Test: m -j with non-treblized device upgraded to P.
Change-Id: Ic142b807f5dbffdfa5c774b3df8d0903b9626b6a
There is a problem about tombstone, which it will fail to
generate tombstone file in some scenarios due to socket
communication exception.
Reproduce step:
step 1: reboot device
step 2: ps -ef |grep zygote , get the pid of zygote64
(Attention: zygote64 should never been killed or reboot,
otherwise we can get the tombstone file)
step 3: kill -5 pid of zygote64
step 4: cd data/tombstones/, and could not find the tombstone
file of zygote64.
[Cause Analysis]
1. There are following logs by logcat:
11-19 15:38:43.789 569 569 F libc : Fatal signal 5 (SIGTRAP),
code 0 (SI_USER) in tid 569 (main), pid 569 (main)
11-19 15:38:43.829 6115 6115 I crash_dump64: obtaining output
fd from tombstoned, type: kDebuggerdTombstone
11-19 15:38:43.830 569 5836 I Zygote : Process 6114 exited
cleanly (0)
11-19 15:38:43.830 777 777 I /system/bin/tombstoned: received
crash request for pid 569
11-19 15:38:43.831 6115 6115 I crash_dump64: performing dump of
process 569 (target tid = 569)
...
11-19 15:38:43.937 777 777 W /system/bin/tombstoned: crash
socket received short read of length 0 (expected 12)
2. The last log was print by function of crash_request_cb in
file of tombstoned.cpp, following related code:
rc = TEMP_FAILURE_RETRY(read(sockfd, &request, sizeof(request)));
if (rc == -1) {
PLOG(WARNING) << "failed to read from crash socket";
goto fail;
} else if (rc != sizeof(request)) {
LOG(WARNING) << "crash socket received short read of length " << rc << " (expected "
<< sizeof(request) << ")";
goto fail;
}
Tombstoned read message by socket, and now the message length is
zero. Some socket communication exception occurs at that time.
We try to let crash_dump resend the socket message when the
communication is abnormal. Just as this CL.
Test: 1 reboot device
2 ps -ef |grep zygote , get the pid of zygote64
(Attention: zygote64 should never been killed or reboot,
otherwise we can get the tombstone file)
3 kill -5 pid of zygote64
4 cd data/tombstones/, and could find the tombstone file of
zygote64.
Change-Id: Ic152b081024d6c12f757927079fd221b63445b18
The excessive logging of pages with segfaults is making it hard to
see what caused the problem, only log the first page that segfaults,
the range that was being walked when the first segfault happened,
and the total number of pages that segfaulted.
Bug: 120032857
Test: memunreachable_test --gtest_filter=HeapWalkerTest.segv
Change-Id: I71821a3f5be65f2fbcb36afc4b7b1ffa4a48e660
Most vendor_overlay files are product specific that are not allowed
to be installed on system partition.
To install those files on product partition, product/vendor_overlay
is added to the vendor_overlay source directory list.
If the same files are provided from both partitions, files on product
partition will be used.
Bug: 119850553
Test: Build and boot to check if the vendor_overlay works
Change-Id: I1ae97cb5c9dd66d1da5c9eaa3133426d2ba77471
There is an issue in LogAudit::auditParse where
android::uidToName(uid) crashes with a null pointer dereference.
Include a null check on the value before passing it on.
Bug: 120043607
Test: End-to-end test with syzkaller as per instructions in bug.
Change-Id: Ic0ac5c3003fcd289ec156ce63fbd668413763429
If scratch gets made too small (eg: fastboot flash scratch small-file)
it can not recover without a workaround. The workaround is not
intuitive, (adb enable-verity then adb disable-verity to erase and
re-establish the proper sized scratch. This needs to be automatic.
If we detect it is too small to support a filesystem, resize it to an
more appropriate size if it exists.
Alter unit test to check for fastboot characteristics and assumptions
associated with the scratch partition, and a test case to flash the
partition.
Test: adb-remount-test.sh
Bug: 109821005
Change-Id: Icfceaa461c2bf13ca5a7dd4e34675dde8a4d251f
Currently /dev/uinput is owned by system/bluetooth.
But that's inconsistent with some of the sepolicies for uhid_device.
This also means that the new native tests for inputflinger aren't able
to execute properly, because they require the ability to register a new
input device via uinput.
Bug: none
Test: atest inputflinger_test
The newly added EventHub_test is still under review
Change-Id: I53524738db1a5d3ba962b9bec35ef322ed3028f2
init doesn't cooperate with execute-only memory just yet, so disable it
until we can determine the root cause.
Bug: 77958880
Test: Device boots.
Change-Id: Ieb78315ba1e48c9cd0d047a42951bd3fbd36641b
Make XOM related crashes a little less mysterious by adding an abort
cause explaining the crash.
Bug: 77958880
Test: Abort cause in tombstone for a XOM-related crash.
Change-Id: I7af1bc251d9823bc755ad98d8b3b87c12bbaecba
Test: Device boot test with Android Runtime APEX.
Test: Device boot test without Android Runtime APEX.
Bug: 113373927
Change-Id: Iff32fcd79a667b07df839f4e6ef2cdb3cf70e9d3
This method was designed for a single-super model, and now needs to
change to accomodate two super partitions (system_a and system_b, for
retrofitting).
NewForUpdate is supposed to transition metadata from one block device
to the next for updates. For normal devices this is a no-op, since
metadata only exists on one partition (super). For retrofit devices,
metadata exists on system_a and system_b. This has two implications.
First, any references to the source slot must be rewritten. For example
"vendor_b" must become "vendor_a". However this is not true of partition
names. Partitions/extents are cleared in the updated metadata since they
no longer have any meaning (the block device list has been
rewritten). We also clear groups since they are re-added during OTA.
The reason we have to do this rewriting is that slot suffixes are
automatically applied in ReadMetadata. We do not have access to the
original unsuffixed metadata that was written by the initial OTA.
This was a conscious design decision, since it localizes retrofitting
idiosyncracies to just a few places (ReadMetadata, NewForUpdate, and
fastbootd), minimizing the number of external callers that have to
understand auto-slot-suffixing.
It would be arguably cleaner if retrofit metadata was always serialized
*without* slot suffixes, thereby making NewForUpdate a no-op. However
this would necessitate changes to the API elsewhere. The functions that
read partition names would have to take a slot suffix, and this would
further complicate MetadataBuilder and fastbootd. Another solution would
be to augment LpMetadata to retain unsuffixed information, but this is
probably not worthwhile given that retrofitting is intended to be
surgical, and will have a shorter lifespan than the non-retrofit case.
Bug: 116802789
Test: liblp_test gtest
Change-Id: I33596d92b38c47bc70bc0aa37ed04f6f0b9d4b6f
Retrofit devices will have two super partitions, spanning the A and B
slots separately. By design an OTA will never cause "A" or "B"
partitions to be assigned to the wrong super. However, the same is not
true of fastbootd, where it is possible to flash the inactive slot. We
do not want, for example, logical "system_a" flashing to super_b.
When interacting with partitions, fastbootd now extracts the slot suffix
from a GetSuperSlotSuffix() helper. On retrofit devices, if the partition
name has a slot, that slot will override FastbootDevice::GetCurrentSlot.
This forces partitions in the inactive slot to be assigned to the correct
super.
There are two consequences of this. First, partitions with no slot
suffix will default to the current slot. That means it is possible to
wind up with two "scratch" partitions, if "adb remount" is used on both
the "A" and "B" slots. However, only the active slot's "scratch" will be
visible to the user (either through adb or fastboot).
Second, if one slot does not have dynamic partitions, flashing will
default to fixed partitions. For example, if the A slot is logical and B
is not, flashing "system_a" will be logical and "system_b" will be
fixed. This works no matter which slot is active. We do not try to
upgrade the inactive slot to dynamic partitions.
Bug: 116802789
Test: fastboot set_active a
fastboot flashall # dynamic partitions
fastboot getvar is-logical:system_a # true
fastboot getvar is-logical:system_b # false
fastboot set_active b
fastboot flashall --skip-secondary
fastboot getvar is-logical:system_a # true
fastboot getvar is-logical:system_b # true
Booting both slots works.
Change-Id: Ib3c91944aaee1a96b2f5ad69c90e215bd6c5a2e8
On retrofit devices, it is easy to accidentally overwrite
system/vendor/product by flashing system in the bootloader. The reason
is that GPT system_a is really the super partition, and the bootloader
doesn't know it.
Addressing this in bootloaders would require two separate commands: one
that rejects flashing system/vendor/product, and another for
expert/factory use that would allow direct flashing.
This patch introduces protection into the host fastboot tool instead.
It's not mutually exclusive with bootloader changes; having protection
in the host tool affords us better and consistent UI. However it does
rely on users having newer builds.
With this change, the following will not work in the bootloader:
fastboot flash system # or vendor, product, etc
The message is the same whether or not the device is a retrofit. To
continue anyway, you can do:
fastboot flash --force system
If we decide on bootloader protection as well, the --force flag can be
re-used.
Bug: 119689480
Test: fastboot flash system # disallowed in bootloader, allowed in fastbootd
fastboot flash --force system # allowed in bootloader
Change-Id: I0861e3f28a15be925886d5c30c7ebd4b20c477cf
