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>
This patch supports zram_writeback enabled by fstab in two ways.
e.g.,
/dev/block/zram0 none swap defaults
zramsize=1073741824,max_comp_streams=8,zram_loopback_path=/data/unencrypted/zram_swap
==> loopback size is 512MB by default.
Or,
/dev/block/zram0 none swap defaults
zramsize=1073741824,max_comp_streams=8,zram_loopback_path=/data/unencrypted/zram_swap,zram_loopback_size=1G
==> loopback size can be specified by "zram_loopback_size=%s" with "GB" or "MB".
Or,
/dev/block/zram0 none swap defaults
zramsize=1073741824,max_comp_streams=8,zram_backing_dev_path=/dev/block/partition
Bug: 74582279
Bug: 122659265
Change-Id: I66a2e6953b4743a34cf732dd0f5b5256c901f247
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
*/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
I7d47ea1223f7792a834981c729694242ab3f28c9 tried to identify processes that crash
after apexd is ready by introducing an 'updatable' class. However, after
I7ca67755dc0656c0f0c834ba94bf23ba9b1aca68 we now have a pre_apexd_ field we can
reuse instead of introducing a new class type.
Bug: 120598832
Test: Killing a !pre_apexd_ process 4 times in 4mins sets the
ro.init.updatable.crashing prop while killing a pre_apexd_ process reboots
into the bootloader
Change-Id: Icb9f405b9b54d11546bbf6d3bc28212936a78b0e
Before, this process had no threadpool, so it could make blocking
calls, but if it did, they would block forever. Now when this
happens, an error is logged so that we can easily see this happen.
Bug: 36424585
Test: boot
Change-Id: I7d2fa12b6d5a243bdde13ce4d974a444133749f7
It is causing problem to the sdcardfs. Specifically, re-mounting events
for /mnt/runtime/{runtime|write} done by the vold process (which is a
pre-apexd process) are not being propagated to other mount namespaces.
As a result, SDCard access isn't working.
The propagation problem is a bug in sdcardfs which is fixed by [1].
However, we can't make all Android devices to have the patch at the same
time. Therefore, by default the separate mount namespace is not created
and will be created only for the devices where the kernel patches are in and
ro.apex.bionic_updatable sysprop is set to true.
[1]
d73d07673edbdbe78e1a7d00e7827ba9bfd86a59 ("ANDROID: mnt: Fix next_descendent")
b5858221c1c4f4bdc9ef67eb75ecf22580368820 ("ANDROID: mnt: remount should propagate to slaves of slaves")
Bug: 122559956
Test: m
Test: device boots
Test: sdcard works (e.g. camera can take pictures)
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Change-Id: I7a309bab46356ee5782f34c5963d1760963c0b14
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 commits allows multiple lines in a fstab have the same mount
point for first-stage mount, where the first successful mount will be
used.
This allows us to specify a common/shared fstab, with different
settings (e.g., ext4, squashfs) per line, to mount different types
of images on the same mount point. e.g., allows the device to mount
GSI (ext4) while support mounting the original squashfs system.img.
Sample fstab:
fstab in dt:
android {
fstab {
odm_ext4 {
dev = "/dev/block/by-name/odm";
mnt_point = "/odm";
type = ext4;
mnt_flags = "ro";
fs_mgr_flags = "slotselect";
};
odm_f2fs {
dev = "/dev/block/by-name/odm";
mnt_point = "/odm";
type = f2fs;
mnt_flags = "ro";
fs_mgr_flags = "slotselect";
};
};
}
fstab in file:
/dev/block/by-name/odm /odm ext4 ro slotselect
/dev/block/by-name/odm /odm f2fs ro slotselect
Test: make & boot & check /proc/mounts
Change-Id: I64892e3007b0cfd7d06dad1cfc664c45305197ee
X86 Kernel could pass CPU capablity to init as argument. This will cause init
can't start first-stage because unknown argument. Need remove this restriction
of arguments to start init successfully.
Fixes: 122435289
Test: Android init can start successfully
Change-Id: I1d432e25553589dd7f618e42ad238b9372dbe34f
Signed-off-by: Haoyu Tang <haoyu.tang@intel.com>
Signed-off-by: Xihua Chen <xihua.chen@intel.com>
Removing restorecon on root sepolicy files because:
1. Under normal boot the files are properly labeled when creating the
image. Restorecon'ing them successfully would require "adb remount".
2. These restorecon's are not required for recovery to function.
Fixes: 122535196
Test: boot blueline
Change-Id: I20b127e950b16535d4bfa9fd4e626e11228925e7
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
As bionic libs are moved from /system to the runtime APEX, anything that
is outside of the runtime APEX cannot use private symbols from the
bionic libs.
init is not included in the runtime APEX but is using private bionic
APIs: __system_property_[add|area_init|update|...]. So, it was required
to publicize the private symbols for init.
However, since init is started before the runtime APEX is activated, it
actually cannot use the bionic libs from the runtime APEX, but will use
the bootstrap bionic libs left in /system/bootstrap/lib[64]. Because
init and the bootstrap libs are in the same partition, init doesn't need
to link against the stubs of bionic libs. In order to make this
possible, the new property 'bootstrap' is set to true allow init to use
the bootstrap bionic.
Bug: 120266448
Test: m with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: If61f25faf9aed4968bf2922859ceb94276ba03fb
This reverts commit e2b04b71ae.
Conditionally reintroduce the shutdown animation as there is some
interest in retaining it.
Bug: 117854737
Test: n/a
Change-Id: I99a085bc763e230de46aa44b3488d771f7ad04ce
Critical processes currently cause the device to reboot into recovery when they
crash 4 times in 4mins.
We extend this feature to a new 'updatable' class of init services.
If these services crash 4 times in 4mins, instead of rebooting into bootloader,
we set ro.init.updatable_crashing to '1'. apexd and update_verifier will
listen to that property and try to abort and rollback updates, staged apex
modules and new slots respectively.
Test: Tested manually by marking zygote as updatable and killing zygote
frequently, verified that property is set.
Bug: 120598832
Change-Id: I7d47ea1223f7792a834981c729694242ab3f28c9
With all of the changes made to the early init boot phase, the
README.md needs updating for future referencing.
Test: none
Change-Id: Ia572577c683add449a4e091ffd4d1597682e9325
Create /dev/block/by-name/<device> symlink for block devices that are
boot devices but do not have a partition name given.
Test: boot normally
Change-Id: I8c100b0d30dce02a2dd31aebcfea538b8eed9b19
If a partition can be formatted by vold, then it doesn't make sense to
have first-stage mount fail if the partition hasn't been formatted yet.
Bug: 121209697
Test: device boots after fastboot flashall -w
Change-Id: I4a6c794a9912a5e0794983e9514a08f9c23e6ae9
mainline-core is still in the progress of defining interfaces between
/system, /product, /product_services. Before that was completely done,
just updating /system to GSI usually couldn't boot a device.
Therefore, this CL allows GSI to specify a config file, telling init
not to mount /product and /product_services. And fallback to
/system/product and /system/product_services in the GSI.
Bug: 120208657
Test: boots a device with /system/etc/init/config/skip_mount.cfg and
checks both /product and /product_services are not mounted.
Change-Id: Ibe2abad30b178a6e552fb21e4b30207fc3ef5523
We want to move all information required for first stage mount into
the first stage ramdisk instead of using device tree. A previous
change allowed reading the fstab from the first stage ramdisk, but
'vbmeta/parts' was still in device tree. This change allows
specifying the required vbmeta/parts information in the fstab.
The new syntax is that instead of simply specifying 'avb' as an fs_mgr
option, a partition may specify 'avb=<vbmeta partition name>' and that
vbmeta partition will also be initialized by first stage init before
attempting to mount any devices.
Bug: 117933812
Test: boot crosshatch without device tree fstab
Change-Id: Ida1a6da988c10d364b3ccdaa6c5d63e5264d1b27
Some configurations won't allow ueventd to have CAP_NET_ADMIN, so the
new default size of 16M is not possible for those. Those
configurations also won't need such a large buffer size, so this
change allows devices to customize the SO_RCVBUF(FORCE) size for the
uevent socket.
This is done by adding the line 'uevent_socket_rcvbuf_size <size>' to
your device's ueventd.rc file. <size> is specified as a byte count,
for example '16M' is 16MiB.
The last parsed uevent_socket_rcvbuf_size line is the one that is
used.
Bug: 120485624
Test: boot sailfish
Test: ueventd unit tests
Change-Id: If8123b92ca8a9b089ad50318caada2f21bc94707
A symlink for TARGET_ROOT_OUT as a post install command of a package
that is also installed to TARGET_ROOT_OUT. We hijack init.rc which
satisfies this requirement for this symlink.
Bug: 120402274
Bug: 120460755
Bug: 120509320
Bug: 120554662
Test: symlink is created
Test: make bootimage && ls -la $OUT/root/init
Change-Id: I6f1ac06ef152c36d7d7db4618d49a008338da39b
Asan requires /proc to be mounted, which means it fundamentally cannot
be used with first stage init. Given that second stage init now
contains the logic for first stage init, asan must be disabled on all
of init until this can be resolved.
Bug: 120424438
Bug: 120561310
Test: Asan builds boot
Change-Id: I24d1a0c8ecb5eb3f77435e6e36432c7b4cb97c6a
In the non-retrofit case, the metadata source partition will be
hardcoded as "super", but such a partition may not exist or may have
been overridden by super_partition=<something>. Make this work reliably
by plumbing the resolved metadata block device through, and using it any
time a partition called "super" is requested.
This also fixes a case in the first_stage_mount code that assumed that
detected a non-A/B, non-retrofit case by assuming the metadata source
partition would be called "super".
Bug: 113175337
Test: boot test on cuttlefish
Change-Id: I8ce1defb902e257eeb7170d697b378eba31faee3
Now that we have a first stage ramdisk (or use recovery in its place),
it's possible to place a vendor specific fstab along with first stage
init, removing the need for device tree modifications to have an
fstab.
Bug: 117933812
Test: hikey boots with only an fstab in first stage ramdisk
Test: blueline mainline boots with a disabled DT fstab and an fstab in recovery
Change-Id: I4460b88851557a75ba06ff795cd842e7dfb6da46
Increase size of the NETLINK_KOBJECT_UEVENT socket receive buffer to
16M. Also, use SO_RCVBUFFORCE to override any limits set by
/proc/sys/net/core/rmem_max.
We had a couple of instances, where we lost critical uevent messages due
to receive buffer overflows.
Bug: 119933843
Change-Id: I6aab183aa0194e173f9175b47c6beb0835cf6675
init add support for picking up partitions if specified by
fs_mgr_overlayfs_required_devices() as /dev/block/by-name/<partition>
Test: adb-remount-test.sh
Bug: 119885423
Change-Id: I6a4c3d9b5c2b406178f0acf0a86c52ab17209537
Even though it isn't strictly needed when not system-as-root, for
backwards compatibility, it is desired to keep this symlink.
Bug: 119851742
Test: tree-hugger
Change-Id: I47bc25ab257336f56ef09b5db6ebaf6b17daad35
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
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
Bowgo Tsai