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
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
