We want ashmem to only be used via libcutils API, with long-term goal
being deprecation of ashmem with memfd. To do that we route libcutils to
a new source of ashmem fds. We then phase out uses of /dev/ashmem that
doesn't go through libcutils using SELinux.
In Q, we introduced ashmemd as the source of ashmem fds to libcutils.
However, having a separate process and, consequently, binder hops to
handle /dev/ashmem results in performance/memory overhead.
To address the overhead, replace ashmemd with a duplicate of
/dev/ashmem. Name it /dev/ashmem<boot_id>, where boot_id is a random
number generated on each boot. This way we make sure that developers
don't accidentally depend on /dev/ashmem<boot_id>, as that name can't be
hardcoded.
Bug: 139855428
Test: writing "add"/"remove" to /sys/class/misc/ashmem/uevent correctly
adds/removes /dev/ashmem and /dev/ashmem/boot_id
Change-Id: I36d23116048bfcd99903ba46cc133161835a2cfa
Some services are not native android services and therefore don't log
via the normal mechanisms. This gives developers an option to have
their stdout/stderr logs sent directly to kmsg.
Test: see test prints to kernel log
Change-Id: I7973ea74d5cab3a90c2cd9a3d5de2266439d0c01
There are no uevent fils in these dirs, so there's no need to
traverse these dirs.
Test: manual
Change-Id: I57b82846ad863952d8717e6c3ab80c1e243ee4f8
Signed-off-by: lijiazi <lijiazi@xiaomi.com>
Currently system sepolicy can be extended via:
- BOARD_PLAT_PUBLIC_SEPOLICY_DIR
- BOARD_PLAT_PRIVATE_SEPOLICY_DIR
To support having a single shared core system sepolicy, those
customization should be moved to the newly added system_ext partition.
System-ext-specific sepolicy files will be installed into
/system_ext/etc/selinux/*. system_ext_sepolicy.cil is merged into
precompiled_sepolicy at build-time. In case precompiled_sepolicy can't
be used (e.g. system-only-ota), the init will merge this file with
the rest of the sepolicy at runtime.
Bug: 137712473
Test: boot aosp_crosshatch with system_ext_sepolicy.cil
Test: boot aosp_crosshatch without system_ext_sepolicy.cil
Change-Id: Ib37622271b559d65462de99ff424be831004508a
There might be partitions like product or system_ext in addition
to the system partition. Those partitions can contain dependencies
required by the system so we need to make the init to recognize
these partitions and mount them accordingly.
Bug: 140092208
Test: gsi_tool install & reboot
Change-Id: Ie5ef063292c3656e79cce9f887f23a8faa1ba2be
There is a race condition with Service::Start and socket creation.
Since socket creation currently happens after the fork(), it's
possible that init can continue executing other commands before the
socket is created. If init starts another service that relies on that
socket, it isn't guaranteed to be available.
Particularly, we've seen this with hwservicemanager starting after
logd, but hwservicemanager's logs sometimes not showing up.
Bug: 140810300
Test: boot and logging functions correctly
Change-Id: Ib2932e836d345830cd38f3b556598508fd953058
All of the logic in reboot.cpp is meant to safely shutdown services,
safely unmount emulated RW file systems, then finally unmount the
remaining RW file systems, particularly /data. If /data hasn't been
mounted, then none of this logic is required.
Running this logic caused a lock up when shutting down blueline from
early-init. Vold, or potentially a related HAL, locked up during the
ShutdownVold() calls. debuggerd separately locked up in the watchdog
thread.
Therefore, this change immediately reboots if /data is not mounted.
It also removes the lines to call into debuggerd. debuggerd will not
run due to SELinux in any case, so it can only be used when hands-on
debugging a device.
Bug: 141082587
Test: shutdown with /data mounted continues as normal
Test: shutdown from early-init immediately shuts the device down
Change-Id: I79c72346b17c7dfe57e955d9739bcaf559badc14
This code is more generic than it needs to be and one of the side
effects is that an extra init process is forked for odm_init, despite
it having the same context as vendor_init. I don't think anything is
going to change regarding that soon, so this change stops forking that
extra process to save its memory and simplifies the code overall.
Bug: 141164879
Test: init still uses vendor_init for vendor_scripts
Test: init unit tests
Test: init only has one subcontext process
Change-Id: I0d224455604a681711e32f89fb20132378f69060
Replace libcrypto with libcrypto_static, which can be protected through
visibility to ensure only modules that don't affect FIPS certification
can use it.
Bug: 141248879
Test: m checkbuild
Change-Id: I5f0b9acfb57f68570f6f58f2395f2bb1bc015365
When userdata is used to store COW devices, we need to ensure we've
generated uevents for it.
This patch also refactors FirstStageMount to pass required devices
through arguments rather than a member variable.
Bug: 140761481
Test: manual test
Change-Id: Ie5e1c9699f084da5467a758eea41c7907fecc5ca
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Change-Id: I44f746acd1040f7baa9123d4824ba39b194f287b
This replaces the recently added `exec_reboot_on_failure` builtin, since
it'll be cleaner to extend service definitions than extending `exec`.
This is in line with what we decided when adding `exec_start` instead
of extending `exec` to add parameters for priority.
Test: `exec_start` a service with a reboot_on_failure option and watch
the system reboot appropriately when the service is not found and when
the service terminates with a non-zero exit code.
Change-Id: I332bf9839fa94840d159a810c4a6ba2522189d0b
init_first_stage is built in Make and statically links libcrypto,
so it needs to set LOCAL_INJECT_BSSL_HASH to make the FIPS self
test pass.
Bug: 137267623
Test: m checkbuild
Change-Id: Icd8ec07b731228a162db9a13d7304bf1d73127aa
Userspace may want to load a different firmware than the one that the
kernel requests in some cases, therefore this change adds the ability
to ueventd to run an external handler that will determine the name of
the file that should actually be loaded.
Bug: 138352500
Test: unit tests
Change-Id: Ic5da37268fd78109f83ae52d1b903bf7322a5ee5
5aa6197d5f added the ability to
parallelize restorecon to speed up boot for devices that have not
completely moved to genfscon. This parallel restorecon happens after
the parallel ueventd handling.
This causes a performance regression for devices that have moved to
genfscon, since previously, the restorecon() was done in the main
ueventd thread in parallel with the uevent handlers.
I also tried to run the fully parallelized restorecon in parallel with
the uevent handlers, but that did not make any change to the cold boot
time, likely due to the additional overhead of parallelizing the work.
Bug: 140458170
Test: blueline coldboot time returns to pre-regression time.
Change-Id: I3cd6a869cc9b62792466813d94ad6c69834e854e
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Reland: during reboot, init stops processing property_changed messages
from property service, since it will not act on these anyway. This
had an unexpected effect of causing future property_set calls to block
indefinitely, since the buffer between init and property_service was
filling up and the send() call from property_service would then
block. This change has init tell property_service to stop sending it
property_changed messages once reboot begins.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I26902708e8be788caa6dbcf4b6d2968d90962785
On every boot, there is a "duplicate" message logged at INFO level for
every system device-encrypted directory, e.g.:
1 1 I init : Setting policy on /data/app-private
1 1 I init : Encryption policy of /data/app-private set to 3a19970b1aa3abed modes 127/4
Or:
1 1 I init : Setting policy on /data/app-private
1 1 I init : Verified that /data/app-private has the encryption policy 3a19970b1aa3abed modes 127/4
(Before I51ee70706bc9ccb216ccefd7bdfbbfc57faae14d the second messages
were slightly different, but were similar and still at INFO level.)
The issue is that set_system_de_policy_on() prints its own log message,
then calls fscrypt_policy_ensure() which prints a message too; and the
second message is essentially a superset of the first.
Clean this up by removing the message from set_system_de_policy_on().
Test: Booted and checked the log.
Change-Id: I2786ba7e2dbb355f159ac9d8fe5ad1f0a4cdbfea
Added in af1a9bfb8f, but it's never been
used in practice because of the performance impact, and it's incompatible
with our ability to add new system calls via a bionic module update
because it defaults to disabling all unknown syscalls, and init will
still be using the non-updated bootstrap libc from when it first shipped.
Test: treehugger
Change-Id: I8e396675fcfaf0218a92f464d15e613f43319305
Instead of init.cpp knowning about the boringssl self
test, use init.rc to exec dedicated self test executables.
Advantages:
- The self test is run not only both the copy of libcrypto
in /system but also /apex/com.android.conscrypt.
- The self test is run not only for the primary (e.g. 64bit)
ABI but also for a secondarry (e.g. 32bit) ABI.
- The dependency on libcrypto is kept to the self test binary.
- The self test binary abstracts the exact native API for
running the self test (this will change soon because the
self test will be run when the library is loaded).
Bug: 137267623
Test: Check that logcat shows both binaries being started as root,
and finishing with exit code 0.
Change-Id: I1e716749ee2133993f0f7b2836483391fd1a62f0
Add exec_reboot_on_failure builtin and refactor the VDC commands that
had similar functionality. These will now also reboot in the case
that the program cannot be found or run for any reason.
Test: boots normally, reboots if command is not found or if command
returns status '1'
Change-Id: I1c99498c2b741512a50188e1a325c25e9ec8fba0
* changes:
Include com.android.runtime in the "runtime" linker namespace.
Update logic for detecting pre-apexd services to check that the ART APEX is mounted.
Update paths and names for the new ART APEX.
There is a race that manifests like this:
1) A service dies (not processed by init yet).
2) service_manager processes death notification.
3) service_manager gets checkService and calls init to start service.
4) init gets the ctl.start / ctl.interface_start for the service
but the service already appears started, so it does nothing.
5) init gets sigchld, but doesn't do anything else to restart the
service
We can avoid all of this if we already reap pending processes before
handling properties in the main loop of init. Since reaping the
services calls waitid(), there's no race even if the signalfd for
sigchld hasn't triggered yet. It also won't cost us much efficiency,
since it's only a single system call.
Test: CF boots, init unit tests pass
Change-Id: Ie24ef406055b283797b41b1821c8ebcccead4db4
mounted.
Necessary to make e.g. bootanimation work, which depends on (at least)
libandroidicu.so in the ART APEX.
Test: Build & boot
Bug: 135753770
Exempt-From-Owner-Approval: Approved internally
Change-Id: Ibab4f5f7a243d0815b9c70a537bae8d77dee2fbb
Merged-In: Ibab4f5f7a243d0815b9c70a537bae8d77dee2fbb
Treehugger Robot