This reverts commit 4d35f2e59c.
Reason for revert: b/137523800 This breaks factory reset on all devices (and potentially rescue party and non-ab updates). Because the init code unconditionally clear the arguments like "--wipe_data" written by framework; as a result, device boots into recovery without doing wipe.
I guess one fix is to check the content of BCB, and skip the overwrite if it already boots into recovery. Revert the cl first to unblock p1, will submit the fix separately.
Change-Id: Iccaf3dce6999005c2199490a138844d5a5d99e7f
For devices that use FDE and don't support updatable APEXes, don't
stop and restart all processes - there is no need and it only increases
boot time for these devices.
Additionally, some daemons have never been restarted in the past, and
restarting them exposes certain issues.
Bug: 137251597
Bug: 136777273
Bug: 135627804
Test: verified manually w/ ro.updatable.apex=false
Change-Id: I9590f2c2cdfab0a49f39846896460305d44221ee
This makes `pathmod init` and `gomod init` work, and it also reserves
the 'init' for potential future usage.
Change-Id: I6990bf421211b93d58d978d84d46474ff243e808
Bugs: me
Test: pathmod init; gomod init
clang-tidy hinted that some of this code wasn't right. Looking
deeper, there is really not much related to file and socket
descriptors, except that they're published in similar ways to the
environment. All of the abstraction into a 'Descriptor' class takes
us further away from specifying what we really mean.
This removes that abstraction, adds stricter checks and better errors
for parsing init scripts, reports sockets and files that are unable to
be acquired before exec, and updates the README.md for the passcred
option.
Test: build, logd (uses files and sockets) works
Change-Id: I59e611e95c85bdbefa779ef69b32b9dd4ee203e2
This fixes a race condition where WaitForFile() after
GetDmDevicePathByName appears to succeed, but a subsequent operation on
the path fails. This can happen when CreateDevice() is called
immediately after a call to DeleteDevice (from any process), and the
path is re-used, enqueuing udev events to remove and re-add the block
device.
The fix for this is to introduce a new variant of CreateDevice() that
has a timeout parameter. When the timeout is positive, CreateDevice()
will wait for a /dev/block/mapper/by-uuid symlink to be created, which
signals that ueventd has finished processing the operation.
ueventd will now create these by-uuid symlinks for device-mapper nodes.
Unfortunately, the uuid is only available during "change" events, so we
have to special case device-mapper symlink creation. And since the uuid
is not available during "remove" events, we simply find matching links
to remove them.
This ensures that callers of CreateDevice() can use the device path
knowing that no asynchronous removals are pending. Code that uses the
old CreateDevice+WaitForFile pattern will be transitioned to the new
method.
Note that it is safe to ignore the timeout, or to use the "unsafe"
CreateDevice, if the caller ensures the path by other means. For example
first-stage init has no device removal, and regenerates uevents until
it has acquired all the paths it needs.
Finally, since libdm now inspects sysfs unconditionally, libdm consumers
need r_dir_file perms for sysfs_dm in their sepolicy. Additionally
linking to libdm now requires linking to libext2_uuid.
Bug: 135771280
Test: libdm_test
device flashes, boots
Change-Id: If5a7383ea38f32a7fbbcf24842dce6a668050a70
Bug: 118016875
Test: Added 'interface' lines to an init_rc file and observed errors
when misspelled or missing entire inheritance hierarchy.
Change-Id: I681420f15539742d8415808b2a0dcbf0bf6faaf1
Without this change "adb reboot recovery" leads to normal boot.
Change-Id: I361d0a1f6f6f2c57f3dc80102c21970b462c9b9c
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
- unused
- using binder requires twoway calls (since getting a service from
servicemanager requires two calls)
Bug: 135768100
Test: N/A
Change-Id: Idc41f487bad2d8343e99ded98812f3a84e2b8e37
android-base:
* Add NOLINT for expanding namespace std for std::string* ostream
overload
libdm:
* Fix missing parentesis around macro parameters
init:
* Fix missing CLOEXEC usage and add NOLINT for the intended
usages.
* Fix missing parentesis around macro parameters
* Fix erase() / remove_if() idiom
* Correctly specific unsigned char when intended
* 'namespace flags' should be signed, since 'flags' it signed for
clone()
* Add clear to property restore vector<string> to empty after move
* Explicit comparison against 0 for strcmp
Test: build
Change-Id: I8c31dafda2c43ebc5aa50124cbbd6e23ed2c4101
Start and wait on a console if androidboot.first_stage_console=1 is
present on the kernel command line. This only works on eng and
userdebug builds.
Change-Id: I978e9390a89509431b399ea58b284736b27eeb1b
Test: Adding a misspelling to an init_rc's interface line and observing
build failure.
Bug: 77646540
Change-Id: I58f66d73f0bd9b4203e8259161843b56ad428d73
In retrospect, these always should have been header only. We don't
need setgroups() anymore either, since we have the right symbols now.
Test: build
Change-Id: If6fbf6f8ee288ed261576207d90a7ec5674853f9
By moving it into builtins.cpp..., but that's less bad than it is
now, especially since this is defunct in code targeting Q+. Remove
the guards that init.h isn't being included by other files too as it's
not useful anymore.
Test: build
Change-Id: Ic564fcff9e8716ec924098b07a8c9d94ca25f960
There's no fundamental reason to store this aside. That property can
only be written by init, so it's not likely that we're going to
corrupt it.
Test: boot and use serial console
Change-Id: I9248fbaf959ea913d09add829d4cb509af99d570
It's been a long standing problem that init calls fs_mgr functions
synchronously and therefore stops handling properties, which causes
deadlocks if either fs_mgr, or vdc, or vold attempt to set
properties.
Previous work, b/21904461, shows that there is a large performance
penalty for adding any amount of locking to properties, so moving
property service into its own thread generically is not a viable
option. However, we can be sure that init is not setting properties
while the fs_mgr functions are running, so we can poll the property
socket in a thread while we call these functions.
The other alternative would have been to separate the fs_mgr functions
into smaller pieces and revisit the main init loop between each
piece. Unfortunately, this would be difficult, since
fs_mgr_mount_all() calls out to different processes via logwrapper,
which synchronously polls on a logging FD from the child, among other
complexities that would make this strategy much more difficult than it
would be worth.
Bug: 21904461
Test: device boots, including when setting property in
fs_mgr_mount_all()
Change-Id: Ib0b7123024035884f9d90f9b489c1e2f5a2e1707
Modprobe functionality is required both within first stage init and also
as a standalone binary. Create a library for this using and extending
the logic in modalias_handler.cpp.
First stage init will attempt to load modules from /lib/modules.
Bug: 129780532
Change-Id: Ie3582358fd839c2f64e1b386b30ed551a86aef5d
Init had some pretty horrid Error() << StringPrintf(...) calls that
are all much better replaced by Errorf(...) now.
Test: build, check that keyword_map errors look correct
Change-Id: I572588c7541b928c72ae1bf140b814acdef1cd60
This change is to support importing property file with its path
variations.
By substitute its filename with another, it can be used to handle
runtime varying filename within single binary.
Here's an example of usage in property defined file.
import /odm/build_${ro.boot.product.hardware.sku}.prop
Bug: 132592551
Test: boot a device and checks above example import statement in
"/odm/build.prop" loading expanded filename correctly
Change-Id: If3fdcf620a5d717e0930b1e4e58261bc8f79ec24
Ueventd can't set properties currently, but this is an artificial
limitation, since ueventd communicates to init that it has finished
cold boot via a file, and init polls this file instead of returning to
the epoll loop, where properties are handled.
This change replaces that file with a property and thus frees ueventd
to be able to set properties.
Bug: 62301678
Test: boot, check that properties are set
Change-Id: I985688e9299456efcb2dfeef9b92668991aa9c05
Now that Result<T> is actually expected<T, ...>, and the expected
proposal states expected<void, ...> as the way to indicate an expected
object that returns either successfully with no object or an error,
let's move init's Result<Success> to the preferred Result<void>.
Bug: 132145659
Test: boot, init unit tests
Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
This change fixes a bug that *.rc files in APEXes are not read when the
APEXes are flattened. This was because init used "/apex/*@*/etc/*.rc"
glob pattern to find the files, which gives 0 result with flattened
APEXes; with flattend APEXes /system/apex is just bind-mounted to /apex,
and therefore, the name@version directories don't exist.
Fixing the issue by globing /apex/*/etc/*.rc and filter-out the paths
with @ to avoid double parsing the *.rc files in case of non-flattend
APEXes.
Bug: 134067086
Test: revert I75ec6b69cca1cef071b50fac9a4cf8b8ceddb142
build sdk_gphone_x86_64 and record a video in the camera app.
The recording works. `ps -A | grep media.swcodec` shows media.swcodec process.
`atest CtsStatsdHostTestCases:android.cts.statsd.atom.UidAtomTests#testAudioState` passes
Test: build sdk_phone_x86_64 and do the same.
Change-Id: I00af1910a8e8a330addc4c6903e5f3695aeb6865
The Result, Error, ErrnoError are quite generic. Moving them from init
to libbase so that they can be used from other places.
Bug: 132145659
Test: libbase_test
Change-Id: Id774a587f74380fadd7a0fc88c0aa892c3d9a489
Factors out utility functions into service_utils.h/cpp, so that they
can be reused by the upcoming native zygote.
Bug: 133443795
Test: Build and boot cuttlefish.
Change-Id: I0531b6f17561119c8cc33dd9ba375b351747fcfe
This change factors out functions that handle selabels from
selinux.h/cpp into selabel.h/cpp. This allows util.cpp to be used by
the upcoming native zygote without a bunch of define flags that are
required for selinux.cpp.
Bug: 133443795
Test: Build and boot cuttlefish.
Change-Id: Ie238a96c6407c6698a605dd8803c1727abfaae7b
Currently, if init encounters a fatal issues it reboots to fastboot
but this may be not desirable in all cases, especially the case of
critical services crashing. Therefore this change adds the ability
for vendors to customize the reboot target via the
androidboot.init_fatal_reboot_target= kernel command line.
This applies to all LOG(FATAL) messages as well as fatal signals in
userdebug/eng builds, except for signals before logging is enabled in
first stage init.
Bug: 121006328
Test: device reboots to configurable target with LOG(FATAL)
Test: device reboots to configurable target after a segfault in the
various stages of init
Test: device reboots to fastboot without a configured target
Change-Id: I16ea9e32e2fee08dece3d33b697d7a08191d607b
Dump init stacks when aborting either due to LOG(FATAL) or in
userdebug/eng builds due to signals, including signals from
sanitizers.
Doesn't work for static first stage init yet, b/133450393 tracks
that.
Also, ensure that LOG(FATAL) in child processes calls abort() in all
stages of init, not just 2nd stage init.
Bug: 131747478
Test: abort init in various ways and see stacks
Test: hang or crash in backtrace handler and see child reboot
Change-Id: Ib53b5d3e7e814244203f875de016ada9900dfce8
When TARGET_FLATTEN_APEX is true (= ro.apex.updatable is unset or set to
false), apexd is not used to activate the built-in flattened APEXes.
Init simply bind-mounts /system/apex to /apex.
However, there is a special case here. The runtime APEX is installed as
either /system/apex/com.android.runtime.debug or
/system/apex/com.android.runtime.release, whereas it should be activated
on /apex/com.android.runtime - without the .debug or .release suffix.
To handle that case, the build system creates an empty directory
/system/apex/com.android.runtime and the .debug or .release directory
is bind-mounted to the empty directory by init at runtime.
This change also fixes a minor bug that native watchdog is triggered
for all post-apexd processes regardless of whether ro.apex.updatable
is true or not. Since apexd is expected to shutdown itself when ro.apex
.updatable is false, we don't trigger the watchdog in that case.
Bug: 132413565
Bug: 133305381
Test: marlin and sdk_gphone are bootable
Merged-In: I219465b8b81decb960e2c5f46bab6e0768b31317
Change-Id: I219465b8b81decb960e2c5f46bab6e0768b31317
(cherry picked from commit f93088ba2b)
Android-base has an implementation of the future std::expected<>.
This provides the same baseline functionality as Result<>, so use it
instead of our own version.
Bug: 132145659
Test: boot, init unit tests
Change-Id: I11e61bcb5719b262a6420483ed51a762826a9e23
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Change-Id: I0733c277baa67c549bb45599abb70aba13fbdbcf
Merged-In: I0733c277baa67c549bb45599abb70aba13fbdbcf
Importing rc files during mount_all was at best a stop gap until
Treble's first stage mount and at worst a bad idea. It doesn't have a
reason to exist now that first stage mount exists and is required, and
always had edge cases where init could not handle loading some aspects
of scripts after it had started processing actions.
This change removes this functionality for devices launching after Q.
Test: devices boot
Change-Id: I3181289572968637b884e150d36651f453d40362
This keyword was introduced to support restarting services on devices
using APEX and FDE. The current implementation is not a restart, but
rather a 'reset' followed by a 'start', because the real /data must be
mounted in-between those two actions. But we effectively want this to be
a restart, which means that we also want to start 'disabled' services
that were running at the time we called 'class_reset_post_data'.
To implement this, keep track of whether a service was running when its
class was reset at post-data, and start all those services.
Bug: 132592548
Test: manual testing on FDE Taimen
Change-Id: I1e81e2c8e0ab2782150073d74e50e4cd734af7b9
Merged-In: I1e81e2c8e0ab2782150073d74e50e4cd734af7b9
Device-mapper is required already, so drop the conditionals for trying to
load it. GetRootEntry() was depending on its existance, so this adds the
required dependency.
Bug: 131747478
Test: boot without any verity/avb/dm-linear devices.
Change-Id: Ifc89d3b338e2c2b8faaf1c24e2792c1eeb5bbbde
Add a property ro.boottime.init.first_stage to provide us a
first stage init duration from start to exec completed in
nanoseconds.
For consistency, report nanoseconds duration for
ro.boottime.init.selinux as well instead of milliseconds.
Now also report consistently from start to exec completed
instead of just the selinux load time.
SideEffects: ro.boottime.init.selinux is reported to TRON and
may alarm with the millionfold increase in precision.
ro.boottime.init is now also consistent with ns
precision.
Test: inspect
Bug: 124491153
Bug: 129780532
Change-Id: Iff4f1a3a1ab7ff0a309c278724c92da0832b9a69
Before, if updatable processes crash 4 times in 4mins, a native
rollback will be attempted. This behavior does not detect
system_server early boot deadlocks because the system server requires
at least a min to detect a deadlock, and crash itself. The crashes
don't happen frequently enough for init to detect.
After, this cl, the old behavior exists and additionally, init detects
*any* 4 crashes of updatable processes before boot completed,
regardless of if they happen within 4mins or not.
Test: Manually tested by adding artificial sleep in system_server so
deadlock is triggered before boot. system_server crashes 4 times in
over 4mins and the ro.init.updatable_crashing prop is set to 1.
Bug: 129597207
Change-Id: Ie6fb5693ff4be105bcbe139c22850fb076e40260
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
In order to prevent device stuck at reboot, we try to create shutdownt
monitor thread with a timeout (default 30s). It will dump init process
and blocked tasks call trace in last kmsg then trigger kernel panic to
reboot device.
Test: reboot device
bug: 128561401
Change-Id: Ieb400ab9fbd983544b61241a4f4b8aa2f4baa863
In the future, property service may run in its own thread or process,
which means that PropertyChildReap() needs to be refactored to not run
as part of the init signal handler.
The new method spawns a new thread that handles the queue of paths
that require restorecon. It then communicates back to property service
via android::base::SetProperty(). Property service distinguishes the
thread from other callers of SetProperty() by checking the pid in the
credentials for the socket connection, thus avoiding dependencies on
the rest of init.
The new method also drops the genericness, since restorecon is the
only function that we should ever need to run asynchronously
Test: async restorecon works, including with queued requests
Change-Id: I2ca00459969e77b1820776dac23d0a0d974e330b
The first stage init skips mounting the mount points defined in
skip_mount.cfg, but these mount points still return from
ReadDefaultFstab(). The behavior causes some error logic which
try to access the partition which had been skipped.
After applying the patch. ReadDefaultFstab() will not contain the
skipped mount points.
Bug: 128961335
Test: `fastboot delete-logical-partition product_a`
Test: `fastboot flash system aosp_arm64-userdebug`
Test: `fastboot -w reboot` and boot to home screen
Change-Id: I3156260b5d37647dbecf98ca90601a089bea5c46
Though unlikely, it is possible for getpeercon() to fail. This change
adds code to handle this case gracefully.
Bug: 130209483
Test: boots, properties are set
Change-Id: I3b3fb76b2312a5cbc87c0da2a044be3ddf8aa400
The setup of SelinuxAuditCallback() was happening after property files
are loaded, and now that these property files can trigger audits, the
audit messages did not contain all of the correct information. This
change moves the setup of SelinuxAuditCallback() to immediately before
the property area is initialized, to ensure that this can not happen
again.
Bug: 130979265
Test: audits work early
Change-Id: I9eb43269317c74e041626ee7b2bb7fea49250e09
The debug ramdisk can only be used if the device is unlocked.
When it's used, init will load adb_debug.prop and the userdebug
sepolicy from the debug ramdisk, to allow adb root on a user build.
Bug: 126493225
Test: 'make' and checks the file is installed
Change-Id: Id6962414197fc8f47f7c07818e8fb16107dc17a3
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
In previous implementation, userdebug sepoilcy and property files are
loaded from the system.img. This CL changes this to:
- first-stage init copies userdebug files from ramdisk to /debug_ramisk/*
- second-stage init loads files from /debug_ramdisk/*.
Note: same as before, the above can only be triggered, if the device
is UNLOCKED
With this, we don't have to put userdebug related files into the USER
system.img.
Bug: 126493225
Test: boot device with a ramdisk with /force_debuggable, checks related
files are loaded
Change-Id: I63f5f846e82ba78427062bf7615c26173878d8f3
right now vendor_init is forked before we set oom_adj for init which
leaves a chance vendor_init could be killed in heavy memory pressure.
this CL set the oom_adj before forking everything to ensure all native
have correct oom_adj settings.
Fixes: 130824864
Test: procrank -o
Change-Id: I8af129076c3efa29f7b781459449f8f2dc853c98
Remove an unimplemented function from the header and clean up some
slight syntax mistakes.
Test: build
Change-Id: Ia82c6aee24fa0889a7595aabc564bef970a0863b
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
This change allows specifying additional avb keys to verify a fstab
entry. It can be used together with the original 'avb' flag. When both
'avb' and 'avb_keys' are present, it will try to use avb_keys to verify
this partition and extract the AVB descriptor from the end of it first.
When avb_key fails, it falls back to searching the AVB descriptor in the
built-in /vbmeta (and its chained partitions) with the matched partition
name.
An example of a fstab file:
system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount,avb_keys=/avb/gsi.avbpubkey
vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
The overhead of adding an additional 'avb_keys' should not be significant,
as the typical size of a AVB Hashtree descriptor for /system is usually
less than 1000 bytes. e.g., on crosshatch, it's about 600 bytes, which
takes less than 1 millisecond for the following call to return failure.
auto avb_standalone_handle = AvbHandle::LoadAndVerifyVbmeta(*fstab_entry);
We also checked the time spent on init's first stage on crosshatch, with the
following CL to set ro.boottime.init.first_stage. The testing result
shows no significant difference between them as well.
https://android-review.googlesource.com/c/platform/system/core/+/934536
With an additional avb_keys entry for /system
[ro.boottime.init.first_stage]: [728]
[ro.boottime.init.first_stage]: [720]
[ro.boottime.init.first_stage]: [722]
Without an additional avb_keys entry for /system
[ro.boottime.init.first_stage]: [730]
[ro.boottime.init.first_stage]: [728]
[ro.boottime.init.first_stage]: [725]
Bug: 124491153
Test: boot a device with above fstab settings
Change-Id: I0c81f816efb0dd40c93da2df304f2e215df9d105
The purpose of having fine grain read/write control over the property
space is to help ensure the confidentiality of data stored in
properties. Leaking property values into the dmesg buffer on errors
exposes the value outside of the access control rules specified by
policy.
(arguably this is also true for the property name, not just the value.
However, property names are exposed in other places now, so the
incentive to fix this is lower. It would also take away a valuable
debugging tool.)
Test: compiles
Change-Id: I4a0634b8b5e4fd2edf718eaf7343940df627366d
Use CgroupController definition from libcgrouprc_format, not
libprocessgroup, because the wire format will be removed
from libprocessgroup later.
Bug: 123664216
Test: builds
Change-Id: If5e2301a1b65c3f6a51a1661cfeeed4e299f634e
Merged-In: If5e2301a1b65c3f6a51a1661cfeeed4e299f634e
Only init uses SetupCgroups. This functionality is
moved from libprocessgroup to its own library, and only
init links to it.
Also, merge CgroupSetupCgroups() with CgroupMap::SetupCgroups()
because the former is just an alias of the latter, and
CgroupMap does not belong to libcgrouprc_setup.
Test: boots
Bug: 123664216
Change-Id: I941dc0c415e2b22ae663d43e30dc7a464687325e
Merged-In: I941dc0c415e2b22ae663d43e30dc7a464687325e
Since DM_NAME= is not sent (delete bug) or interpreted with ueventd
message, instead probe /sys/devices/virtual/block/dm-X/dm/name when
instantiating. Cache the value for later delete.
By creating the /dev/block/mapper/<name> nodes, this will give
selabel_lookup_best_match an alias to hang its hat on so that the
associated /dev/block/dm-X nodes will be suitably labelled and
differentiated.
NB: For Android, the deletion of the nodes will only happen in the
context of fastbootd, update_engine and gsid; otherwise the links
and properties created can be considered set-once and persistent.
Test: manual inspect /dev/block/mapper/ links
Bug: 124072565
Change-Id: I6d9e467970dfdad7b67754ad61084964251eb05f
This catches a common mistake where client code checks for errors using
the common idiom that works for std::iostream and other file-like
classes:
unique_fd fd = open(...);
if (!fd) {
}
Test: atest libbase_test
Test: m droid
Change-Id: I9629a7795537ecb3b57be9c741c06f80967e4cc2
SetupCgroups is called by init process during early-init stage and is not
supposed to be called again by anyone else. Ensure that the caller is the
init process, make sure cgroup.rc file is written only one time, keep the
file descriptor to cgroup.rc file open by the init process to ensure all
its further mappings stay valid even if the file is deleted.
Bug: 124774415
Test: build, run, verify no errors or warning in the logcat
Change-Id: Ib8822cf0112db7744e28d442182d54dcf06f46f2
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
On marlin, dev.mnt.blk.root is empty. Issue is shared for all
devices that are system-as-root.
/dev/root /proc/mounts entry exists before the associated block device
is instantiated by ueventd. As a result when the device shows up the
root mount is updated late when the next mount inotify trigger occurs,
delay which we will accept. But the property entries are added before
removed in the loop which causes the ultimate property entry for root
to report empty. Add /dev/block/dm-0, remove /dev/root, for property
dev.mnt.blk.root.
Fix is to change to Remove before Adding. Remove /dev/root, then add
/dev/block/dm-0.
On system-as-root as well, can not just use fstab. Determine if a
dm-verity reference is wrapped around system and use that instead.
Add some additional filtration of loop and APEX mounts to reduce
property noise.
Fix issue with creating the std:string line holder from getline(3).
Test: manual on marlin
Bug: 124072565
Change-Id: Ief2e1a6f559cbcbc87273fc2db35c675bb972f43
* changes:
libbase: realpath is wrapped with TEMP_FAILURE_RETRY
liblp: Replace open with GetControlFileOrOpen
init: expand prop in 'file'
libcutils: android_get_control_file uses realpath.
Allow having properties in 'file' option of a service.
Test: boots (sanity)
Test: lpdumpd
Bug: 126233777
Change-Id: I55158b81e3829b393a9725fd8f09200690d0230f
Bug: 126230649
Bug: 127953521
Test: GSI boots when installed to sdcard on hikey960
GSI boots when installed to /data/gsi
Change-Id: Id59926ebe363939c8c5745bb1bf5bd13722dae7e
If the required_devices_partition_names is cleared, no need to Poll.
Test: manual check boot time, and adb-remount-test.sh
Bug: 128834849
Change-Id: I044ee2752a7f32b084ff6e88b4b586accdfb78f0
Set properties dev.mnt.blk.<mount_point>=<device_block_class> for mount
and umount operations by setting up an Epoll handler to catch
EPOLLERR or EPOLLPRI signals when /proc/mounts is changed. Only
update properties associated with block devices. For the mount
point of /, use the designation of /root instead.
Can use the properties in init rc expansion like:
on property dev.mnt.blk.root=*
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${boot_read_ahead_kb:-2048}
on property dev.mnt.blk.data=*
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${boot_read_ahead_kb:-2048}
on late-fs
setprop boot_read_ahead_kb 128
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${boot_read_ahead_kb}
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${boot_read_ahead_kb}
Test: boot and inspect getprop results.
Bug: 124072565
Change-Id: I1b8aff44f922ba372cd926de2919c215c40ee874
When init found "/force_debuggable" in the first-stage ramdisk, it will
do the following if the device is unlocked:
1. load /system/etc/adb_debug.prop (with ro.debuggable=1)
2 .load userdebug_plat_sepolicy.cil instead of original plat_sepolicy.cil from
/system/etc/selinux/.
This make it possible to run VTS on a USER build GSI, by using a special
ramdisk containing "/force_debuggable".
Bug: 126493225
Test: unlock a USER build device, check 'adb root' can work
Change-Id: I9b4317bac1ce92f2c0baa67c83d4b12deba62c92
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
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
In the current setup, init uses the highest policy version supported
by the kernel, instead of the policy version defined in policy. This
results in inconsistency between precompiled (version 30) and
on-device compiled policy (version 30 or 31). Make these consistent.
Bug: 124499219
Test: build and boot a device. Try both precompiled and on-device
compiled policy.
Change-Id: I0ce181916f43db17244c4d80f5cf5a91bbb58d3a
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
Follow up to the change made for AVB2 devices in
I19371b05912240480dc50864a2c04131258a7103.
The same consideration must be made in the fall through case, which
is taken either if AVB is completely disabled, or the dm-verity / AVB1
mechanism is used.
Bug: 113175337
Test: boot test on cuttlefish
Change-Id: I99d46a2c2630c40f5f5c02279b11e423998a1e05
init doesn't cooperate with execute-only memory just yet, so disable it
until we can determine the root cause.
Bug: 77958880
Test: Device boots.
Change-Id: Ieb78315ba1e48c9cd0d047a42951bd3fbd36641b
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
With the addition of the /dev/block/by-name/ symlinks created for the
boot_device, we no longer need to use a map to track the symlinks for
the partitions AVB needs to access.
This will help us in removing the requirement to specify which
partitions contain AVB metadata.
Bug: 117933812
Test: boot blueline_mainline with AVB
Change-Id: I1d46dba5b2fc16b2a14f861b34225ac0f2995b60
The first split of 1st/2nd stage init went a bit overboard, since it
split these even in the case of the recovery image and system-as-root,
which don't actually need the split. This change simplifies this a
bit:
system-as-root and recovery have a single combined /system/bin/init
and a symlink from /init to it.
non-system-as-root has a separate first stage init at /init on the
first stage ramdisk and a combined /system/bin/init on system.img.
Two particular benefits from this:
1) Removal of the rsync of TARGET_RAMDISK_OUT to the recovery image
2) Decrease of overall space on the recovery image since it won't have
a statically linked first stage init
This also unified the various entry points of init to depend entirely
on the arguments passed to it, instead of the hybrid of arguments and
environment variable used previously.
Bug: 80395578
Test: boot both system-as-root and non-system-as-root
Change-Id: Ic2f29b6f56b7defc80eaa0e7cd0c9107e978816f
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
The following message creates unnecessary alarm:
init: Partition system_a already existed in the by-name symlink map \
with a value of \
/dev/block/platform/soc/1d84000.ufshc/by-name/system_a, new value \
/dev/block/platform/soc/1d84000.ufshc/by-name/system_a will be \
ignored.
and in the code is cited as an ERROR. The message admittedly does
point out an inefficiency by reporting multiple updates.
Test: compile
Change-Id: I388a76fa078cf9de5840930247f732d16ccb0719
When using the recovery image as a trampoline to boot the system,
first chroot from the recovery image to /first_stage_ramdisk, to
minimize differences between these two boot paths.
Primary motivation is due to the fact that the basename of each mount
point is used by device-manager to name its nodes, and the previous
code that created used /system_recovery_mount as the mount point for
system.img broke AVB. Instead of hacking around that issue, this
change unified mounting for the recovery trampoline and true first
stage ramdisk paths.
Change when relanding: the original change skipped the move mount from
/first_stage_ramdisk to / and only did a chroot instead. This was a
mistake that resulted in the subsequent move mount of /system to / to
mount over the '/' directory instead of moving that mount. This
change uses a bind mount of /first_stage_ramdisk to itself instead of
skipping the first move mount.
Bug: 114062208
Test: AVB works with blueline_mainline
Change-Id: I65207edfe98531892da2eafcbff19b438c9c64fe
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
This reverts commit 56999b41af.
Reason for revert: Something is broken here; we're not switching to /system properly.
Change-Id: I777fedcfb545c11275c9cc12f99b99a2423959a0
When using the recovery image as a trampoline to boot the system,
first chroot from the recovery image to /first_stage_ramdisk, to
minimize differences between these two boot paths.
Primary motivation is due to the fact that the basename of each mount
point is used by device-manager to name its nodes, and the previous
code that created used /system_recovery_mount as the mount point for
system.img broke AVB. Instead of hacking around that issue, this
change unified mounting for the recovery trampoline and true first
stage ramdisk paths.
Bug: 114062208
Test: AVB works with blueline_mainline
Change-Id: Iffb154962b6e160150917e068f1e7d0bf7cb84e7
This patch adds another uevent-regeneration pass to the first stage
mount. When the super partition spans multiple block devices, we need
/dev/block/by-name symlinks to have been created before we begin mapping
dynamic partitions.
Bug: 116802789
Test: retrofit device boots
Change-Id: I00bb277e1d81385a457c5b4205a95d8fbe365bb2
We need to do restorecon after the cold boot, otherwise the newly
created sysfs nodes won't be labelled.
Bug: 118861992
Test: manual - do insmod, check sysfs nodes are properly labelled
Change-Id: I4bdfb4a68206724a568d8cbb6c644ba8764b5fa7
Current hwasan implementation breaks when stderr (fd 2) is missing.
Bug: 118776698
Test: hwasan boots without serial console
Change-Id: Id095a87212096526a497563adab3d7f2f9fe8ab0
Using overlayfs, the system partition may provide files for older
version of vendor partitions by overlaying on the vendor partition.
Directories in /system/vendor_overlay will be overlaid on the
directories in /vendor to override existing files or provide new
files.
This feature works only if the kernel support overlayfs and has a
patch for override_creds. Otherwise, no-op.
Bug: 114679254
Test: Build and boot: nothing affected without overlayfs, or
vendor file is overrided with overlayfs
Change-Id: Iff3a308945299034123ba7bcb40dc787e102730e
The memcg.limit_percent option can be used to limit the cgroup's
max RSS to the given value as a percentage of the device's physical
memory. The memcg.limit_property option specifies the name of a
property that can be used to control the cgroup's max RSS. These
new options correspond to the arguments to the limitProcessMemory
function in frameworks/av/media/libmedia/MediaUtils.cpp; this will
allow us to add these options to the rc files for the programs that
call this function and then remove the callers in a later change.
There is also a change in semantics: the memcg.* options now have
an effect on all devices which support memory cgroups, not just
those with ro.config.low_ram or ro.config.per_app_memcg set to true.
This change also brings the semantics in line with the documentation,
so it looks like the previous semantics were unintentional.
Change-Id: I9495826de6e477b952e23866743b5fa600adcacb
Bug: 118642754
Found the following 2 binary is not in the path
system/core/init/grab-bootchart.sh: line 20: bootchart: command not found
system/core/init/grab-bootchart.sh: line 21: gnome-open: command not found
Use a more commonly available command to create bootchart
Test: system/core/init/grab-bootchart.sh started a bootchart
successfully
Change-Id: I6d5b4a692af2fd53ea636b768f55c697586e6898
If a section header such as 'on' or 'service' has an error with it,
the rest of the commands / options are currently reported as errors
since there is no valid parser object to parse them. For example,
service !@#$%%^&*() /system/bin/false
user root
group blah
blah blah
Generates:
init: /system/etc/init/bad.rc: 2: invalid service name '!@#$%%^&*()'
init: /system/etc/init/bad.rc: 3: Invalid section keyword found
init: /system/etc/init/bad.rc: 4: Invalid section keyword found
init: /system/etc/init/bad.rc: 5: Invalid section keyword found
This change suppresses the extraneous 'Invalid section keyword found'
messages.
Test: faulty error messages are suppressed.
Change-Id: Ieeb2d5b8b7eea33e191a88ce5a0d41701686943f
Partial revert of "init: if vendor_init can read a property, let it be
a trigger too" (b35f827c97).
We made a mistake when we allowed vendor init to action on any vendor
or odm property, since when a new SELinux label is created for a
vendor property, vendor_init does not automatically get read
permissions for it.
Recently, we tried to use read permissions instead of the built-in
list in init, but that broke due to the above mistaken. Since we have
already launched with these permissions as is, we must restore them.
Bug: 118457755
Test: no denials for vendor init actionable properties on crosshatch
Change-Id: I7a9a560c9a54a177c6b83d28309e2f288f05d400
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
There is a list of 'stable_properties' that vendor_init can use as
property triggers for Treble property compliance. This list came about
since init parses init scripts before all partitions are mounted and
therefore before all property context files are available, such that
init cannot use the normal SELinux mechanisms for determining if a
given property is vendor_init readable.
Currently though, we require all partitions that would contain
property context files to be mounted during first stage mount, so we
can use the normal SELinux mechanisms here, so this change deprecates
the stable_properties list and moves init to use SELinux to determine
if a property can be a trigger.
Bug: 71814576
Test: vendor_init fails to use non-readable properties as a trigger
Test: vendor_init successfully uses readable properties as a trigger
Change-Id: I6a914e8c212a3418cbf4a8a07215056aad2e0162
Init is special.
It starts early and does not pick up the Android ASAN options provided
on the environment. Therefore we pull in /system/asan.options in
explicitly if it exists. We provide sane defaults that will allow the
system to boot otherwise.
Logging is complicated because it needs to go to the kernel log.
So use sanitizer functions to install log functions.
Bug: 117879229
Test: m && m SANITIZE_TARGET=address
Test: init boots with ASAN enabled
Change-Id: I72c033a1f86ba5d6b2e4f943e7a3acd0d399c8bf
Bug: 117828597
Test: bugreport launches with a test property set to appropriate keys
Test: bugreport doesn't launch with the test property unset
Test: no errors seen in build or boot in either of the above cases
Change-Id: Iea27032080a0a7863932b1c1b573857ac66b56b5
ParseLineSection() provides 'args' as an rvalue reference, so its
callers can and should use it as such. This saves some copying
overhead and cleans up the code a bit.
Test: boot
Change-Id: Ib906318583dc81de9ea585f5f09fdff35403be1b
With system-as-root, both first and second stage init belong to
system, but without system-as-root, first stage belongs to vendor and
second stage belongs to system. This change creates two phony
packages to achieve this correctly in the build system.
Bug: 117606184
Test: mainline builds work properly
Change-Id: I19263e76c217c2e70bc06c180be3a460e9144f18
'Critical' services have rebooted into bootloader, like all other
catastrophic init crashes, for years now. Update the text to match.
Test: n/a
Change-Id: Icfc41bf3e383958f14ecfaab9ca187e2c3dc7fd9
This keyword can (and should) be used multiple times when multiple
services are served together. I've documented this here.
Bug: N/A
Test: N/A
Change-Id: Ie986c9cac486db346555f359e9ccbed93d8d1d22
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
Vendor might want to pause/resume some operations while a bugreport is captured
so that we need to export dumpstatez into stable_properties.h for vendor to get
property event when dumpstatez launch.
Test: confirmed manually with "adb bugreport"
Bug: 117536084
Change-Id: Ib743c5e59ca20cc44470110c814d85e4cbb90c0c
Signed-off-by: Minchan Kim <minchan@google.com>
1) increase thermal shutdown timeout to 3s for process to save work
2) respect property "ro.build.shutdown_timeout" in thermal shutdown if
it is set less than default time - "3s"
Bug: 112432890
Test: Build
Change-Id: Idc2b24dd44c1fab8f9b047fd2468de2ee45ff783
The kernel opens /dev/console and uses that fd for stdin/stdout/stderr
if there is a serial console enabled and no initramfs, otherwise it
does not provide any fds for stdin/stdout/stderr. InitKernelLogging()
is used to close these existing fds if they exist and replace them
with /dev/null.
Currently, InitKernelLogging() is only called in second stage init,
which means that processes exec'ed from first stage init will inherit
the kernel provided fds if any are provided.
In the case that they are provided, the exec of second stage init
causes an SELinux denial as it does not have access to /dev/console.
In the case that they are not provided, exec of any further process is
potentially dangerous as the first fd's opened by that process will
take the stdin/stdout/stderr fileno's, which can cause issues if
printf(), etc is then used by that process.
Lastly, simply moving InitKernelLogging() to first stage init is not
enough, since first stage init still runs in kernel context and future
child processes will not have permissions to access kernel context
resources. Therefore, it must be done for a second time in second
stage init.
Bug: 117281017
Test: no audits when booting marlin.
Change-Id: If27edab5c32b27765e24c32fbed506ef625889de
Allow services to specify a custom restart period via the
restart_period service option. This will allow services to be run
periodically, such as a service that needs to run every hour.
Allow services to specify a timeout period via the timeout_period
service option. This will allow services to be killed after the
timeout expires if they are still running. This can be combined with
restart_period for creating period services.
Test: test app restarts every minute
Change-Id: Iad017820f9a602f9826104fb8cafc91bfb4b28d6
Added fs_mgr_overlayfs_required_devices() as hint to init to make sure
the device gets created before fs_mgr_overlayfs_mount_all().
Test: manual
Bug: 109821005
Change-Id: Iab038f3e0252a357b082bb08db3679512b9badec
We ran into an issue with an fd leaking due to missing both CLO_EXEC
and fclose() in related code, so let's make sure we're safe here too.
Test: boot
Change-Id: Ief893c936859815c78fa6d7e06cb88ad34aadbac
If a device has logical partitions but does not use a partition called
"super", we will need this to be configurable. Note that the "slot"
argument is currently unused, but will be necessary for update_engine if
there are A and B super partitions.
Bug: 116608795
Test: super partition works
Change-Id: Ieb548a158faeb423f3561230f26d582325efbc6b
We need to keep the right mount points in the fstab for other
processes to access (/ for system-as-root or /system otherwise).
Force_normal_boot devices are defacto not system-as-root,
since they're booting through the recovery ramdisk and therefore must
use /system as the system mount point.
Bug: 114062208
Test: boot pixel from recovery with force_normal_boot
Change-Id: Ib0e4e4f8a29299ecdcd35e8f1415551c4c9745ad
Device is considered to be unlocked if
androidboot.verifiedbootstate is "orange".
Test: adb shell getprop ro.boot.flash.locked
Change-Id: Id3aeec757908ea63a37e28ad880a6c71d53083ac
