With the keymint HAL removed from microdroid, there are no more legacy
HALs meaning no further need for hwservicemanager.
Bug: 215747811
Test: atest MicrodroidTests
Change-Id: I111f3456399ef91e51d1cfead67659601c23db9e
The keymint HAL has been removed from microdroid to remove the
corresponding sepolicy.
Bug: 215747811
Test: atest MicrodroidTests
Change-Id: I08aae50dd9a4575954db40ec974625e43bff2335
The keystore service has been removed from microdroid to remove the
corresponding sepolicy.
Bug: 215747811
Test: atest MicrodroidTests
Change-Id: I6600b47f8b8c6bba05b1f59b4d87713283805817
This property is read by microdroid_manager to check whether the VM is
in debug mode. Give it a context to satisfy the sepolicy.
Bug: 214231981
Test: atest MicrodroidTestApp
Change-Id: I9d4bda5e487324c95229c7978e8fe0a53fa9f616
This reverts commit eee72d6cb3d9f5c6001192247861b28cb0787827.
REASON: not needed. See the other CL in the same topic.
Bug: 197358423
Test: m
Change-Id: Ice0813ed9e349e37c83b163e2c21f17bb1105013
Previously, all dalvik.vm.* properties were not used / ignored in
Microdroid. However this change makes use of
dalvik.vm.boot-dex2oat-threads which controls the concurrency level of
dex2oat.
Specifically, on the host-side, the number of vCPUs in the compos VM is
configured from the system property having the same name. Then inside
the compos VM, compsvc which runs in the compos domain, sets the system
property to be the number of vCPUs in the VM. In other words, the system
properties get the same value both in the host and the guest VMs. Then
finally, the dex2oat process running inside the VM reads the system
property and configures its concurrency level accordingly.
Bug: 197358423
Test: run compos
Change-Id: I8d2394a7192a7b55a910f317e12e2b1f60b89636
This should be read-only and corresponds to apexd.payload_metadata.path
Bug: 191097666
Test: android-sh -c 'setprop apexd.payload_metadata.path'
See permission denied
atest MicrodroidHostTestCases
Change-Id: Ifcb7da1266769895974d4fef86139bad5891a4ec
dex2oat currently uses some properties as flags (see
art/libartbase/base/flags.cc). For CompOS, we don't really need such
properties, and actually should avoid global state. So dontaudit
explicitly.
Bug: 210030607
Test: no more default_prop denials for dex2oat
Change-Id: I10852f2a7df4dac7a9389eab3f53f91328104f96
The two properties are not just prefixes. See __android_log_level in
system/logging/liblog/properties.cpp.
Bug: 210030607
Test: no longer seeing denials with default_prop in odrefresh
Change-Id: If2c9cba7aa65802e81c79c7d3d9735cbf14a6efa
The `__builtin_available` macro is used in used in several libraries in
microdroid, including liblog. The macro internally uses
ro.build.version.{codename,sdk}[1]. This change defines the context for
these properties.
[1] https://reviews.llvm.org/rG516a01b5f36d4188778a34202cd11856d70ac808
Bug: 210030607
Test: No longer seeing denied access of default_prop from odrefresh
Change-Id: I51bc52f679a174daccc05a1e2d6c9fda9e6b12cb
logd.ready is a system property that logd sets when it is ready to
serve incoming socket requests for reading and writing logs. Clients of
logd (e.g. logcat) can use this to synchronize with logd, otherwise they
may experience a crash due to the refused socket connection to logd when
they are started before logd is ready.
Bug: 206826522
Test: run microdroid. see logcat logs are shown immediately
Change-Id: Iee13485b0f4c2beda9bc8434f514c4e32e119492
And microdroid_manager can set it to shut down when verification fails.
Bug: 204073443
Test: MicrodroidHostTestCases
Change-Id: I12ec7c8b832f5d1e382961ce7866502c2cc8a9b8
In Microdroid, logcat is started as a daemon process (whose service name
is seriallogging) whose job is to read logs from logd and sends them to
the host side via a virtual console.
The daemon process is controlled by microdroid_manager, so the process
is given write access to ctl.start$seriallogging and also to some
sysprops originated from bootconfig so that it can know if the VM is
configured as debuggable or not.
Bug: 200914564
Test: start microdroid using the vm tool. logcat logs are shown in
stdout.
Change-Id: I79bc6486ae1f84515ad31a09e24d8368fb54bc6d
microdroid's domains have been able to read/write any properties. That's
just for convenience while bringing up microdroid. This cleans up such
global permission and grants minimal access.
Bug: 194447534
Test: atest MicrodroidHostTestCases ComposHostTestCases
Test: run microdroid demo app
Change-Id: I09ce1174d4af9c228b788a522a6ab845cafd4505
This adds properties necessary to run microdroid to property_contexts,
and then removes default_prop access to all domains except for init, as
init should be able to write all properties.
Bug: 194447534
Test: atest MicrodroidHostTestCases ComposHostTestCases
Change-Id: I2f80c71ce257613b3c3b019a3e988a5a0653d879
Previously, the boot process of microdroid was mostly implemented in the
init.rc file. microdroid_manager was started first in the background,
then apexd, apkdmverity, and zipfuse were executed in sequence. However,
in order to correctly implement the app payload verification scheme,
most of the early boot process has to be controlled by
microdroid_manager. Specifically, apkdmverity should be started "after"
the apk roothash is read from the instance disk by microdroid_manager.
As an alternative, we could let apkdmverity the read instance disk by
itself. However, this is undesirable because doing so requires multiple
processes - microdroid_manager and apkdmverity - have access to the
instance disk and more seriously the secret key to decrypt it.
Another alternative is to let microdroid_manager do the dm-verity
configuration which apkdmverity does. This also is considered
undesirable because then we would give the permissions for configuring
dm-verity devices to microdroid_manager which is a long-running daemon
process. Note that apkdmverity is not a daemon process.
This CL introduces a few number of changes which are required to let
microdroid_manager directly control the early boot process:
1) microdroid_manager is allowed to start the services apkdmverity and
zipfuse by using the `ctl.start` sysprop.
2) apkdmverity is allowed to use bootstrap bionic libraries as it is now
executed before APEXd activates the APEXes.
3) A new sysprop `microdroid_manager.apk_roothash` is added. It is
written by microdroid_manager and read by apkdmverity. It contains the
roothash read from the instance disk. This value is not a secret.
4) Another new sysprop `apex_config.done` is added. It is set by init
just after `perform_apex_config` and read by microdroid_manager.
Microdroid_manager uses this to wait until linker configuration is ready
so that it can execute app payloads with the config.
Bug: 193504400
Test: atest MicrodroidHostTestCases
Change-Id: If29ce17d7a6cb4859e8ceeffb321724e7f11bf82
authfs_service is a binder service on microdroid. Upon a request by the
client, the service will create the mount directory, execute authfs to
mount the FUSE, and finally unmount and delete the mount directory.
authfs currently requires more privileges than it should, but it's ok
because the client owns the VM, and all input will be verified by
signatures. But there is plan to keep the privileges isoated in the
service (b/195554831).
Bug: 194717985
Bug: 195554831
Test: Start the service from init, use a test executable to call the
service API. Only observed denial from the test executable.
Change-Id: Ie53aa9e2796433fc3182357039d0b7ba1c0848ef
