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
/apex is not mounted via init.rc but directly by the first_stage init
before the mount namespaces are configured.
This allows us to change the propagation type for /apex mount point to
private to isolate APEX activatesions across post- and pre-apexd
processes.
Bug: 125549215
Test: m; device boots to the UI
Change-Id: I10e056cd30d64cb702b6c237acd8dab326162884
The FstabEntry.avb_key is renamed to FstabEntry.avb_keys, to
allow specifying multiple avb keys, separated by ':'
(because ',' is already used by fstab parsing).
Bug: 124013032
Test: boot live GSI with multiple allowed AVB keys
Change-Id: Iacd3472a1d5a659dfecf09ea6074d622658f4d0b
This commit extracts the security patch level (SPL), e.g.,
com.android.build.system.security_patch = 2019-04-05 from AVB property
descriptors when attempting to mount a standalone image (e.g., live
GSI). Then compares the SPL between the old system.img and the new live
system.img for rollback protection.
Bug: 122705329
Test: boot an old Live GSI, checks rollback is detected
Change-Id: I7aae58c0b2062a3ff57ed932ad58e7b604453fed
"ro." properties do not make sense for prop files, especially with the
way that the system/product and vendor/odm partitions are meant to
override each other. To fix this, we ignore the fact that "ro."
properties are "write once" when first loading in property files.
We then adjust the order of property file loading, such that we read
partitions from least to most specific, reading in order: system,
vendor, odm, product, product_services.
Bug: 122864654
Test: ro. properties can override when reading build props with
appropriate permissions
Test: ro. properties do not override when lacking permissions to
be set by a given partition
Change-Id: Ib9a5f77e95d9df647cdde7a5c937bb3425c066fa
Commit I27dd391fc06a3c78e88a65c7931c84de1699f157 make property_service no longer
load selinux property_contexts by function selinux_android_prop_context_handle,
So we should config /odm and /product property_contexts loading path in
property_service.cpp but not in libselinux.
Test: property_service can load property_contexts in /odm and /product
Change-Id: Ifa94b87180c4867ecbe8dea347ad02bb37958043
Currently the dm-verity for live GSI is always enabled, even if the
disable bit in the top-level /vbmeta is set. We should skip setting up
dm-verity on live system.img when adb disable-verity is ever set.
Bug: 124291583
Test: adb disable-verity, then boot live GSI
Test: fastboot flash --disable-verification vbmeta vbmeta.img,
then boot live GSI
Change-Id: Id52d20d0b2e56dfa7de8f866dcc989b82a96c879
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
It is better to guarantee that a /system or / entry will be present in
first stage mount than it is to maintain the code to fake an entry if
its not present in the input fstab.
Test: adb-remount-test.sh on blueline
Change-Id: I8aa3e704903b8abf06b1c63be071913a9de58eb3
If not present, ro.product.[brand|device|manufacturer|model|name] and
ro.build.fingerprint will be resolved during init from
partition-specific properties.
Test: booted system image, verified properties
Test: booted recovery image, verified properties
Bug: 120123525
Change-Id: I7fe2793a7d9eb65645d92ceb408f1f050acf9a81
In particular, this allows services running as the root user to have
capabilities removed instead of always having full capabilities.
Test: boot device with a root service with an empty capabilities
option in init showing no capabilities in /proc/<pid>/status
Change-Id: I569a5573ed4bc5fab0eb37ce9224ab708e980451
Remove hardcoded cpuset path usage and replace it with a request to
get the path using new API.
Exempt-From-Owner-Approval: already approved in internal master
Bug: 111307099
Test: builds, boots
Change-Id: I211d093c24a682e2d1992c08e4c1d980379711a4
Merged-In: I211d093c24a682e2d1992c08e4c1d980379711a4
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Abstract usage of cgroups into task profiles that allows for changes
in cgroup hierarchy and version without affecting framework codebase.
Rework current processgroup and sched_policy API function implementations
to use task profiles instead of hardcoded paths and attributes.
Mount cgroups using information from cgroups.json rather than from init.rc
Exempt-From-Owner-Approval: already approved in internal master
Bug: 111307099
Test: builds, boots
Change-Id: If5532d6dc570add825cebd5b5148e00c7d688e32
Merged-In: If5532d6dc570add825cebd5b5148e00c7d688e32
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
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
It looks like this code is dead currently. From history, this was
meant to be used as a way to check that the recovery image is what was
expected during runtime, but that effort never completed, and we have
full verification of the recovery image when booting into recovery
anyway.
The code is functionally dead as is too, since /recovery doesn't
actually exist in any fstab, since recovery is either mounted as a
ramdisk during recovery or not mounted during normal boot.
Test: boot
Change-Id: I48cd324ef0d5a163db2df2648f6042174b83f10e
SetUpDmVerity won't return true twice for the same partition and it will
leads to failure when verify-boot is enabled on multi-fstab-lines.
Test: make
Change-Id: I5ce35e9c6b2d47fd0f599e36046e1ad2b0a35ffa
We need to be able to tell if /product was updated independently
/system. Otherwise, the device might accidentally load the
precompiled_policy after a /product sepolicy update.
Bug: 119305624
Test: boot aosp_taimen, precompiled policy is loaded
Test: If either of these hashes
/system/etc/selinux/plat_sepolicy_and_mapping.sha256
/product/etc/selinux/product_sepolicy_and_mapping.sha256
are removed, then init falls back to compiling sepolicy at boot time.
Change-Id: I3d658335cf66bcb7123109de701309039b1ae5ba
This reverts commit c661b660fe.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Ie56ea5516887b885579764929e82e4fe684a7dcf
This reverts commit 2599088ff6.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Idea332b1f91e9d2ac6ebd3879da7820c8ba2284f
This reverts commit 5ab1300481.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Iec3347d7f35fbb6f32fd1192135a0cf87dc123a7
These files, including their building rules, have been removed in favor
of their dynamically linked versions; we no longer need to explicitly
restorecon the actual files either, for the same reason as in commit
05f96a2561. When doing normal boot, these
files come from system.img, which have been labeled at build time; when
booting recovery, they don't need dedicated labels to be functional.
Test: Build and boot crosshatch.
Test: Factory reset under recovery on taimen (mke2fs).
Test: Factory reset under recovery on crosshatch (make_f2fs).
Change-Id: Icbcd24aad8be1e7f4ba7d379acd5855d256ae106
Dump only uninterruptible tasks instead of all tasks when
unmount timeout. Also dump current CPU stack traces.
Bug: 122858312
Test: Reboot with and without timeout
Change-Id: I1412ace022b6d78e25fbe1337d1082d4be9c19c0
/system/etc/selinux/mapping/V.v.cil is being split into /system and
/product parts.
Change init to account for /product/etc/selinux/mapping/V.v.cil mapping
file when merging SELinux policies.
Bug: 119305624
Test: boot taimen
Test: "cnd" type is declared in /vendor; "dataservice_app" type is
declared in /product. This permission is preserved
"allow cnd dataservice_app:binder { transfer call };"
Change-Id: I65995a75041044ae71c148d655a70c5efd3b84cc
Running fsck when filesystem is in clean state is unnecessary
and causes long shutdown duration.
Bug: 120575926
Test: shutdown
Change-Id: I0562bdad4ac2fb2dd3c9617f96ca3d6279876bd8
Signed-off-by: Randall Huang <huangrandall@google.com>
