Age | Commit message (Collapse) | Author |
|
"LA.QSSI.12.0.r1-07600-qssi.0"
Change-Id: Iad9e2be9a76060a64223f9cddca8f5ae6b6eb952
|
|
Change-Id: Iaf5eb813e848ef05b1b455ebfe3643f4a8b4f80d
|
|
These aren't actually duplicate interfaces because we
are overriding the service so interfaces in the original
definition will never be used.
Test: Verify 'm dist' works without complaining about
duplicate interfaces.
Change-Id: Iab5e1d8bb4cb7d5b2608028c3cee73af94c47424
|
|
"LA.QSSI.12.0.r1-06800-qssi.0"
Change-Id: I979d0f844cf44539ca87aade5929a4c84b4d31ff
|
|
|
|
Note: Since there is no __ANDROID_API_T__ in this branch, and no api
define for 32, we have to hardcode the number.
Bug: 226699360
Bug: 226699360
Test: manual test
Change-Id: I2602eaa217a2b6cba8a5fb8acd6d5a8a9e3d405e
(cherry picked from commit 3a364add0b264ea5446d7bd984509c65b6aca97c)
|
|
Bug: 220074017
Change-Id: I682501b298008e130a29cab70f947f12c140e314
|
|
This is a race between init process and bionic libc initialization of
snapuserd.
init->fork() ----------------> SecondStageMain() -> PropertyInit()
|
|
v
execveat ---> __libc_init_common() -> __system_properties_init()
(snapuserd)
When init process calls PropertyInit(), /dev/__properties__ directory
is created. When bionic libc of snapuserd daemon invokes __system_properties_init
_after_ init process PropertyInit() function is invoked, libc will
try to initialize the property by reading
/system/etc/selinux/plat_property_contexts. Since any reads on /system
has to be served by snapuserd, this specific read from libc cannot be
serviced leading to deadlock.
Reproduce the race by inducing a sleep of 1500ms just before execveat()
so that init process calls PropertyInit() before bionic libc
initialization. This leads to deadlock
immediately and with additional kernel instrumentation with debug
logs confirms the failure:
======================================================
init: Relaunched snapuserd with pid: 428
ext4_file_open: SNAPUSERD: path /system/etc/selinux/plat_property_contexts - Pid: 428 comm 8
ext4_file_read_iter: SNAPUSERD for path: /system/etc/selinux/plat_property_contexts pid: 428 comm 8
[ 25.418043][ T428] ext4_file_read_iter+0x3dc/0x3e0
[ 25.423000][ T428] vfs_read+0x2e0/0x354
[ 25.426986][ T428] ksys_read+0x7c/0xec
[ 25.430894][ T428] __arm64_sys_read+0x20/0x30
[ 25.435419][ T428] el0_svc_common.llvm.17612735770287389485+0xd0/0x1e0
[ 25.442095][ T428] do_el0_svc+0x28/0xa0
[ 25.446100][ T428] el0_svc+0x14/0x24
[ 25.449825][ T428] el0_sync_handler+0x88/0xec
[ 25.454343][ T428] el0_sync+0x1c0/0x200
=====================================================
Fix:
Before starting init second stage, we will wait
for snapuserd daemon to be up and running. We do a simple probe by
reading system partition. This read will eventually be serviced by
daemon confirming that daemon is up and running. Furthermore,
we are still in the kernel domain and sepolicy has not been enforced yet.
Thus, access to these device mapper block devices are ok even though
we may see audit logs.
Note that daemon will re-initialize the __system_property_init()
as part of WaitForSocket() call. This is subtle but important; since
bionic libc initialized had failed silently, it is important
that this re-initialization is done.
Bug: 207298357
Test: Induce the failure by explicitly delaying the call of execveat().
With fix, no issues observed.
Tested incremental OTA on pixel ~15 times.
Ignore-AOSP-First: cherry-pick from AOSP
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I86c2de977de052bfe9dcdc002dcbd9026601d0f3
(cherry picked from commit 65f3d09445699910947fd73b35979121b2bf07fb)
Merged-In:I86c2de977de052bfe9dcdc002dcbd9026601d0f3
|
|
Google's SafetyNet attestation includes checks for the integrity of the
verified boot chain, as reported by some ro.boot.* properties normally
passed by the bootloader. Unconditionally reporting successful, valid
values helps pass SafetyNet checks, as long as other system state is
intact.
However, the real prop values must be retained in recovery/fastbootd in
order for fastbootd to allow/deny flashing correctly based on the
bootloader lock state. This is accomplished by checking androidboot keys
in the kernel cmdline and bootconfig (necessary on Pixel 6), and not
spoofing anything if the boot isn't a normal full-blown Android boot.
Change-Id: I66d23fd91d82906b00d5eb020668f01ae83ec31f
|
|
"LA.QSSI.12.0.r1-05800-qssi.0"
Change-Id: I057db3543fad7cab3fbda5a5ac742c92b2e2b3c5
|
|
[Adrian DC] Preserve the log while permissive
Change-Id: I3f2887930e15d09014c2594141ba4acbbc8d6d9d
|
|
Allow optional vendor-specific initializations
within init. This can be used for runtime
initialization setup that init rc scripts do
not support.
Change-Id: I7623a0d59b18f9ec8e3623958e2f7ccd72b877bf
|
|
Change-Id: Id04e29c2e6639a50d8ad7accc675e03d38f50b6c
|
|
This change only *adds* /system_ext/etc/selinux to the debug policy
search path, and does not change any preconditions to load the debug
policy. The device still needs to be bootloader-unlocked and has the
debug ramdisk flashed to be able to use the debug policy. The only thing
changed is that now the debug policy can be loaded from /system_ext or
/debug_ramdisk when system partition is compliance testing GSI.
The debug policy in the boot ramdisk may be outdated if the system
partition is flashed with a image built from a different revision.
This happens frequently when running the compliance testing VTS, where
the device is flashed with (A) GSI and (B) device vendor image & debug
boot image, and (A) and (B) are built from different git revisions.
To address this, we install a copy of the debug policy under
/system_ext, so that the version desync between (A) & (B) wouldn't be a
problem anymore because (A) no longer relies on the debug policy file
from (B).
Bug: 188067818
Test: Flash RQ2A.201207.001 bramble-user with debug ramdisk & flash
gsi_arm64-user from master, device can boot and `adb root` works
Change-Id: I4d6235c73472e4d97619b2230292e6a0bc4b3e05
Merged-In: I4d6235c73472e4d97619b2230292e6a0bc4b3e05
(cherry picked from commit 650b29d2349253a0dd6000564ccb2c19b51352db)
|
|
This property will hold the major.minor part of the kernel version (e.g. "5.4"), allowing init scripts to act depending on that version, enabling and disabling certain features.
Bug: 194156700
Test: manual on a Pixel device
Signed-off-by: Alexander Potapenko <glider@google.com>
Merged-In: Icec640b8a7150b344d9aa3bc0bdbcdae050c7c45
Change-Id: I5af411e39da600e5e0f6703f3a2a4930d509e29d
|
|
into s-keystone-qcom-dev
|
|
Revert "[automerger] cc/cc.go: Support per-image-variation "requ..."
Revert submission 579058-b/196306898
Reason for revert: Devices not booting in Keystone lab
Reverted Changes:
I53f309b36:[automerger] init: Separate the required modules o...
I68be9ad4c:[automerger] Skip dexbootjar check using AllowMiss...
I068fefdef:[automerger] cc/cc.go: Support per-image-variation...
I40ae1fe6b:Remove unused VSDK projects
I78b062afd:Skip dexbootjar check using AllowMissingDependenci...
I03f0cf6af:init: Separate the required modules of core and re...
Iebab29ed5:cc/cc.go: Support per-image-variation "required"
Change-Id: I13bf7eacd9bfdabfaf16deec02773c6f07cbad9c
|
|
into s-keystone-qcom-dev
|
|
Change-Id: Id2fbfa6a186ebfdc54c125b5232799b0eaa6a286
|
|
So that init_second_stage (core) depends on core variant tools and rc
files, and init_second_stage.recovery depends on recovery variant tools
and recovery specific rc files.
Bug: 191369319
Test: Presubmit
Test: Check the ninja graph, init_second_stage.recovery no longer depend
on core variation modules
Test: Check out/soong/Android-${PRODUCT}.mk
Change-Id: I03f0cf6af10617fe2e7de677e9dde1aecb2afc74
(cherry picked from commit 9ba6a5b8a20019e6e65fb8c79d2ce2dbd644ed3b)
|
|
This reverts commit 1c51525f6686a97e32c166facad93fc97eacf0f9 because it
accidentally made reboot_on_failure be a no-op for all services. This
is because Reap() itself calls KillProcessGroup() on devices with a
vendor level >= R, which in turn sets SVC_STOPPING. I had overlooked
this somehow, probably because I didn't consider that a service can
consist of multiple processes.
It turns out that real FDE devices don't actually need the above commit
because FDE devices aren't allowed to have updatable apexes enabled, and
without updatable apexes enabled, apexd exits automatically and
therefore doesn't have to be stopped. This can be verified by using the
aosp_cf_x86_phone_noapex build target, rather than aosp_cf_x86_phone
which I had used for testing before. So just revert it for now.
Bug: 194370048
Change-Id: I90eddf2a87397449b241e5acaaa8d4a4241d73a9
(cherry picked from commit d14a178d01fd1690cf8c9f69dd8672b29f946a10)
Merged-In: I90eddf2a87397449b241e5acaaa8d4a4241d73a9
|
|
Change-Id: I63897770711a81d331de3f325affa88c3a56784f
|
|
If a bootconfig argument has a list of values, it has a space between
them in /proc/bootconfig.
Example:
BOARD_BOOTCONFIG := parameter=value1,value2,value3
In /proc/bootconfig, it looks like:
parameter = "value1", "value2", "value3"
Before this CL, that example would end up with the value string of:
"value1, value2, value3"
To keep consistent behavior with kernel cmdline the value string should be:
"value1,value2,value3"
Test: Boot cuttlefish with test bootconfig params and verify ro.boot.*
Bug: 192257482
Merged-In: Iccdec451f53330162fa2c9ad2b7c2630f32b4168
Change-Id: Iccdec451f53330162fa2c9ad2b7c2630f32b4168
|
|
into sc-dev
|
|
Test: m
Bug: 192647837
Change-Id: I11dca132168d6a30372d7a68fe590894d3cc5ccf
Merged-In: I11dca132168d6a30372d7a68fe590894d3cc5ccf
|
|
|
|
|
|
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Update init_first_stage"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert "Add BOARD_BUILD_SYSTEM_ROOT_IMAGE to config vars"
Revert "Add install_in_root to cc_binary"
Revert "Add ramdisk_available to init_first_stage's deps"
Revert submission 15071196-init_first_stage_soong
Reason for revert: fixes b/192248690
Reverted Changes:
I23cf4f975:Add ramdisk_available to init_first_stage's deps
Icd98c7e24:Add ramdisk_available to init_first_stage's deps
If9da9ba16:Add ramdisk_available to init_first_stage's deps
Ibc8668029:Add ramdisk_available to init_first_stage's deps
I3b4b8c475:Add ramdisk_available to init_first_stage's deps
I59cd149e0:Completely migrate init first stage to Soong
I36d789578:Add ramdisk_available to init_first_stage's deps
I2a0daa612:Add BUILD_USES_RECOVERY_AS_BOOT to soong config
Ic76c325ce:Directly create ramdisk dirs in ramdisk image rule...
I4c5374deb:Add BOARD_BUILD_SYSTEM_ROOT_IMAGE to config vars
I8aab5faf3:Add ramdisk_available to init_first_stage's deps
I9d5a10661:Add ramdisk_available to init_first_stage's deps
Iaa2edeb4a:Add ramdisk_available to init_first_stage's deps
I7cb582ca0:Update init_first_stage
I06091d15e:Add ramdisk_available to init_first_stage's deps
I8bdb8dda3:Add ramdisk_available to init_first_stage's deps
I7436b8dd1:Add ramdisk_available to init_first_stage's deps
I39693fd86:Add ramdisk_available to init_first_stage's deps
I0a9ba90f0:Add ramdisk_available to init_first_stage's deps
Ib66b4c4ea:Add ramdisk_available to init_first_stage's deps
I31ce63d23:Add ramdisk_available to init_first_stage's deps
Icb580f97c:Add ramdisk_available to init_first_stage's deps
I044a075b7:Add ramdisk_available to init_first_stage's deps
I33164a7e7:Fix ndk and aml arch order
Ib8d92904a:Add ramdisk_available to sysprop_library
Ibc3516453:Add install_in_root to cc_binary
Change-Id: I147777bb1c4a3b818bc0118c6cf44ccfbf7970a0
|
|
This test requires running test services, which causes test to crash
(and still incorrectly be reported as passing) when running on
non-rooted device.
Ignore-AOSP-First: reboot_test is not in AOSP yet
Bug: 190958734
Test: atest CtsInitTestCases
Change-Id: I3c5c9917d0a787d66272ccf4aefc57e6573841bc
|
|
This reverts commit 0a799bdfd607b729e94796e414d406839d6ad6ad.
Now that the kernel bootconfig feature has been to updated to handle
mixed subkeys and values, androidboot.hardware parameter is supported.
Test: build and boot Cuttlefish with "androidboot.hardware=cutf_vm"
Bug: 191502832
Merged-In: I0e436a27730d20689bc6974562c3e88d744385db
Change-Id: I0e436a27730d20689bc6974562c3e88d744385db
|
|
|
|
Androidboot parameters have moved from /proc/cmdline to /proc/bootconfig
so we need to check both places in reboot_utils.
"ro.boot.*" properties can not be used because this is initialized
before the properties are set.
Test: boot Cuttlefish with init_fatal_panic and
init_fatal_reboot_target in bootconfig and in cmdline
Bug: 191494101
Merged-In: I6c230496ec1c3632470d20ff4a31f28db96ea71b
Change-Id: I6c230496ec1c3632470d20ff4a31f28db96ea71b
|
|
adb_debug.prop is migrated too. And ramdisk_available is added to all
dependencies.
Bug: 187196593
Test: boot
Change-Id: I59cd149e0021211b8fd59c44b93bbf18dc8637bf
Merged-In: I59cd149e0021211b8fd59c44b93bbf18dc8637bf
|
|
Change-Id: Ifacd718e7a3cbde1afa75d11a1b14e64286c2847
|
|
Ignore-AOSP-First: Awaiting security triage
Bug: 187862380
Bug: 190126442
Test: CtsInitTestCases
Change-Id: Ibb34a6b8a5675dbc515b7f8a43d7eecf2084510c
(cherry picked from commit aea97815308ab98faf1599c16d6190b787d34941)
|
|
Ban weird paths such as /../system or //vendor in first stage mount.
Add utility function fs_mgr_create_canonical_mount_point() that:
* mkdir(mount_point) to ensure mount_point's existence
* Test that realpath(mount_point) =?= mount_point
Bug: 188898525
Test: Presubmit
Test: Boot CF
Change-Id: Iaf2ec52701277f26cc81f3e15a47b6083a788334
Merged-In: Iaf2ec52701277f26cc81f3e15a47b6083a788334
(cherry picked from commit 3431d52675f25020b279c9fbcda6b8648f9cf67b)
|
|
Rename fs_mgr_overlayfs_mount_fstab_entry() to
fs_mgr_mount_overlayfs_fstab_entry() and move it out of
fs_mgr_overlayfs.cpp to make it available for user builds.
Add checks to unsure overlayfs mount point doesn't contain symbolic
link or /../.
Check the mount point with an allowlist if user build. The mount point
should either be /vendor, /product ... or their submounts, or strict
submounts of /mnt/vendor and /mnt/product.
Bug: 188862155
Test: Boot test with overlayfs mount entries on user build
Change-Id: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
Merged-In: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
(cherry picked from commit 23816e84ca8821f303d9a3e753d7c050881bacd5)
|
|
* Add logs.
* Append "override_creds=off" overlayfs mount flag only if
fs_mgr_overlayfs_valid() returns kOverrideCredsRequired.
Pre-4.6 kernels or kernels without the override_creds patch don't
need or don't recognize the override_creds mount flag.
(Background: I832c8ca3fce0269bdef4ce988541adb7ba9662ed)
* mkdir(mount_point) before mount() to ensure the mount point exists.
This could happen if the mount point is in a tmpfs, such as /mnt.
Bug: 188862155
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I1a05696346610d7fd61de6d25c379520fd58ca9b
Merged-In: I1a05696346610d7fd61de6d25c379520fd58ca9b
(cherry picked from commit dcf1c1f46235637a6d1057c88e6d1fed88e1b90a)
|
|
GetDmVerityDevices() should filter out overlayfs fstab entries in the
first place, so InitRequiredDevices() don't need to filter out overlayfs
pseudo device names.
Bug: 188862155
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I0ac8b7ac0f21daa0c191580d9349adf217854864
Merged-In: I0ac8b7ac0f21daa0c191580d9349adf217854864
(cherry picked from commit 87290f8e9bb11b919e049e3662819af81e2a35c9)
|
|
Change-Id: I9e72fbfdbfff79342269f330683fee1cd9f8ad11
|
|
|
|
|
|
b026f15df0 am: 8408b03092
Original change: https://android-review.googlesource.com/c/platform/system/core/+/1698093
Change-Id: Ic7cca5299f5a9f06cfc701990bcf781e3103f82f
|
|
Change-Id: If1e45c0407ebeee685e65e47b54a353ef88b401f
|
|
Add overlayfs (lowerdir) mount entry support to fstab.
overlay <final dir> overlay lowerdir=/1:/2
E.g.
overlay /vendor overlay lowerdir=/odm/vnd_ovl1/1:/odm/vnd_ovl2
Test: Ensure mounting with fstab overlayfs entry
CRs-Fixed: 2942496
Change-Id: Ib025e203f8ac1836ab62dfa96fb14e8e108f82fb
|
|
Add a test to check the build fingerprint when the dynamic build
id is in use.
Bug: 186786987
Test: th
Change-Id: I44d6be0c18552f319bcb8d19cca5659ce580d26c
|
|
8b6d881071 am: 4e83aa5beb
Original change: https://android-review.googlesource.com/c/platform/system/core/+/1695266
Change-Id: I3be9c44e07194c9c317677fe33e9dc1568548783
|
|
|
|
9beeed390c am: 8456b731d8
Original change: https://android-review.googlesource.com/c/platform/system/core/+/1698925
Change-Id: I1cdeeeed17212edcdd120cdddfd79e2ed7106231
|
|
Background in http://go/compatible-build-fingerprint. To uniquely
identify the mixed build, we plan to append the unique vbmeta digest
to ro.build.id.
If BOARD_USE_VBMETA_DIGTEST_IN_FINGERPRINT is true, the build system
will not set ro.build.id. Instead, init will set it at runtime, by
appending the digest to the legacy build id.
Bug: 186786987
Test: build and boot a device with new build id
Change-Id: Idea57df599bfd6eede760671e2555541f7dc3f21
|