| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I403cb7edc6ea22330d3ece8e83d1b02adc5496f2
|
|
|
|
Change-Id: I5dab30887faa50059b7023ed316e66ffd3553695
|
|
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
|
|
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
|
|
The code to read verity state in userspace is deprecated in favor of
having the bootloader read and report the state, so this change
removes this now unused code.
Bug: 73456517
Test: boot
Change-Id: Ib626fd61850bce3016179ca92a9831c2ac29c032
|
|
A fork() was historically added in case of fs_mgr crashing or leaking
memory, but this should not be the case with fs_mgr, and a fork() only
hides any such problem, instead of allowing us to address it
directly.
Test: boot
Change-Id: If7ee4807757048258a6ea9a79a24cebbacc530cc
|
|
umount_all is the cleanup step for mount_all.
In particular, the mount_all builtin creates a verity device,
'postinstall-verity', for the following line:
system /postinstall ... ... slotselect_other,logical,avb_keys=...
cppreopt umounts /postinstall but doesn't destroy the postinstall-verity
device, causing OTA to fail (because it cannot destroy the
system_[other] device). umount_all also destroy the verity device.
Note that mount_all does not map system_[other]; it is mapped by
first stage init. Hence, umount_all doesn't destroy it either. The OTA
client is reponsible for unmapping the device itself.
Bug: 129988285
Test: flash, boot, then check `dmctl list devices`, then OTA
Change-Id: Id3ab65b3860b6ea6cfec310ab13652009c81f415
Merged-In: Id3ab65b3860b6ea6cfec310ab13652009c81f415
|
|
umount_all is the cleanup step for mount_all.
In particular, the mount_all builtin creates a verity device,
'postinstall-verity', for the following line:
system /postinstall ... ... slotselect_other,logical,avb_keys=...
cppreopt umounts /postinstall but doesn't destroy the postinstall-verity
device, causing OTA to fail (because it cannot destroy the
system_[other] device). umount_all also destroy the verity device.
Note that mount_all does not map system_[other]; it is mapped by
first stage init. Hence, umount_all doesn't destroy it either. The OTA
client is reponsible for unmapping the device itself.
Bug: 129988285
Test: flash, boot, then check `dmctl list devices`, then OTA
Change-Id: Id3ab65b3860b6ea6cfec310ab13652009c81f415
|
|
Change-Id: Ib8e341b5da57c0db00a208d1a8323bef84e9124f
|
|
Bind-mounting of the bionic files on /bionic/* paths no longer required
as there are direct symlinks from bionic files in /system partition to
the corresponding bionic files in the runtime APEX. e.g.,
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
Bug: 125549215
Test: m; devices boots
Change-Id: I4a43101c3e3e2e14a81001d6d65a8a4b727df385
|
|
Change-Id: I93403833e5723da878449a076860bd26858cb62a
|
|
Summary: Boot sequence around apexd is changed to make it possible for
pre-apexd processes to use libraries from APEXes. They no longer need to
wait for the apexd to finish activating APEXes, which again can be
done only after /data/ is mounted. This improves overall boot
performance.
Detail: This change fixes the problem that processes that are started
before apexd (so called pre-apexd processes) can't access libraries
that are provided only by the APEXes but are not found in the system
partition (e.g. libdexfile_external.so, etc.). Main idea is to activate
system APEXes (/system/apex/*.apex) before /data is mounted and then
activate the updated APEXes (/data/apex/*.apex) after the /data mount.
Detailed boot sequence is as follows.
1) init prepares the bootstrap and default mount namespaces. A tmpfs is
mounted on /apex and the propagation type of the mountpoint is set to
private.
2) before any other process is started, apexd is started in bootstrap
mode. When executed in the mode, apexd only activates APEXes under
/system/apex. Note that APEXes activated in this phase are mounted in
the bootstrap mount namespace only.
3) other pre-apexd processes are started. They are in the bootstrap
mount namespace and thus are provided with the libraries from the system
APEXes.
4) /data is mounted. init switches into the default mount namespace and
starts apexd as a daemon as usual.
5) apexd scans both /data/apex and /system/apex, and activate latest
APEXes from the directories. Note that APEXes activated in this phase
are mounted in the default namespaces only and thus are not visible to
the pre-apexd processes.
Bug: 125549215
Test: m; device boots
Change-Id: I21c60d0ebe188fa4f24d6e6861f85ca204843069
|
|
Change-Id: Iefeb673073fa3d300ab74aa9dfef7f3a500daeae
|
|
fs_mgr_update_verity_state() has two callers with generally different
intentions. One caller loops through all entries in the default fstab
to set partition.<mount_point>.verified properties. The other caller
is only interested in whether or a specific mount point has verity
enabled.
Given this, we refactor fs_mgr_update_verity_state() to
fs_mgr_get_verity_mount_point() which takes a single FstabEntry and
returns the mount point used for the dm-verity device or an empty
option if verity is not enabled on that mount point.
Test: adb-remount-test.sh test on blueline
Change-Id: Ic7dd8390509e95b2931b21e544c919a544138864
|
|
Conflicts:
libprocessgroup/sched_policy.cpp
Bug: 124069173
Change-Id: I0409464e297a67f5d615e50f928ff52da3bb7f31
|
|
Conflicts:
fs_mgr/fs_mgr.cpp
fs_mgr/fs_mgr_fstab.cpp
fs_mgr/fs_mgr_priv.h
init/reboot.cpp
Change-Id: I88c99bfd0f4bd80fb3d2c974978cf9cb483e68c3
|
|
|
|
Should have been done a while ago, but better late than never.
Test: treehugger
Change-Id: I0ea6e8d459cd3f3b3ce2d00a7a6a9786d52c52dd
|
|
This CL fixes the design problem of the previous mechanism for providing
the bootstrap bionic and the runtime bionic to the same path.
Previously, bootstrap bionic was self-bind-mounted; i.e.
/system/bin/libc.so is bind-mounted to itself. And the runtime bionic
was bind-mounted on top of the bootstrap bionic. This has not only caused
problems like `adb sync` not working(b/122737045), but also is quite
difficult to understand due to the double-and-self mounting.
This is the new design:
Most importantly, these four are all distinct:
1) bootstrap bionic (/system/lib/bootstrap/libc.so)
2) runtime bionic (/apex/com.android.runtime/lib/bionic/libc.so)
3) mount point for 1) and 2) (/bionic/lib/libc.so)
4) symlink for 3) (/system/lib/libc.so -> /bionic/lib/libc.so)
Inside the mount namespace of the pre-apexd processes, 1) is
bind-mounted to 3). Likewise, inside the mount namespace of the
post-apexd processes, 2) is bind-mounted to 3). In other words, there is
no self-mount, and no double-mount.
Another change is that mount points are under /bionic and the legacy
paths become symlinks to the mount points. This is to make sure that
there is no bind mounts under /system, which is breaking some apps.
Finally, code for creating mount namespaces, mounting bionic, etc are
refactored to mount_namespace.cpp
Bug: 120266448
Bug: 123275379
Test: m, device boots, adb sync/push/pull works,
especially with following paths:
/bionic/lib64/libc.so
/bionic/bin/linker64
/system/lib64/bootstrap/libc.so
/system/bin/bootstrap/linker64
Change-Id: Icdfbdcc1efca540ac854d4df79e07ee61fca559f
|
|
This reverts commit 2599088ff67c10c66a70d3741c41529d3e11c7f5.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Idea332b1f91e9d2ac6ebd3879da7820c8ba2284f
|
|
|
|
Bug: 121209697
Test: gsi boots
Change-Id: I69db0f8e999da366e46728b1008602f543cd79f6
|
|
Conflicts:
fs_mgr/fs_mgr.cpp
fs_mgr/fs_mgr_fstab.cpp
fs_mgr/fs_mgr_priv.h
fs_mgr/include/fs_mgr.h
Change-Id: Ibb1b0d9d698f1728e4df068f3119ad5f852c96db
|
|
*/build.prop files are now loaded much earlier than before; from 'on
post-fs' to the time when the property service is started which is
before init starts the action loop.
This ensures that all processes that are launched by init have a
consistent view of system properties. Previously, the processes that
started before 'on post-fs' were initially with the small number of
sysprops loaded from */default.prop and then suddenly get additional
sysprops from */build.prop while they are executing.
Bug: 122714998
Test: device boots
Change-Id: Ic07528421dfbe8d4f43673cea41175d33cfbf298
|
|
This change makes the bionic libs and the dynamic linker from the
runtime APEX (com.android.runtime) available to all processes started
after apexd finishes activating APEXes.
Specifically, the device has two sets of bionic libs and the dynamic
linker: one in the system partition for pre-apexd processes and another
in the runtime APEX for post-apexd processes. The former is referred as
the 'bootstrap' bionic and are located at
/system/lib/{libc|libdl|libm}.so and /system/bin/linker. The latter is
referred as the 'runtime' bionic and are located at
/apex/com.android.runtime/lib/bionic/{libc|libdl|libm}.so and
/apex/com.android.runtime/bin/linker.
Although the two sets are located in different directories, at runtime,
they are accessed via the same path: /system/lib/* and
/system/bin/linker ... for both pre/post-apexd processes. This is done
by bind-mounting the bootstrap or the runtime bionic to the same path.
Keeping the same path is necessary because there are many modules and
apps that explicitly or implicitly depend on the fact that bionic libs
are located in /system/lib and are loaded into the default linker
namespace (which has /system/lib in its search paths).
Before the apexd is started, init executes a built-in action
'prepare_bootstrap_bionic' that bind-mounts the bootstrap bionic to the
mount points. Processes started during this time are provided with the
bootstrap bionic. Then after the apexd is finished, init executes
another built-in action 'setup_runtime_bionic' which again mounts the
runtime bionic to the same mount points, thus hiding the previous mounts
that target the bootstrap bionic. The mounting of the runtime bionic
(which is only for post-apexd processes) is hidden from pre-apexd
processes by changing propagation type of the mount points to 'private'
and execute the pre-apexd processes with a new mount namespace using
unshare(2). If a pre-apexd process crashes and re-launched after the
apexd is on, the process still gets the bootstrap bionic by unmounting
the runtime bionic which effectively un-hides the previous bind-mounts
targeting the bootstrap bionic.
Bug: 120266448
Test: device boots
Test: cat /proc/`pidof zygote`/mountinfo shows that
/system/lib/{libc|libdl|libm}.so and /system/bin/linker are from the
runtime APEX
Test: cat /proc/'pidof vold`/mountinfo shows that the same mount points
are from system partition.
Change-Id: I7ca67755dc0656c0f0c834ba94bf23ba9b1aca68
|
|
This adds the ability to prevent a class from starting
if a certain persistent property has been set to
disallow it.
A class will only load if there is not a property named
persist.init.dont_start_class.[class name] set to 1.
Test: Set a property called persist.dont_start_class.[class]
to 1. Verify that the given class does not start
Change-Id: I51c70ad635762ed77855d0509e630adb0aec0eb1
|
|
Conflicts:
healthd/healthd_mode_charger.cpp
Change-Id: I0a90dc5729e993c0fc27bdf06f813db477da4d90
|
|
Bug: 62292478
Test: boot
Test: adb-remount-test.sh
Change-Id: Id4715af4c1f03e2cfc67de92d3ea58e933685e51
|
|
Bug: 62292478
Test: boot and check verity state
Change-Id: I4912a16ada9a6d72480d7ac905654b764c5d18b6
|
|
Bug: 62292478
Test: build
Change-Id: Ifbde514bf73d3ce2f321326291daa025b6afac46
|
|
There can be no match when there is no APEX installed or no APEX is
providing *.rc file. Don't fail in that case.
Bug: 117403679
Test: m apex.test; m; device is is bootable
Change-Id: Ib1c607ee2c156dc236da1df7df0c6663e8d899b2
|
|
A service with 'updatable' option can be overriden by the same service
definition in APEXes.
/system/etc/init/foo.rc:
service foo /system/bin/foo
updatable
/apex/myapex/etc/init.rc:
service foo /apex/myapex/bin/foo
override
Overriding a non-updatable (i.e. without updatable option) service
from APEXes is prohibited.
When an updatable service is started before APEXes are all activated,
the execution is delayed until when the APEXes are all activated.
Bug: 117403679
Test: m apex.test; adb push <built_apex> /data/apex; adb reboot
adb shell, then lsof -p $(pidof surfaceflinger) shows that
the process is executing
/apex/com.android.example.apex@1/bin/surfaceflinger instead of
/system/bin/surfaceflinger
Change-Id: I8a57b8e7f6da81b4d2843e261a9a935dd279067c
|
|
Init now parses *.rc files from the APEXs when the apexd notifies the
mount event via apexd.status sysprop.
Bug: 117403679
Test: m apex.test; adb root; adb push <builtfile> /data/apex; adb reboot
adb root; adb shell setprop ctl.start apex.test; dmesg shows that init
tries to start the service which doesn't exist.
[ 47.979657] init: Could not ctl.start for 'apex.test': Cannot find '/apex/com.android.example.apex/bin/test': No such file or directory
Change-Id: I3f12355346eeb212eca4de85b6b73257283fa054
|
|
Reboot into recovery to wipe data when metadata encryption
fails instead of continuing boot.
CRs-Fixed: 2341082
Change-Id: If4de94b87f7cb96164b6b9534c12b07e62f7214d
|
|
The file-based encryption setup code is being refactored into its own
library because it applies to both ext4 and f2fs, not just ext4. Update
init to use the new location. For fs_mgr, just remove the include of
ext4_crypt_init_extensions.h since it was unneeded.
Test: built, booted device with f2fs encryption
Change-Id: I392a763e3349f001bdbc09eb9ca975aa3451fd68
|
|
It's better to either check these results or explicitly ignore them.
Only a few callers weren't already doing this, so it's relatively
trivial to enforce.
Test: build
Change-Id: I44cdc342e46128f66cac914aaa0b9b4559cacd8c
|
|
e.x.:
interface_start android.hardware.nfc@1.0/default
onrestart interface_restart android.hardware.nfc@1.0/default
Fixes: 79418581
Test: add this to a service, and killing that service, light is restarted
onrestart interface_restart android.hardware.light@2.0::ILight/default
Change-Id: Ia7ac9380f01038752325cfbe030df1dd4a5665e2
|
|
|
|
Bug: 77335096
Test: device boots twice with and without metadata encryption
Change-Id: Iaed78288cb37865ba23833721b73b11414e7e862
|
|
Bug: 77335096
Test: device boots twice with and without metadata encryption
Change-Id: Iaed78288cb37865ba23833721b73b11414e7e862
|
|
An earlier such change was reverted in commit e242a97db547dc73efea1b5287536be66637dc33.
Bug: 70487538
Test: ensure that angler can boot
Merged-In: Id5f57fce1c9b817a2650e0c848143d8a0d286bf0
Change-Id: Id5f57fce1c9b817a2650e0c848143d8a0d286bf0
|
|
An earlier such change was reverted in commit e242a97db547dc73efea1b5287536be66637dc33.
Bug: 70487538
Test: ensure that angler can boot
Merged-In: Id5f57fce1c9b817a2650e0c848143d8a0d286bf0
Change-Id: Id5f57fce1c9b817a2650e0c848143d8a0d286bf0
|
|
|
|
This reverts commit 959b05553576ffc15da4334a5917ce763611ab82.
Reason for revert: b/73968735
Bug: 73968735
Test: b/73968735#comment5
Change-Id: Ifce4c029bab7380c60e20cc2b2885beb4a097456
|
|
Create a host side parser for init such that init rc files can be
verified for syntax correctness before being used on the device.
Bug: 36970783
Test: run the parser on init files on host
Change-Id: I7e8772e278ebaff727057308596ebacf28b6fdda
|
|
|
|
Test: Roll back PLATFORM_SECURITY_PATCH, ensure recovery dialog is seen
Bug: 70487538
Change-Id: Iceb6af3f9d6aea6bc646dbb4b5d29dffcb284736
|
|
Bug: 36970783
Test: build
Change-Id: I08fa39052236b462249f79de1d02bf02bdbf4c84
|
|
|
