With a regular x86 kernel we are always able to get 32
min bits for mmap randomization.
However to emulate 16KB for x86 app developers the kernel
can only provide 30 bits for the randomization due the to
larger page size (PAGE_SHIFT =+ 2).
Allow the min rand bits to be (32 - (PAGE_SHIFT - 12)) in
order to generically support larger than 4KB page sizes.
This should be a no-op change for all devices, except the
x86 16KB emulator, since they will always be able to get
32 random bits.
Bug: 309816695
Test: Boot test 4k x86 device
Test: Boot test emulated 16k x86 device
Change-Id: I48d47d56ac3aecb71a9e0093a7033bb60b89c2b7
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Noticed while looking at riscv64. Looks like a bug, but actually nothing
we can do about it now or for the foreseeable future.
Bug: https://github.com/google/android-riscv64/issues/45
Test: treehugger
Change-Id: I2be81b2fd7095df40958a1f641d7b89cf5a8e41d
Improve the comment, and increase the "minimum maximum" to 24 --- we
only support 64-bit, and 64-bit never has less than 24 bits.
Bug: https://github.com/google/android-riscv64/issues/1
Test: treehugger
Change-Id: I478c7649aa19258352c908a449cabe12da94952c
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>
mmap_rnd_compat_bits is for address space randomization of 32-bit
applications on 64-bit system. Configuring it is not only unnecessary
for 64-bit "only" builds, but also can cause a boot failure if the
kernel is built without CONFIG_COMPAT which is the case for Microdroid.
Use ro.product.abilist32 to determine whether 32-bit applications are
supported and if not, don't configure it, but mmap_rnd_bits.
Bug: 237950549
Test: run Microdroid with the kernel built with aosp/2153639
Change-Id: Ifca6fa02f14ad4c7d8f9b2ab8852494c12945c3a
This has been something the kernel does automatically since 2014, so
there's no obvious reason to add extra work during boot to duplicate
that effort.
Bug: http://b/179086242
Test: treehugger
Change-Id: I44cce99a892e4f2a6a303c2126bd29f955f5fb23
Some functionality based on eBPF attached to tracepoints (gpu memory
accounting and time-in-state) rely on newer devices running with
"disabled" perf_event_paranoid controls as a result of the kernel having
LSM hooks in the perf_event_open syscall instead. This is tested
for, and set up by init via the sys.init.perf_lsm_hooks sysprop.
Development devices that boot into permissive mode still want the
eBPF-based functionality to work, but end up with a paranoid value that
disallows the syscall, as the LSM hook test expects to observe a SELinux
denial (which doesn't happen due to permissiveness).
As a pragmatic way of achieving the paranoid value override, we pretend
that the hook test has succeeded if we detect permissive SELinux during
second-stage init. It'd be nicer if we had a sysprop to reflect the
device's on-boot status of SELinux, but it's not worth adding for this
case.
BYPASS_INCLUSIVE_LANGUAGE_REASON=technical term
Bug: 170674916
Tested: booted crosshatch-userdebug with permissive kernel cmdline,
confirmed that the log message from the new codepath was present
in logcat, sysprop is 1, and paranoid is -1.
Change-Id: I9df5da2076cdbd777d35e50e8cd7a483ec85e20a
Historically, the syscall was controlled by a system-wide
perf_event_paranoid sysctl, which is not flexible enough to allow only
specific processes to use the syscall. However, SELinux support for the
syscall has been upstreamed recently[1] (and is being backported to
Android R release common kernels).
[1] da97e18458
As the presence of these hooks is not guaranteed on all Android R
platforms (since we support upgrades while keeping an older kernel), we
need to test for the feature dynamically. The LSM hooks themselves have
no way of being detected directly, so we instead test for their effects,
so we perform several syscalls, and look for a specific success/failure
combination, corresponding to the platform's SELinux policy.
If hooks are detected, perf_event_paranoid is set to -1 (unrestricted),
as the SELinux policy is then sufficient to control access.
This is done within init for several reasons:
* CAP_SYS_ADMIN side-steps perf_event_paranoid, so the tests can be done
if non-root users aren't allowed to use the syscall (the default).
* init is already the setter of the paranoid value (see init.rc), which
is also a privileged operation.
* the test itself is simple (couple of syscalls), so having a dedicated
test binary/domain felt excessive.
I decided to go through a new sysprop (set by a builtin test in
second-stage init), and keeping the actuation in init.rc. We can change
it to an immediate write to the paranoid value if a use-case comes up
that requires the decision to be made earlier in the init sequence.
Bug: 137092007
Change-Id: Ib13a31fee896f17a28910d993df57168a83a4b3d
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
One of the major aspects of treble is the compartmentalization of system
and vendor components, however init leaves a huge gap here, as vendor
init scripts run in the same context as system init scripts and thus can
access and modify the same properties, files, etc as the system can.
This change is meant to close that gap. It forks a separate 'subcontext'
init that runs in a different SELinux context with permissions that match
what vendors should have access to. Commands get sent over a socket to
this 'subcontext' init that then runs them in this SELinux context and
returns the result.
Note that not all commands run in the subcontext; some commands such as
those dealing with services only make sense in the context of the main
init process.
Bug: 62875318
Test: init unit tests, boot bullhead, boot sailfish
Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
Test: boot bullhead
Test: Introduce LOG(FATAL) at various points of init and ensure that
it reboots to the bootloader successfully
Test: Introduce LOG(FATAL) during DoReboot() and ensure that it reboots
instead of recursing infinitely
Test: Ensure that fatal signals reboot to bootloader
Change-Id: I409005b6fab379df2d635e3e33d2df48a1a97df3
We currently throw out the return values from builtin functions and
occasionally log errors with no supporting context. This change uses
the newly introduced Result<T> class to communicate a successful result
or an error back to callers in order to print an error with clear
context when a builtin fails.
Example:
init: Command 'write /sys/class/leds/vibrator/trigger transient' action=init (/init.rc:245) took 0ms and failed: Unable to write to file '/sys/class/leds/vibrator/trigger': open() failed: No such file or directory
Test: boot bullhead
Merged-In: Idc18f331d2d646629c6093c1e0f2996cf9b42aec
Change-Id: Idc18f331d2d646629c6093c1e0f2996cf9b42aec
This change splits out the selinux initialization and supporting
functionality into selinux.cpp and splits the security related
initialization of the rng, etc to security.cpp. It also provides
additional documentation for SEPolicy loading as this has been
requested by some teams.
It additionally cleans up sehandle and sehandle_prop. The former is
static within selinux.cpp and new wrapper functions are created around
selabel_lookup*() to better serve the users. The latter is moved to
property_service.cpp as it is isolated to that file for its usage.
Test: boot bullhead
Merged-In: Idc95d493cebc681fbe686b5160502f36af149f60
Change-Id: Idc95d493cebc681fbe686b5160502f36af149f60
