As part of debugging long run issue we are enabling
module info as part of debug build under the config key
DEBUG_MODULE_LOAD_INFO , But doing so can lead to info leak
as modules/dlkm are loaded in early-init and setting the
kptr_restriction is done after early-init.
So moving setting of kptr_restrict much before early-init.
Bug: 138641073
Change-Id: Ic3c0ca57a94c8b20136a15331dd646bd8825b625
generate subdir for /sys and /sys/devices, handle restorecon in parallel.
This reduces coldboot time on our target about 300ms.
Change-Id: I9c3d0e97aacff0ca127880d936dfd5fcc2aee125
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.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I13b8bf240c9fcb1d2d5890a8be2f0ef74efd4adf
Use lstat(), and then make only the system calls needed to fix the
directory up.
Bug: 140027478
Test: boots twice, no worrying log messages.
Change-Id: I1c1445baae3ec1c1ce17626ede388aa04d5f7781
Note that /metadata must now be mounted before CreateLogicalPartitions()
is called. This is because SnapshotManager overrides the default
partitioning scheme, and the only way to tell if a SnapshotManager is
needed is via the metadata partition.
Bug: 139204329
Test: manual test
Change-Id: I812df6c4c0d4d8753b1516f63dc70c5bc3e1c09c
Before ImageManager was introduced, gsid avoided using PartitionOpener
when writing to external media. PartitionOpener couldn't interact with
non-boot devices, because it prepends /dev/block/by-name. We hacked
around this in both gsid and in first-stage init, which manually detects
the problem and prepends /dev/block instead.
After the ImageManager refactoring, sdcard support broke in gsid,
because it started relying on PartitionOpener. Let's fix this by allowing
/dev/block for mmcblk* names in PartitionOpener.
Bug: 139204329
Test: fiemap_image_test gtest
Change-Id: Ic1cbdbe0a18fc09522ee38cc62b35fd8193ce250
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.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: Id9534a5916abb2f7d2a49cda54e33c1b69c50c2f
host_init_verifier statically links libprocessgroup, which has shared
dependency on libjsoncpp. Right now it also has shared dependency on
libjsoncpp, resulting in ODR violation:
ERROR: AddressSanitizer: odr-violation (0x7fce895f3220):
[1] size=8 'Json::kNullRef' external/jsoncpp/src/lib_json/json_value.cpp:37:22
[2] size=8 'Json::kNullRef' external/jsoncpp/src/lib_json/json_value.cpp:37:22
These globals were registered at these points:
[1]:
#0 0x56276926ef0d (/usr/local/google/buildbot/src/android/master/out/host/linux-x86/bin/host_init_verifier+0xd1f0d)
#1 0x7fce894ac1d9 (/lib64/ld-linux-x86-64.so.2+0x101d9)
[2]:
#0 0x56276926ef0d (/usr/local/google/buildbot/src/android/master/out/host/linux-x86/bin/host_init_verifier+0xd1f0d)
#1 0x7fce894ac1d9 (/lib64/ld-linux-x86-64.so.2+0x101d9)
Move host_init_verifier to libjsoncpp_headers to fix the ODR violation.
Bug: 139546461
Bug: 131328001
Test: Run ASAN host_init_verifier
Change-Id: I54a51138d61fff37f092ffaa0758817600a0af9d
When we have a property match along with an event trigger, we
currently don't allow matching empty property values, in other words,
properties that are unset. For example, the below trigger would never
be run:
on zygote-start && property:persist.sys.fuse=""
That doesn't make sense though, it should be possible to match an
empty property value, so this change allows that trigger to match when
persist.sys.fuse is either empty or not set.
This continues to not match a '*' to an empty property, so
on zygote-start && property:persist.sys.fuse=*
will not run if persist.sys.fuse is empty or unset.
Test: the above triggers run appropriately
Change-Id: Ia57de7b96ad352590d0c82ff4ae95060b7361976
Includes refactoring out interface inheritance hierarchy logic to a new
interface_utils file.
Bug: 137397100
Test: 'm' with an init_rc that misspells an interface in an
interface_start, interface_restart, or interface_stop line.
Change-Id: I9f650289d64ae2b13435a81e1693c7ab5e6e9ecf
* changes:
Adds new property for service name -> PID.
Adds a library to parse service info from init_rc files for use in tests.
Adds a visibility rule for init defaults.
Host init verifier already checks that the names and number of
arguments for builtins are correct, but it can check more. This
change ensures that property expansions are well formed, and that
arguments that can be parsed on the host are correct. For example it
checks that UIDs and GIDs exist, that numerical values can be parsed,
and that rlimit strings are correct.
Test: build
Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
It's better to pass the error message to the caller to determine how
best to print the error.
Test: build
Change-Id: Id8857c459df2f26c031650166609608d20e4d051
Previously we were ignoring ENOENT from all builtins as
rootdir/init.rc has many legacy commands that we need to keep for
backwards compatibility, but are otherwise no longer relevant.
However, this wasn't catching actual issues, for example chown failing
due to not finding the user or group name. This change therefore
reduces the scope of ignoring ENOENT to the only the extraneous errors
in builtins.
Test: boot CF and walleye without seeing errors from init.rc
Test: see errors from invalid users/groups in chown
Change-Id: Ia8e14fa2591e083cb1736c313a3e55515bc5d15e
It is exceedingly difficult to debug I/O and filesystem corruption
issues during first and selinux initialization stage init. By
redirecting stderr, and for good measure stdout, to /dev/kmsg in
first stage init before it exec's "/system/bin/init" we can see
the filesystem corruption errors more clearly.
Before this we would see:
init: Skipped setting INIT_AVB_VERSION (not in recovery mode)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x...
and then wonder why?
After this change we can see:
init: Skipped setting INIT_AVB_VERSION (not in recovery mode)
libc: Fatal signal 5 (SIGTRAP), code 128 (SI_KERNEL), fault addr...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x...
-or-
init: Skipped setting INIT_AVB_VERSION (not in recovery mode)
linker: CANNOT LINK EXECUTABLE "/system/bin/init": cannot locate symbol...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x...
(NB: with stutter removed because of stdout and stderr)
Silence from these sources otherwise on successful execution.
Test: boot
Bug: 138459777
Change-Id: I4200b24baeaa6e408a5e0a2c890561bda1e2f1f4
I've heard that keyword_map is too complex, in particular the tuple
and the pair in BuiltinFunctionMap, so this change removes a lot of
that complexity and, more importantly, better documents how all of
this works.
Test: boot, init unit tests
Change-Id: I74e5f9de7f2ec524cb6127bb9da2956b5f307f56
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
Steven Moreland