ALL_ROOTDIR_SYMLINKS and add them to ALL_DEFAULT_INSTALLED_MODULES,
so they can be included in product SBOMs properly.
Bug: 272358980
Test: CIs and build/soong/tests/sbom_test.sh
Change-Id: I73dfb34156d681786c013912e59a0d0c0c48ecc7
If ro.zygote is zygote64, don't bother running 32-bit test.
Otherwise abilist{32,64} decides what tests to run.
Bug: 291874369
Test: make gsi_arm64-user; Check /system/etc/init/hw
Change-Id: Id10b2242606d6400acc29c3174f713581d6cce2e
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 shared between two mount namespaces, hence visible
in the default mount namespace.
Bug: 290148078
Test: VendorApexHostTestCases
Change-Id: I841480e41be8def5a4c6a4aa874c4e21465a71d3
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
This folder is used to host bootanim data files.
Bug: 210757252
Test: /data/misc/bootanim is correctly created.
Change-Id: I9c9949316d073ad7ebac503f097c5fee6c0b2a22
VFIO nodes, both the container (`vfio`) node and group (numbered)
nodes, should be located in `/dev/vfio`. This change prevents
ueventd from flattening that structure.
Test: Bind a device to VFIO driver to create a VFIO group
Change-Id: I635e9febe6bb52718df263e735479f361eacad4c
lpdumpd runs as "system", not "root". Adjust the DAC permissions of
/metadata/ota so it can call SnapshotManager::Dump.
Bug: 291083311
Test: lpdump
Change-Id: I97fd7eb2055cf6d31fd42f1021e2f99edbdb838a
The "update_verifier_nonencrypted" service is being replaced with simply
"update_verifier", so update init.rc accordingly.
Bug: 208476087
Test: presubmit
Change-Id: I58f3fb25167ff7d3679c72e5e9c012f02fa5b516
The three actions for "zygote-start" are identical except for their
property triggers. This seems to have been left over from when Android
supported both File Based Encryption (FBE) and Full Disk Encryption
(FDE), causing there to be four possible encryption states:
- ro.crypto.state=unsupported (No encryption configured)
- ro.crypto.state=encrypted && ro.crypto.type=file (FBE enabled)
- ro.crypto.state=unencrypted (FDE supported but disabled)
- ro.crypto.state=encrypted && ro.crypto.type=block (FDE enabled)
It seems that the reason the zygote-start action was duplicated three
times was to exclude the "FDE enabled" case, which could only be done by
explicitly listing the other three cases.
However, now that FDE is no longer supported, only the first two cases
are possible. Therefore, zygote-start can just be the whole trigger.
Bug: 208476087
Test: presubmit
Change-Id: Icd6e4b0d2fb3f9f20595c0af4e2e35350564da8d
Remove the code that "locked" the .fs-verity keyring at a certain point
in the boot. It probably was thought that this achieved some useful
security property, which is a bit questionable. Regardless, Android no
longer uses fsverity builtin signatures. The only code that is still
being kept around is enough to access existing files on old kernels, and
for this "locking" the keyring is definitely not essential.
Bug: 290064770
Test: presubmit and booting Cuttlefish
Change-Id: Ide5729aeac5772658b2a3f0abe835988b8842b02
Based on experiments, we fount out 128 (128 x global readahead window
size = 16mb) is the optimal multiple to boost up read speeds for the
sequentially accessed files with POSIX_FADV_SEQUENTIAL.
Bug: 195311558
Test: check the /sys/fs/f2fs/<userdata partition>/seq_file_ra_mul value
Change-Id: I7563ad6e47b9ab76ae7fe36978d0e5970a7490e8
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Due to the work done for b/156305599 ("Ensure no process except vold can
create directories like /data/system_ce/0"), the SELinux policy now
enforces that vold is the only process that can write to directories
that contain per-user encrypted subdirectories. This is essential to
prevent bugs where directories that are supposed to be encrypted get
created too early so are not actually encrypted as intended.
However, this only works when SELinux is in enforcing mode. When
SELinux is in permissive mode, only DAC is enforced, and the file modes
allow other processes to write to many of these directories. That
allows system_server to break things once again.
Therefore, remove the write bit from the file modes so that write access
is always denied to processes that don't have CAP_DAC_OVERRIDE. This is
not as strong a restriction as the SELinux policy, which still applies
independently, but it does keep out system_server by itself.
Also remove the sticky bit from /data/misc_ce and /data/misc_de, since
there is no reason for it. (It probably was originally copied from
/data/misc, which might need it. But misc_{ce,de} don't need it.)
Bug: 285239971
Test: Booted Cuttlefish
Change-Id: I1213a4d18c5f851acf213d786400d79d73777ed0
It's necessary to have the right dalvik.vm.* flags in place when they
are validated by odrefresh.
Test: See the other CL in the topic.
Bug: 281850017
Ignore-AOSP-First: Will cherry-pick to AOSP later
Change-Id: Ib64790dde97faaa6b62ead2c1c8dd53c97f97f9c
Merging as a separate CL due to a log showing up
related to this on hwasan (is a prebuilt pulling
this in?)
Bug: 276813155
Test: boot cf
Change-Id: I19f7fc51c937d0eb1ee17781fc5d201a0972c4b0
Bionic requires random numbers to init the shadow call stack. Those
numbers are obtained via the syscall getrandom (non-blocking) and will
fallback to /dev/urandom if the former fails.
When loading pKVM modules, we are so early in the boot process that the
only source of entropy for the linux RNG are the architecture random
number generators... which might be available on some platforms. Without
any source of entropy, the only way of generating a random number is to
try to generate some, which is what the bionic fallback expects via
urandom.
As a consequence, add the urandom node to the initramfs.
Bug: 274876849
Merged-In: I111e2db53fabd63d070b8e9ab9c52faebf484ab3
Change-Id: I34a0e3f7c72de7344512366d4a96183b445edc2e
Bionic requires random numbers to init the shadow call stack. Those
numbers are obtained via the syscall getrandom (non-blocking) and will
fallback to /dev/urandom if the former fails.
When loading pKVM modules, we are so early in the boot process that the
only source of entropy for the linux RNG are the architecture random
number generators... which might be available on some platforms. Without
any source of entropy, the only way of generating a random number is to
try to generate some, which is what the bionic fallback expects via
urandom.
As a consequence, add the urandom node to the initramfs.
Bug: 274876849
Change-Id: I164b08f026a238dad9f27a345bdef96717f2aa74
Set the user explicitly.
For boringssl self-test, changed to 'nobody' since
this test doesn't require permissions.
Bug: 276813155
Test: boot, check can 'nobody' can still write to kmesg.
Change-Id: I32f7134e83183bd054bffbb22d412d7a2dc0ad09
There are multiple use cases in Android for which background writes need
to be controlled via the cgroup mechanism. The cgroup mechanism can only
control background writes if both the blkio and memcg controllers are
mounted in the v2 cgroup hierarchy. Hence this patch that migrates the
blkio controller from the v1 to the v2 cgroup hierarchy.
The blkio controller has been marked as optional since not all Android
kernels enable this controller (CONFIG_BLK_CGROUP).
This patch increases the TOTAL_BOOT_TIME for devices with a 4.19 kernel
(redfin) from 18.9 s to 20 s. This patch does not affect the boot time
for devices with a 5.10 or 5.15 kernel.
This patch increases the time spent in CgroupMap::ActivateControllers()
by 25 microseconds in Cuttlefish on an x86-64 CPU.
CgroupMap::ActivateControllers() is called by Service::Start().
Bug: 213617178
Test: Cuttlefish and various phones
Change-Id: I3c07c1be84c3feb277b7d7003652d5d3b57c6541
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Bug: 260366497
Bug: 264600011
Test: The correct label is assigned to dir after taking reboot
Test: Both system_server and dumpstate can access it
Change-Id: Icecbb59ddf936088aa3873bf1b143a08f035fefe
Added SPDX-license-identifier-Apache-2.0 to:
rootdir/Android.mk
Bug: 68860345
Bug: 151177513
Bug: 151953481
Test: m all
Change-Id: I19aaea76a932cc928bbc178c01a33fdc98b0cf16
Grant read/write access to anyone for /data/misc/wmtrace folder on
debuggable builds, it's further protected by the selinux policy.
This is to allow systemui process to write proto logs to the same folder
on device as WindowManager, both can contribute to the transitions like
PiP, Split-Screen and etc.
Bug: 251513116
Test: adb shell dumpsys activity service SystemUIService \
WMShell protolog [start | stop]
Change-Id: Ice57efa17c61d132b02c0a11a762c24d772bd90a
This file contains a description of dev nodes added to the CPIO archive
for the Android ramdisks. /dev/null is a security requirement for
bionic, /dev/console is needed so the kernel can set-up stdout stderr
and stdin before running /init.
Bug: 254835242
Change-Id: I111e2db53fabd63d070b8e9ab9c52faebf484ab3
A critical shutdown service is one that stays on right until the system
is rebooted. In order to be able to capture kernel messages right until
reboot this is required, otherwise after the console service is
terminated some messages can be lost.
Test: Reboot and verify messages show up on serial further down the reboot process
Change-Id: Iea58b5a76afe45b3346803021e3be81742b02ea0
