Introduce hypervisor-generic type for VM managers:
vm_manager_device_type.
Bug: 274758531
Change-Id: I0937e2c717ff973eeb61543bd05a7dcc2e5dc19c
Suggested-by: Steven Moreland <smoreland@google.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
1. Allow them to be configured by vendor_init.
2. Introduce a new system property
hypervisor.memory_reclaim.supported, which is configured by
vendor_init and accessed only by virtualizationservice, and is not
as widely accessible as the existing hypervisor sysprops.
Bug: 235579465
Test: atest MicrodroidTests
Change-Id: I952432568a6ab351b5cc155ff5eb0cb0dcddf433
Manual testing protocol:
* Verify prng_seeder daemon is running and has the
correct label (via ps -Z)
* Verify prng_seeder socket present and has correct
label (via ls -Z)
* Verify no SELinux denials
* strace a libcrypto process and verify it reads seeding
data from prng_seeder (e.g. strace bssl rand -hex 1024)
* strace seeder daemon to observe incoming connections
(e.g. strace -f -p `pgrep prng_seeder`)
* Kill daemon, observe that init restarts it
* strace again and observe clients now seed from new instance
Bug: 243933553
Test: Manual - see above
Change-Id: I0a7e339115a2cf6b819730dcf5f8b189a339c57d
The properties for rkp_only are no longer read only.
This allows remote provisioner unit tests to enable/disable the remote
provisioning only mode, which is required to fully verify functionality.
Test: RemoteProvisionerUnitTests
Bug: 227306369
Change-Id: I8006712a49c4d0605f6268068414b49714bbd939
These properties are used to inform keystore2 and the RemoteProvisioner
app how they should behave in the system in the event that RKP keys are
exhausted. The usual behavior in a hybrid system is not to take any
action and fallback to the factory provisioned key if key attestation is
requested and no remotely provisioned keys are available.
However, there are instances where this could happen on a device that
was intended to be RKP only, in which case the system needs to know that
it should go ahead and attempt to remotely provision new certificates or
throw an error in the case where none are available.
Test: New properties are accessible from the two domains
Change-Id: I8d6c9e650566499bf08cfda2f71c64d5c2b26fd6
rss_stat will be throttled using histogram triggers and synthetic trace
events. Add genfs context labels for the synthetic tracefs files.
Bug: 145972256
Test: Check log cat for avc denials
Change-Id: I7e183aa930bb6ee79613d011bed7174d553f9c1a
This reverts commit f20fea50f1.
Reason for revert: unbreak the git_sc-v2-dev-plus-aosp tests
Bug: 202879263
Change-Id: I79245afb4ba7f5be8ee46f2e91921a7327b650c5
Although there has been a plan to add code to the init process that
requires access to block device properties, that plan has not been
realized. Hence stop granting the init process access to block device
properties
Bug: 202520796
Test: source build/envsetup.sh && lunch aosp_x86_64 && m && launch_cvd
Change-Id: I0ed83bd533a901f85986d15f636c9b3f39fec271
Signed-off-by: Bart Van Assche <bvanassche@google.com>
In virtualized deployments of Android, it can be useful to have
access to a description of the hypervisor/host environment being
used to run the guest OS instance.
This is represented by means of a new system property
ro.boot.hypervisor.version, which is meant to convey a
free-form descriptor of the current host/hypervisor version
The property is meant to be provided to Android as androidboot.
by whatever host-specific means are used to supply other boot
properties to the target Android instance. Access could be later
opened to other vendor processes to set if needed for specific
setups where init is not a sufficiently-early stage for
host/guest communication. Such setups are not known at this time.
For a native Android incantation, the property defaults to
being missing
Other properties could later be added to this same namespace
and context if they turn out to be useful in specific scenarios.
Bug: 178749018
Test: build cuttlefish
Change-Id: Id721c14ef1958b525c2866a660dcae8fd176a79d
This reverts commit 7ed2456b45.
Reason for revert: /dev/userspace-panic is discarded (b/188777408#comment13)
Bug: 188777408
Change-Id: I98b0159890ee755ffaefc5533f9c40d54f8f26d2
Define type userspace_panic_device and macro userpanic_use for init,
llkd, and system_server to access /dev/userspace_panic - a kernel file
node for userspace processes to request kernel panic.
Bug: 188777408
Change-Id: I1e9d115d85f664aa84bdd6bb4b95bdb48e3aab9a
Addressing b/194450129 requires configuring the I/O scheduler and the
queue depth of loop devices. Doing this in a generic way requires
iterating over the block devices under /sys/class/block and also to
examine the properties of the boot device (/dev/sda). Hence this patch
that allows 'init' and 'apexd' to read the properties of all block
devices. The patch that configures the queue depth is available at
https://android-review.googlesource.com/c/platform/system/core/+/1783847.
Test: Built Android images, installed these on an Android device and verified that modified init and apexd processes do not trigger any SELinux complaints.
Change-Id: Icb62449fe0d21b3790198768a2bb8e808c7b968e
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The init process configures swapping over zram over a loop device. An
I/O scheduler is associated with the loop device. Tests have shown that
no I/O scheduler works better than the default, mq-deadline. Hence
allow the init process to configure the loop device I/O scheduler.
Without this patch, the following SELinux denials are reported during
boot:
1 1 I auditd : type=1400 audit(0.0:4): avc: denied { read write } for comm="init" name="scheduler" dev="sysfs" ino=78312 scontext=u:r:init:s0 tcontext=u:object_r:sysfs_loop:s0 tclass=file permissive=0
1 1 I auditd : type=1400 audit(0.0:4): avc: denied { read write } for comm="init" name="scheduler" dev="sysfs" ino=78312 scontext=u:r:init:s0 tcontext=u:object_r:sysfs_loop:s0 tclass=file permissive=0
Bug: 194450129
Test: Built Android images and installed these on an Android device.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Change-Id: I0af0a92c53bb1f68b57f6814c431a7f03d8ea967
In microdroid, apexd activates apexes which are passed as a virtual disk
to share apexes with host Android.
Bug: 184605708
Test: apexd running in microdroid can read /dev/block/vdb2
when a disk image is passed to crosvm via --disk= option.
Change-Id: Ie27774868a0e0befb4c42cff795d1531b042654c
* Permits setting the sys.drop_caches property from shell.
* Permits init to read and write to the drop_caches file.
* Can only be set to 3 (drop_caches) and 0 (unset).
Bug: 178647679
Test: flashed user build and set property; no avc denials.
Test: flashed userdebug build and dropped caches w/o root.
Change-Id: Idcedf83f14f6299fab383f042829d8d548fb4f5d
Create contexts for /sys/kernel/tracing/instances/bootreceiver
Allow read access to files in this dir for system_server.
Bug: 172316664
Bug: 181778620
Test: manual runs with KFENCE enabled
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I7021a9f32b1392b9afb77294a1fd0a1be232b1f2
Revert submission 1572240-kernel_bootreceiver
Reason for revert: DroidMonitor: Potential culprit for Bug 181778620 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted Changes:
Ic1c49a695:init.rc: set up a tracing instance for BootReceive...
I828666ec3:Selinux policy for bootreceiver tracing instance
Change-Id: I9a8da7ae501a4b7c3d6cb5bf365458cfd1bef906
Create contexts for /sys/kernel/tracing/instances/bootreceiver
Allow read access to files in this dir for system_server.
Bug: 172316664
Test: manual runs with KFENCE enabled
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I828666ec3154aadf138cfa552832a66ad8f4a201
System files in recovery are labelled as rootfs, so we need an explicit
transition to snapuserd. Without this, factory data resets will fail
with a VABC OTA pending, with the following denial:
avc: denied { entrypoint } for pid=522 comm="init" path="/system/bin/snapuserd"
dev="rootfs" ino=1491 scontext=u:r:snapuserd:s0 tcontext=u:object_r:rootfs:s0
tclass=file permissive=0
Bug: 179336104
Test: factory data reset with VABC OTA pending
Change-Id: Ia839d84a48f2ac8ccb37d6ae3b1f8a8f7e619931
During first-stage init we spawn a daemon (snapuserd) to interact with
the dm-user kernel module. Immediately after sepolicy is loaded, we
launch the daemon again with the correct privileges, and kill the
original one.
In order for init to do this, it needs to be able to open and write to
the snapuserd socket (which is corrected to the "correct" daemon), as
well as call flock() on /metadata/ota which is how libsnapshot ensures
exclusive access to Virtual A/B snapshots.
Bug: 168259959
Test: no denials with Virtual A/B Compression enabled
Change-Id: Ic7fc78ca1a17673b878766e0f4dfe0265c1be768
This cleans up remaining exported2_default_prop. Three properties are
changed.
- ro.arch
It becomes build_prop.
- hal.instrumentation.enable
It becomes hal_instrumentation_prop.
- ro.property_service.version
It becomes property_service_version_prop.
Bug: 155844385
Test: selinux denial test on Pixel devices
Change-Id: I7ee0bd8c522cc09ee82ef89e6a13bbbf65291291
ro.boot. properties assigned as "exported2_default_prop" are now
"bootloader_prop", to remove bad context name "exported2_default_prop".
Two things to clarify:
1) We have both the prefix entry and the exact entries. Although the
exact entries may be redundant, we may want to keep them. Vendors are
still allowed to have properties starting with "ro.boot." on
vendor_property_contexts file. The exact entries can prevent vendors
from modifying them to random contexts.
2) ro.boot. is special as it is originally for kernel command line
"androidboot.". But some ro.boot. properties are being used as if they
were normal. To avoid regression, ro.boot. properties having contexts
other than "exported2_default_prop" are not changed here. They will be
tracked later.
Bug: 155844385
Test: m selinux_policy
Change-Id: Ic0f4117ae68a828787304187457b5e1e105a52c7
Merged-In: Ic0f4117ae68a828787304187457b5e1e105a52c7
vts_config_prop and vts_status_prop are added to remove exported*_prop.
ro.vts.coverage becomes vts_config_prop, and vts.native_server.on
becomes vts_status_prop.
Bug: 155844385
Test: Run some vts and then getprop, e.g. atest \
VtsHalAudioEffectV4_0TargetTest && adb shell getprop
Test: ro.vts.coverage is read without denials
Change-Id: Ic3532ef0ae7083db8d619d80e2b73249f87981ce
There are probably more cases but this one blocks presubmit
for cuttlefish with mainline kernels.
Bug: 158304247
Change-Id: I6d769b16a230a113a804df61f8de4dcbce2193b6
This properties are used to compute UserspaceRebootAtom and are going to
be written by system_server. Also removed now unused
userspace_reboot_prop.
Test: builds
Bug: 148767783
Change-Id: Iee44b4ca9f5d3913ac71b2ac6959c232f060f0ed
Written exclusively by init. Made it readable by shell for CTS, and for
easier platform debugging.
Bug: 137092007
Change-Id: Ia5b056117502c272bc7169661069d0c8020695e2
Add extra policy to enable linkerconfig to be executed from recovery.
Bug: 139638519
Test: Tested from crosshatch recovery
Change-Id: I40cdea4c45e8a649f933ba6ee73afaa7ab3f5348
In order to remount ext4 userdata into checkpointing mode, init will
need to delete all devices from dm-stack it is mounted onto (e.g.
dm-bow, dm-crypto). For that it needs to get name of a dm-device by
reading /sys/block/dm-XX/dm/name file.
Test: adb shell setprop sys.init.userdata_remount.force_umount_f2fs 1
Test: adb shell /system/bin/vdc checkpoint startCheckpoint 1
Test: adb reboot userspace
Test: adb shell dumpsys activity
Bug: 135984674
Bug: 143970043
Change-Id: I919a4afdce8a4f88322f636fdf796a2f1a955d04
By default sys.init.userspace_reboot.* properties are internal to
/system partition. Only exception is
sys.init.userspace_reboot.in_progress which signals to all native
services (including vendor ones) that userspace reboot is happening,
hence it should be a system_public_prop.
Only init should be allowed to set userspace reboot related properties.
Bug: 135984674
Test: builds
Test: adb reboot userspace
Change-Id: Ibb04965be2d5bf6e81b34569aaaa1014ff61e0d3
With the CLs in the same topic, it's being built as a dynamically linked
executable. And this applies to normal boot (including charger mode) and
recovery mode both.
/system/bin/charger under normal boot will be labeled as charger_exec,
which has the attribute of system_file_type.
The file in recovery image will still be labeled as rootfs. So we keep
the domain_trans rule for rootfs file, but allowing for recovery mode
only.
Bug: 73660730
Test: Boot into charger mode on taimen. Check that charger UI works.
Test: Boot into recovery mode. Check that charger process works.
Change-Id: I062d81c346578cdfce1cc2dce18c829387a1fdbc
init needs to execute bpfloader as a one-shot service. Add sepolicy for
the same. Also update old rules allowing init to fork/exec bpfloader and
remove rules allowing netd to do so.
Bug: 112334572
Change-Id: Ic242cd507731ed8af3f8e94d4fccc95819831d37
Signed-off-by: Joel Fernandes <joelaf@google.com>
NIAP certification requires that all cryptographic functions
undergo a self-test during startup to demonstrate correct
operation. init now performs this check during startup.
The self-test is forked from init. For the child process
to be able to request a reboot it needs permissions to
set the sys.powerctl property.
Bug: 119826244
Test: Built for walleye. When the BoringSSL self test was forced
to fail the device rebooted into the bootloader, as
expected.
Change-Id: I4171b1dd0a5e393252ae5c002171ac51c9cbb3e6
Also allow adb and fastboot to talk to recovery
through recovery_socket. This enables changing
between modes with usb commands.
Test: No selinux denials
Bug: 78793464
Change-Id: I80c54d4eaf3b94a1fe26d2280af4e57cb1593790
Also allow adb and fastboot to talk to recovery
through recovery_socket. This enables changing
between modes with usb commands.
Test: No selinux denials
Bug: 78793464
Change-Id: I1f97659736429fe961319c642f458c80f199ffb4
This is do aid developers pushing debug services to not need to modify
the underlying SEPolicy
avc: denied { transition } for comm="init" path="/system/bin/awk"
dev="dm-0" ino=1934 scontext=u:r:init:s0 tcontext=u:r:su:s0
tclass=process
avc: denied { rlimitinh } for comm="awk" scontext=u:r:init:s0
tcontext=u:r:su:s0 tclass=process
avc: denied { siginh } for comm="awk" scontext=u:r:init:s0
tcontext=u:r:su:s0 tclass=process
avc: denied { noatsecure } for comm="awk" scontext=u:r:init:s0
tcontext=u:r:su:s0 tclass=process
Test: init can execute a system_file marked with seclabel u:r:su:s0
Change-Id: I85d9528341fe08dbb2fb9a91e34a41f41aa093be
