We were ending up with multiple copies of the proto runtime in the
recovery image, when we need zero.
Before:
784K recovery/root/system/lib64/libadbd_services.so
832K recovery/root/system/lib64/libadbd.so
After:
360K recovery/root/system/lib64/libadbd_services.so
344K recovery/root/system/lib64/libadbd.so
Bug: http://b/150317254
Test: treehugger
Change-Id: I39fbb3959128994f0de2ae0ea47dbc0800c516fe
We want to ignore SIGPIPE within init, but if we use SIG_IGN, that
would be inherited by child processes through exec(), which we do not
want to have happen. We instead set up a real signal handler with a
no-op handler function, that will ignore SIGPIPE within init, but will
not be inherited across exec().
This fixes c29c2baa69 ("init: Add support for native service
registration with lmkd"), when SIG_IGN was introduced.
Note that we caught this issue before shipping a release with that
change, so the major motivation here is to not cause a behavior change
in init.
Bug: 151581751
Test: children of init that don't explicitly block SIGPIPE exit when
sent SIGPIPE
Test: children of init that do explicitly block SIGPIPE do not exit
when sent SIGPIPE
Test: init does not exit when sent SIGPIPE
Test: init exits when sent SIGABRT
Change-Id: Ieda8555fd03836bcd672a422fe673a8369ad9beb
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.
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
A previous version of this change was reverted and added locks around
all service operations and allowed the property thread to spawn
services directly. This was complex due to the fact that this code
was not designed to be multi-threaded. It was reverted due to
apparent issues during reboot. This change keeps a queue of processes
pending control messages, which it will then handle in the future. It
is less flexible but safer.
Bug: 146877356
Bug: 148236233
Bug: 150863651
Bug: 151251827
Test: multiple reboot tests, safely restarting hwservicemanager
Change-Id: Ice773436e85d3bf636bb0a892f3f6002bdf996b6
__ANDROID_API__ isn't defined on host, so this check will fail due to
-Wundef. The || is short circuited through, so we can check for host
first and only have the right side of the || evaluated for device
builds.
Bug: 150898477
Bug: 151255209
Test: build
Change-Id: I2e0bc055ac0c7ba8262875801cdaed9cc30d2cef
libselinux is currently being copied to APEXes. This is risky because
the library is not designed to be portable; part of it is tied to the
specific version of the Android that it was developed for.
This change fixes the problem by declaring that the library supports
a stub with the list of C APIs that are included in the stub. Then there
is only one copy of libselinux in /system/lib and other APEXes use the
copy by dynamically linking to it.
Also, adbd no longer statically links to it, because doing so brings
libselinux in it.
Bug: 151053366
Test: m com.android.adbd. It doesn't include libselinux in it.
Test: m com.android.adbd-deps-info. then inspect
out/soong/com.android.adbd-deps-info.txt. The dependency to libselinux
is shown as '(external)'.
Change-Id: If418cbe3abdeacb759d59052e6dca4c2067678dd
In case of GSI on DSU, /data is mounted on the following stack:
userdata -> userdata_gsi -> actual block device, and fstab returned from
ReadDefaultFstab() function will say that /data should be
mounted onto userdata_gsi. This configuration wasn't supported.
To support it, fs_mgr_get_mounted_entry_for_userdata now unwinds the
dm-device stack /data is mounted onto, and for each entry in fstab
resolves corresponding block device (in case of logical partitions by
asking DeviceMapper to resolve name -> path, and for other cases by
reading a symlink), and then checking whenever resolved block device
belongs to the unwinded stack.
Test: on both normal boot & DSU
Test: atest CtsUserspaceRebootHostSideTestCases
Test: atest CtsFsMgrTestCases
Bug: 148612148
Change-Id: I1bb3e64ae92d56de905b4f7f1997b7499b101b0f
Merged-In: I1bb3e64ae92d56de905b4f7f1997b7499b101b0f
(cherry picked from commit f495fe798b)
... so that an operation can be skipped partially. For example, if
an operation contains blocks:
563412 -> 123456
... then optimized operation is:
5612 -> 1256
Test: update_engine_unittests
Test: apply incremental OTA
Bug: 148623880
In an experiment, this reduces CoW size of an incremental update
package by 200MB (out of 700MB).
Change-Id: I86ca23fd589ddbc84c81318283b5f4e71782a759
There is a longstanding bug where file-based encryption causes spurious
SELinux denials of module_request because it uses the kernel's crypto
API, and the crypto API tries to autoload kernel modules.
While this sometimes indicate missing kconfig options, it can still
happen even if all needed kconfig options are enabled. This is because
a crypto algorithm can be a composition like "hmac(sha512)", and the
crypto API will first look for the full composition before it
instantiates it using the components like "hmac" and "sha512". But
often an implementation of the full composition doesn't exist.
However, as far as I can tell, Android doesn't actually use kernel
module autoloading at all. First, Android never changes
/proc/sys/kernel/modprobe from the default of "/sbin/modprobe", yet this
isn't where modprobe is located on Android. Android's SELinux policy
contains a neverallow rule that ensures that only init (not even
vendor_init) can write to this setting, so vendors can't be changing it.
Vendors could potentially be setting CONFIG_STATIC_USERMODEHELPER_PATH,
which overrides the path of all usermode helpers including modprobe.
But this is a relatively new kconfig option, available only in
android-4.14 and later. Also, for a vendor to actually do this they'd
also need to extend the SELinux policy with a domain_auto_trans rule to
allow their usermode helper to be executed by the kernel.
Android does increasingly use kernel modules, and GKI (Generic Kernel
Image) will require them. However, the modules are actually inserted by
userspace by 'init', not autoloaded.
It's possible to disable kernel module autoloading completely by setting
/proc/sys/kernel/modprobe to an empty string. So, let's do that.
This prevents lots of spurious SELinux denials, and allows removing
unnecessary rules to allow or dontaudit the module_request permission.
Note: when the kernel doesn't have CONFIG_ANDROID_BINDERFS enabled, this
change exposes a kernel bug that causes a WARNING in get_fs_type(). To
avoid this WARNING, a kernel fix should be applied too -- currently
under discussion upstream
(https://lkml.kernel.org/r/20200310223731.126894-1-ebiggers@kernel.org).
Bug: 130424539
Bug: 132409186
Bug: 144399145
Bug: 146477240
Bug: 148005188
Bug: 149542343
Test: Tested on cuttlefish and coral:
- Checked that /proc/sys/kernel/modprobe contains /sbin/modprobe
before this change, and the empty string after.
- Checked that if all SELinux rules for module_request are removed,
there are SELinux denials for module_request before this change
but none after.
- Ran lsmod both before and after and verified that the list is the
same, i.e. checked that this change doesn't break how Android
actually loads kernel modules.
Change-Id: I4132fe1a491e7b789311afcf693c1f6493fb9dc5
With some internal API changing from "const char*" to
"const std::string&", we can change a couple calling sites to
directly pass a std::string reference, instead of getting the
c_str() version of the string. This avoids us creating a
temporary std::string for the call.
Test: TreeHugger
Change-Id: I2fe0760ce8bf7d352010a341005356c0a801d351
GetGsiService() is defined in libgsid, let libfs_mgr_binder link to
libgsid instead of duplicating the logic.
Test: Build and boot
Change-Id: I28d0c92b432a53770a3bdc5f4c5cd91e3466151c
liblog is a platform library that provides stable C API. There is no
need to include the library, especialy by statically linking to it, in
any APEX. It not only wastes the storage/ram, but also is incorrect
because the socket interface to logd which is implemented in liblog is
not guaranteed to be stable.
Fixing this issue by converting static_libs: ["liblog"] into
shared_libs: ["liblog"], in which case the dependency to the library
is satisfied via the stub variant of the library.
As a result, we could restrict the availablity of the library to
the platform and the runtime APEX.
Exempt-From-Owner-Approval: already approved when this was in internal
master (ag/10572699)
Bug: http://b/151051671
Bug: http://b/150827719
Test: m
Change-Id: I5aab863cb12b8767b6979255c247000a59355b0e
