The android-4.14-stable and later kernels support the
FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY ioctls. This
has superseded the old way of adding fscrypt keys to the kernel, which
was to use the add_key() syscall to add keys to the "session" keyring.
On kernels that support the ioctls, Android doesn't use the obsolete
way. Since upgrading even just to Android 14 requires at minimum a
android-4.14-stable kernel (according to
https://source.android.com/docs/core/architecture/kernel/android-common#compatibility-matrix),
there is no need to support the obsolete way anymore.
Therefore, this commit removes the code from init that created a keyring
named "fscrypt" in the session keyring. It also removes the code that
created the session keyring itself, since the only reason that Android
even created a session keyring was just to hold the "fscrypt" keyring.
Flag: N/A for the following reasons:
- Removing obsolete code, which is fairly safe
- Very early code, so runtime flag cannot be used
- Even a build-time flag cannot be used, since init needs
recovery_available, which aconfig libraries do not support
Bug: 311736104
Test: Build and boot Cuttlefish
Change-Id: Id9a184c68cf16d5c4b1d889444cf637c95a91413
The macros isn't used anywhere but was a distraction when tracking down
/data mounting behaviour.
Test: build
Change-Id: Ie23574326cbebd7f515c8409e1dcb91a00cafc6f
do_start() ignores ENOENT intentionally to avoid logspam. It's
implemented in ErrorIgnoreEnoent. However, without resetting errno,
ErrorIgnoreEnoent will ignore unrelated errors from Service::Start() due
to the sticking errono set from other commands.
Bug: 296821716
Test: launch_cvd
Change-Id: I71d3113bdb69bdca82e2ff4f3a793301749f6c08
ServiceList's services_update_finished flag was overlapped with the
global flag: is_default_mount_namespace_ready. Now DelayService() relies
on the is_default_mount_namespace_ready flag.
Add a service description with 'updatable' flag and invoke 'start
<name>' in 'on init' block (which comes before APEX activation).
See the log for "Cannot start an updatable service".
Bug: 293535323
Test: see the comment
Change-Id: I9341ba1a95d9b3b7c6081b530850d61f105f0a56
create_apex_data_dirs() now uses GetApexListFrom(dir) in
apex_init_util.cpp.
This is essentially a refactoring, but there are a few behavioral
changes, which I think make more sense.
- Emits no error when opendir(/apex) fails.
- Emits errors when mkdir fails for each apex.
- Does not abort `perform_apex_config` even though create_apex_data_dirs
fails.
Bug: 293546778
Test: check /data/misc/apexdata/ after boot
Change-Id: I9d1a9710a6a626eec087c8c0fb1768667ffb036e
Reading .rc files from bootstrap APEXes causes "double loading".
This works for services because init just ignores duplicates. But it
emits error logs, which can mislead even though there's no actual
errors. Besides, for actions, duplicates can cause a problem when
commands are not idempotent.
So, when loading RC files from APEXes for the second time, we'd better
skip those bootstrap APEXes.
Bug: 290148081
Test: VendorApexHostTestCases
Change-Id: Ia630dbd14046064b5e5c612c01ebacf57091c8d4
To start an early_hal service from a bootstrap vendor apex, init now
reads .rc files from bootstrap apexes as well.
In this change, perform_apex_config command is re-purposed to support
bootstrap mode. Now we have some similarity between two apexd calls:
- for bootstrap apexes (in the bootstrap mount namespace):
exec_start apexd-bootstrap
perform_apex_config --bootstrap
- for normal apexes (in the default mount namespace):
restart apexd
...
wait_for_prop apexd.status activated
perform_apex_config
Note that some tasks in perform_apex_config are not needed in the
bootstrap. For example, we don't need to create apexdata directories
for bootstrap apexes.
Bug: 290148081
Test: VendorApexHostTestCases
Change-Id: I8f683a4dcd7cd9a2466a4b1b417d84c025c37761
This new directory is bind-mounted to /apex in the bootstrap mount
namespace so that apexd-bootstrap mounts bootstrap APEXes there via
/apex.
The directory is detached from /apex in the default mount namespace but
still visible in case bootstrap APEXes are needed.
However, there are (mostly, virtual) devices which don't need two mount
namespaces. Those devices don't need to make /bootstrap-apex directory
at all.
Bug: 290148078
Test: atest VendorApexHostTestCases
Test: atest MicrodroidTests
Change-Id: I541cec71d9970b14971d46e01e4808b23590dbed
MarkServicesUpdate() starts delayed services which are mostly for
APEXes. (e.g. start a service from APEX). But before
"DefaultNamespaceReady", services are started in "bootstrap" mount
namespace, which makes services from non-bootstrap APEXes fail to start.
This is a quick fix for the problem before coming up with better
solution in the future.
Bug: 293535323
Test: add 'start adbd' before 'perform_apex_config' in init.rc
adbd starts successfully.
Change-Id: I846689f7c38cdca83c1f7faec0106b8174527e09
Combine some cases that are handled identically, and remove the
'userdata_remount' parameter which is unused. No change in behavior.
Test: presubmit
Change-Id: I0567e47d02942af7865c155dab76e6d0e9d71a1f
Make the code that creates BuiltinArguments instances easier to read by
using initializer lists instead of constructor calls. Remove the
BuiltinArguments constructors.
Change-Id: I6cf215a81d298cf7e524e22fb75db820e0225c9a
Signed-off-by: Bart Van Assche <bvanassche@google.com>
From the unique_fd.h header file: "unique_fd's operator int is
dangerous, but we have way too much code that depends on it, so make
this opt-in at first."
From the Google C++ style guide: "Do not define implicit conversions."
See also go/cstyle#Implicit_Conversions.
Hence this CL that disables unique_fd::operator int().
Change-Id: I28d94755d5408f63e5819da8d1cbc285057f867f
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Allow us to check if check_at_most_once is set for any partitions.
This property should be false for any device with a reasonable amount of
RAM and a modern CPU. Enabling check_at_most_once violates AVB best
practices, it should only be allowed on performance limited devices.
Bug: 253033920
Test: Ensure that avbHashtreeNotUsingSha1 CTS test still passes
and that partition.system.verified.check_at_most_once is set.
Change-Id: I8174adf81111cc0df547ea01f81b0dfaca32631f
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Now that emulated FBE is no longer supported, there is no longer any
distinction between native FBE and emulated FBE. There is just FBE.
Referring to FBE as "fscrypt" is also poor practice, as fscrypt (the
Linux kernel support for filesystem-level encryption) is just one part
of FBE, the Android feature.
Therefore, rename fscrypt_is_native() to IsFbeEnabled().
Bug: 232458753
Change-Id: Ib4dcdf799833b91d326b4b6f7120b0a3d4f4fc31
APEX configs have supported only 'service' definitions. For those
services relying on 'on' trigger actions, we had to have separate config
files installed in read-only partitions (e.g. /system/etc/init).
This was suboptimal because even though APEXes are updatable, read-only
partitions are not.
Now, 'on' is supported in APEX configs. Putting 'on' trigger actions
near to service definitions makes APEX more self-contained.
'on' trigger actions loaded from APEX configs are not sticky. So, events
happens before loading APEX configs can't trigger actions. For example,
'post-fs-data' is where APEX configs are loaded for now, so 'on
post-fs-data' in APEX configs can't be triggerd.
Bug: 202731768
Test: atest CtsInitTestCases
Change-Id: I5a01d9c7c57b07955b829d6cc157e7f0c91166f9
Includes extracting the APEX-specific SDK version naming scheme filter
logic so it can be reused when host_apex_verifier looks at rc files
inside the APEX.
Bug: 222121216
Test: Use in host_apex_verifier
Change-Id: I0396a455f30d2de71525ccd3fa69c75576054048
This change provide a specialization of android::base::OkOrFail for
status_t. As a result, a statement whose type is status_t can be used
with OR_RETURN.
The specialization also provides conversion operators to Result<T,
StatusT> where StatusT is a wrapper type for status_t. This allows
OR_RETURN macro to be used in newer functions that returns Result<T,
StatusT>.
Example usage:
\#include <utils/ErrorsMacros.h>
status_t legacy_inner();
status_t legacy_outer() {
OR_RETURN(legacy_inner());
return OK;
}
Result<T, StatusT> new_outer() {
OR_RETURN(legacy_inner()); // the same macro
return T{...};
}
Bug: 209929099
Test: atest libutils_test
Change-Id: I0def0e84ce3f0c4ff6d508c202bd51902dfc9618
They are changed to template classes. s/Error/Error<>/g to reflect that.
In addition, the direct uses of ResultError for error reporting is
replaced with Error and Errorf.
Bug: 209929099
Test: m
Change-Id: I815526a8e6fa30e63fa3efcf5700b146bf70a507
If surfaceflinger crashes before zygote starts, it will restart zygote
too early. Add this argument will allow it to only restart zygote if
it's already running.
Bug: 197224273
Test: manual test
Change-Id: I0ac8dbeaf0a002f8cfcfcc0f63d4b90d08393c5c
class_restart accidentally restarts disabled services. Changing this
behavior is risky as it could break compatibility. Instead, add an
"--only-enabled" argument to class_restart to opt-in to the new
functionality. This syntax is backward compatible, as previously only a
1-argument form was accepted.
Bug: 190065372
Bug: 198105685
Test: add a class_restart action and a disabled service, make sure
service is not restarted.
Change-Id: Idb08779de7ac7a21e23f8b8a3276bd5a66a43299
Remove the class_start_post_data and class_reset_post_data commands,
since they aren't used anymore. They were only used on devices that
used FDE (Full Disk Encryption), via actions in rootdir/init.rc. These
actions have been removed, since support for FDE has been removed.
There is no use case for these commands in vendor init scripts either.
Keep the mark_post_data command, since DoUserspaceReboot() uses the
post-data service flag even on non-FDE devices.
Bug: 191796797
Change-Id: Ibcd97543daa724feb610546b5fc2a0dd7f1e62e7
Support an "init.#rc" versioning scheme for apex init files.
chooses highest # <= current system sdk.
".rc" (aka the old init.rc) is treated as sdk 0
Document these semantics in README.md
Bug: 198186200
Test: booting, lots of logcat output
Change-Id: I2d0405be73dae9bafa6f22535b29ed6b053ddbc4
It's requested by the partner engineering team to uniquely
identify a partition.
Bug: 197973981
Test: boot the device and check props
Change-Id: I0f7aa34dd0087f0698fe90b9df6c0eae06fc4f5d
Also the check that linker configuration should not be updated if APEX
is in updatable state, is removed as now with refactoring of code and its
movement to apex project, that is also needed.
Resolves: https://b.corp.google.com/issues/192838499
Test: Run the AVD Device and check that it boots and run atest
ApexTestCases
Change-Id: I80a94fa0a4145d30546bb34a6d478a20a2881368
Any service which is executed when Runtime apex is mounted, but
linkerconfig is not updated can fail to be executed due to missing
information in ld.config.txt. This change updates init to have a status
variable which contains if current mount namespace is default
and APEX is not ready from ld.config.txt, and use bootstrap namespace if
it is not ready.
Bug: 181348374
Test: cuttlefish boot succeeded
Change-Id: Ia574b1fad2110d4e68586680dacbe6137186546e
The action reads a file with individual `export` actions declared on
each line, and calls `setenv` for each.
See go/updatable-classpath for details on how this is going to be used.
Bug: 180105615
Test: manual
Change-Id: I5390e52cf8ffd9c3babf31ed854eeecc727351eb
This is used in cts tests to verify that algorithms in blocklist aren't
used to build the hashtree. The system properties are required to perform
the check on unrooted devices.
Bug: 175236047
Test: flash, getprop; atest CtsNativeVerifiedBootTestCases
Change-Id: I2dcfdb06f85dbe92cde45e836dd68e7bd835020f
Linkerconfig will be moved into Runtime APEX, so
/system/bin/linkerconfig would not be available before APEX is mounted.
Use bootstrap linkerconfig instead during early init.
Bug: 165769179
Test: Cuttlefish boot succeeded
Change-Id: Iae41f325bbd5f5194aaf4613141860f913dfbff1
There are sysfs nodes that don't take multiple inputs, adding a new
copy_per_line built-in command to copy from source file to destination
line by line.
Bug: 171740453
Test: boot and check file and log
Change-Id: I41b7a565829299d56b81d4509525dfa6a0a52444
During boot sequence there can be multiple calls to mount_all. For the
userspace reboot to correctly remount userdata, we need to store the
return code of the one that was responsible in mounting userdata.
Test: adb root
Test: adb shell setprop init.userspace_reboot.is_supported 1
Test: adb reboot userspace
Test: checked dmsg
Bug: 166353152
Change-Id: Id0ae15f3bcf65fa54e4e72b76f64716c053af7fb
Store pertinent information about userspace reboot events in the case
of failure. This information is any services which failed to stop
cleanly, the output of the default fstab and /proc/mounts, and
a list of mounts which failed to unmount. This information is only
stored as necessary (i.e. mount information will not be stored if
everything unmounted, even if some services failed to stop).
Added new /metadata/userspacereboot directory to persist this
information. Information older than 3 days will be deleted.
Test: adb reboot userspace with sigterm/sigkill timeouts set to
very low values
Test: Manual test of storing all other information
Bug: 151820675
Change-Id: I6cfbfae92a7fc6f6c984475cad2c50c559924866
Move responsibility for setting ro.crypto.type into fs_mgr_mount_all,
so that even if setting up the filesystem fails, the type is set
correctly and so errors are appropriately handled.
Bug: 162289984
Test: simulate a failure and check that it's set.
Change-Id: Ib061a454e7e21d7206c3c1fa8e88e16618099581
Init starts ueventd in the default mount namespace to support loading
firmware from APEXes.
Bug: 155023652
Test: devices boots
adb$ nsenter -t (pid of ueventd) -m ls /apex
=> shows all APEXes
Change-Id: Ibb8b33a07eb014752275e3bca4541b8b694dc64b
While mount_all and umount_all were updated to use ro.boot.fstab_suffix,
I neglected to update swapon_all. Trivially copied from umount_all.
Bug: 142424832
Change-Id: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
Merged-In: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
Currently the ReadDefaultFstab function, which calls GetFstabPath,
makes some assumptions about what the fstab will be called and where
it is located. This is being used by vold to set up userdata encryption
and for gsid, and is even used in the default boot control HAL, so it
has become quite baked.
The original way for a board to specify things to mount was to use the
"mount_all /path/to/fstab" command in init.rc. However, due to the
above functionality, the path after mount_all is no longer very useful,
as it cannot differ from the inferred path, or userdata encryption and
other features will be broken.
On Cuttlefish, we have an interest in being able to test alternative
userdata configurations (ext4 vs f2fs, encryption on/off, etc.) and
currently the only way to achieve this is to either a) modify the
ro.hardware or ro.hardware.platform properties, which breaks a bunch
of things like default HAL filenames, or regenerate our odm.img or
vendor.img filesystems. We can't simply install another fstab and
point to it with "mount_all".
This change allows the fstab path to be omitted from "mount_all", and
adds another property which overrides the existing checks for
fstab.${ro.hardware} and fstab.${ro.hardware.platform}. Specifying
${ro.boot.fstab_suffix} will cause fstab.${ro.boot.fstab_suffix}
to be checked first.
Bug: 142424832
Test: booted cuttlefish with 'mount_all ${ro.hardware} --late'
Test: booted cuttlefish with 'mount_all --late'
Test: booted cuttlefish with 'mount_all --late' and fstab_suffix=f2fs
Test: partially booted cuttlefish with 'mount_all ${ro.hardware}'
Test: partially booted cuttlefish with 'mount_all'
Change-Id: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
A one second timeout is so coarse and can affect boot time when
the possibility that the file does not exist. Switch to accepting
a floating point number for seconds for the wait for file command.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: wait_for_file sleep 0.05 reports an appropriate delay
Change-Id: I8d8ed386519ab54270b05ce91663d0add30f12e7
This is apparently causing problems with reboot.
This reverts commit 7205c62933.
Bug: 150863651
Test: build
Change-Id: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
Instead they will be logged from system_server. This CL just prepares
grounds for logging CL to land.
Test: adb reboot userspace
Bug: 148767783
Change-Id: Ie9482ef735344ecfb0de8a37785d314a3c0417ff
