|author||Tianjie Xu <email@example.com>||Tue Aug 06 12:32:05 2019 -0700|
|committer||Bryan Ferris <firstname.lastname@example.org>||Tue Jan 21 21:48:13 2020 +0000|
Force package installation with FUSE unless the package stores on device The non-A/B package installation is subject to TOC/TOU flaw if the attacker can switch the package in the middle of installation. And the most pratical case is to store the package on an external device, e.g. a sdcard, and swap the device in the middle. To prevent that, we can adopt the same protection as used in sideloading a package with FUSE. Specifically, when we install the package with FUSE, we read the entire package to cryptographically verify its signature. The hash for each transfer block is recorded in the memory (TOC), and the subsequent reads (TOU) will be rejected upon dectecting a mismatch. This CL forces the package installation with FUSE when the package stays on a removable media. Bug: 136498130 Test: Run bin/recovery --update_package with various paths; and packages are installed from FUSE as expected Test: recovery_component_test - all passing Merged-In: Ibc9b095036a2fa624e8edf6c347ed4f12aef072f Change-Id: Ibc9b095036a2fa624e8edf6c347ed4f12aef072f
mm -j && m ramdisk-nodeps && m recoveryimage-nodeps # To boot into the new recovery image # without flashing the recovery partition: adb reboot bootloader fastboot boot $ANDROID_PRODUCT_OUT/recovery.img
# After setting up environment and lunch. mmma -j bootable/recovery # Running the tests on device. adb root adb sync data # 32-bit device adb shell /data/nativetest/recovery_unit_test/recovery_unit_test adb shell /data/nativetest/recovery_component_test/recovery_component_test # Or 64-bit device adb shell /data/nativetest64/recovery_unit_test/recovery_unit_test adb shell /data/nativetest64/recovery_component_test/recovery_component_test
recovery-persist executables exist only on systems without /cache partition. And we need to follow special steps to run tests for them.
Execute the test on an A/B device first. The test should fail but it will log some contents to pmsg.
Reboot the device immediately and run the test again. The test should save the contents of pmsg buffer into /data/misc/recovery/inject.txt. Test will pass if this file has expected contents.
When running recovery image from debuggable builds (i.e.
-userdebug build variants, or
adbd service is enabled and started by default, which allows
adb communication. A device should be listed under
adb devices, either in
$ adb devices List of devices attached 1234567890abcdef recovery
/system/bin/adbd is built from the same code base as the one in the normal boot, only a subset of
adb commands are meaningful under recovery, such as
adb pull etc. Since Android Q,
adb shell no longer requires manually mounting
/system from recovery menu.
$ adb devices List of devices attached
adbdis built and running.
adbd is always included into recovery image, as
adbd service automatically only in debuggable builds. This behavior is controlled by the recovery specific
/init.rc, whose source code is at
The best way to confirm a running
adbd is by checking the serial output, which shows a service start log as below.
[ 18.961986] c1 1 init: starting service 'adbd'...
adbd service has been started but device not shown under
adb devices, use
lsusb(8) (on host) to check if the device is visible to the host.
bootable/recovery/etc/init.rc disables Android USB gadget (via sysfs) as part of the
fs action trigger, and will only re-enable it in debuggable builds (the
on property rule will always run after
on fs write /sys/class/android_usb/android0/enable 0 # Always start adbd on userdebug and eng builds on property:ro.debuggable=1 write /sys/class/android_usb/android0/enable 1 start adbd
If device is using configfs, check if configfs has been properly set up in init rc scripts. See the example configuration for Pixel 2 devices. Note that the flag set via sysfs (i.e. the one above) is no-op when using configfs.
$ adb devices List of devices attached 1234567890abcdef unauthorized
recovery image doesn‘t honor the USB debugging toggle and the authorizations added under normal boot (because such authorization data stays in /data, which recovery doesn’t mount), nor does it support authorizing a host device under recovery. We can use one of the following options instead.
For debuggable builds, an RSA keypair can be used to authorize a host device that has the private key. The public key, defined via
PRODUCT_ADB_KEYS, will be copied to
/adb_keys. When starting the host-side
adbd, make sure the filename (or the directory) of the matching private key has been added to
$ export ADB_VENDOR_KEYS=/path/to/adb/private/key $ adb kill-server $ adb devices
-user builds filter out
PRODUCT_ADB_KEYS, so no
/adb_keys will be included there.
Note that this mechanism applies to both of normal boot and recovery modes.
adbdto connect without authentication.
adbdis compiled with
ALLOW_ADBD_NO_AUTH(only on debuggable builds).
ro.adb.securehas a value of
Both of the two conditions need to be satisfied. Although
ro.adb.secure is a runtime property, its value is set at build time (written into
/prop.default). It defaults to
-user builds, and
0 for other build variants. The value is overridable via