Allow ueventd configuration to specify what to do with
devices based on driver. This responds to bind events and
treats them similarly to add events.
The format of the driver stanza is exactly the same as
that of the subsystem stanza.
Bug: 376900376
Test: set up cbc_mbim driver stanza and ensure it properly
creates and destroys device nodes when a USB device with
that driver appears and disappears or is bound and unbound
Change-Id: I31f5c91bd074d14075b74fe7beefaa6ac07a7ac9
NVME devices have a subsystem of "class/nvme". Add that to the list of
subsystems we check so we can identify them properly.
Bug: 316324155
Test: Boot on a device with nvme
Change-Id: I2ab3f6890f62f525dba150a0368c666a1c4c875e
Now that FindPlatformDevice() isn't modifying the path argument, and
is just passing it on to FindSubsystemDevice(), take this argument by
const reference. That should avoid an unnecessary string copy.
Bug: 316324155
Test: Compile
Change-Id: I1d92a322d0c311ee46a117dd9d650896ec02520f
The current code waits for boot partitions to show up by waiting to
see a uevent with the right partition name. However, nothing in the
waiting code validates that the partition that showed up is actually
on the boot device. That means that the current code can be confused
if there is another block device in the system (possibly connected via
USB) that has a partition name matching one of the system ones.
It can be noted that the problem is specifically just that the
"waiting" part returns too early. Later parts of the system,
specifically the parts of the system that create the
"/dev/block/by-name" symlinks, do properly look at the list of "boot
devices". This means that the problem we're fixing is that later code,
which assumes that the boot partitions have already initialized, can
fail to find an initialized partition.
To make it concrete, imagine that you have two block devices in your
system: the builtin emmc and an external USB disk. Let's say you're
booting over USB and "boot_devices" properly lists only USB. Both the
"emmc" and "USB" block devices are properly formatted Android disks
and have the full slew of partitions. At boot time, you can see:
1. We get to the point where we need to wait for the "boot" source
(USB) to show up.
2. We see the eMMC show up.
3. The eMMC has all the needed partitions, so we consider our wait
done. ...but eMMC isn't in the list of "boot devices" so we don't
create the "/dev/block/by-name" symlinks.
4. Later code assumes that the "/dev/block/by-name" symlinks are
already setup and fails.
5. The device fails to boot.
Fix it so that the wait makes sure that the partitions are on the boot
device.
Unfortunately, it appears that in some cases products (especially
emulators) aren't setting the "boot devices" and/or are not making
sure all boot partitions are on the same device. Limit the fix to only
devices using the new "boot_part_uuid" to make sure we don't break old
code.
NOTE: this is effectively the same change as a previous one ("init:
Look for super partition only on a boot device") but with the added
fix to only enable the check when using "boot_part_uuid".
Bug: 309244873
Bug: 349144493
Bug: 316324155
Test: Boot isn't confused when two boot devices are present
Change-Id: Iaae453ed661307f485cdf4dde86294105cae9b2d
The current mechanism for specifying boot devices on Android systems
involves passing a set of "boot_devices" though command line,
bootconfig, or device tree.
The bootdevices are specified as strings and, in general, need to
match a sysfs path but without the "/sys/devices" or
"/sys/devices/platform" prefix. The sysfs path is generally the path
to the closest parent of the block device that is a "platform" device.
As an example, if the sysfs path of the expected boot device is:
/sys/devices/platform/soc@0/7c4000.mmc/mmc_host/mmc1/mmc1:0001/block/mmcblk1
The bootloader would specify it as "soc@0/7c4000.mmc" since:
* We strip off "/sys/devices/platform/"
* As we move up directories, we don't find one whose subsystem is
"platform" until we get up to
"/sys/devices/platform/soc@0/7c4000.mmc".
The current mechanism is a bit brittle. Specifically:
* The sysfs path isn't _really_ stable and can change across kernel
upgrades. For instance, during one kernel upgrade the device tree
for a product changed so that the root node changed from "soc" to
"soc@0" and this changed all sysfs paths. In the past device tree
folks have asserted that we shouldn't rely on dts node names to stay
consistent, yet those node names are used to construct sysfs paths.
* For some devices, like USB, the path of the closest "platform"
device tends to be the path of the USB controller. This means that
if two USB disks are plugged in we can't guarantee which one will be
identified as the boot device.
Add a new method of finding the boot device by passing the partition
UUID that we loaded the kernel from. Using the partition UUID to
identify the boot device is standard on Linux. You can see this
because when you're not using an initramfs you can use the syntax
"root=PARTUUID=<valid-uuid-id>[/PARTNROFF=n]" to specify the root.
Using the same idea for Android's boot code makes sense.
With this new method for finding the boot device, we can make the code
much more specific about matching sysfs paths. Once we find the sysfs
path for the kernel we can make sure that all of the other boot
partition share the same "scsi" or "mmc" parent instead of going all
the way to the closest platform device. In the above example, this
means that we'd make sure that all boot devices are found under this
sysfs node:
/sys/devices/platform/soc@0/7c4000.mmc/mmc_host/mmc1/mmc1:0001/block/mmcblk1
...instead of just making sure they are under:
/sys/devices/platform/soc@0/7c4000.mmc
There is the question of what we should do if the bootloader passes
_both_ an old style "boot_devices" and also a partition UUID. In this
case, we'll issue a warning and then ignore the old "boot_devices".
Considering it a warning rather than an error could allow switching to
the "boot_part_uuid" method even if an old bootloader is still
hardcoding some old "boot_devices".
NOTE: Using partition UUID won't cause any security problems even
though someone _could_ plug in an external device crafted to have the
same UUID as the normal boot device's kernel partition. We already
have "verity" in the system making sure our filesystems are not
tampered with and this would also protect us from booting a tampered
disk. That means that the worst someone could do in this case would be
to confuse the system and make the device non-bootable. Chromebooks
have been using the partition UUID to find the root filesystems for
years and this has never been a problem.
NOTE: this new method relies on the commit ("init: Add partition_uuid
to Uevent") which in turn relies upstream kernel commit 74f4a8dc0dd8
("block: add partition uuid into uevent as "PARTUUID"").
Bug: 316324155
Test: Use partition UUID to boot
Change-Id: If824cb700ca3696a442a28e6ad02d7c522c3b495
We want to use the logic for FindPlatformDevice() in a future change
to look for devices that have USB parents. Break out a helper
function.
This change is intended to be a no-op and just a reorganization.
Bug: 316324155
Test: See boot devices still found
Change-Id: Ic5a57a89339c43dea1334644be9386637169c61c
Later code will want to use GetBlockDeviceInfo(), so factor it out to
a helper function. This change is intended to be a no-op.
Bug: 316324155
Test: Build & boot
Change-Id: If5d63f39efcd84a07eb8c6fa4f28bda45c4cbe5c
This reverts commit 5bfb93678f.
Reason for revert: b/376468452 and trusty boot up on arm64. This CL is causing a lot of troubles (now only on emulator, but may affect more devices in field) and shall be reverted. Desktop team will handle support for selecting single boot source (while having more than one) as part of boot_part_uuid support (at aosp/3318438).
Change-Id: I2804c119631f592d0862f3472ffe18dbb23b17e5
This reverts commit 8d71220df2.
Reason for revert: Fix for gcar emulator (basically all QEMU-based emulators) landed at aosp/3315253 and aosp/3160116.
Change-Id: If4eddd3f7e224c31019ad3bd752e2375c7567780
Init code is bailing out as soon as `super` partition was
found in the system, ignoring rest of uevents.
In case given device contains multiple boot sources, `super`
partition as well as all other partitions shall be taken
from the same boot source, instead of relying on
`which uevent came first`.
Bug: 309244873, 349144493
Test: Plug secondary USB boot device to device that supports multiple
boot sources. Select boot from USB. Device boots properly.
Signed-off-by: Jan Dabros <dabros@google.com>
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Change-Id: I70eb7d4223258ec273faa523cb67ddab0b7c32a0
Make all member functions private that are not called from outside
DeviceHandlermember functions.
Bug: 335708738
Change-Id: Ibe2e5f6b8b45a79b5be59665627e0a46de4e439a
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
This change introduces a new mode to `subsystem.devname` in `ueventd.rc`
configuration files, which sets the file name to the contents of
`/sys/DEVNAME/name`.
The objective of this change is to help Cuttlefish distinguish between
console devices, which are only different in uevents by initialization
order. Cuttlefish currently relies on `/dev/hvc##` devices which are
created for non-multiport virtio-console devices.
https://cs.android.com/android/platform/superproject/main/+/main:device/google/cuttlefish/shared/config/ueventd.rc;l=18;drc=5204f119d859d3ae5f1a2ee1c6a05ee68d6a28ed
On Cuttlefish we're considering moving to multiport virtio-console
devices ( https://fedoraproject.org/wiki/Features/VirtioSerial ). It
would be possible to rely on device order here as well, but using names
to distinguish devices makes it possible to drop unused devices in the
future, rather than reserving indexes indefinitely.
Multiport virtio-console devices create uevents with DEVNAME=vport#p#
and DEVPATH=.../vport#p#, only exposing the name in a sysfs file.
Bug: 336663898
Test: Attach multiport console, run with `-DLOG_UEVENTS=1`
Test: Introduce ueventd policy using `devname sys_name`
Change-Id: I59632b556db4a47883eab97e90c0e6ca81a9c650
Allow mapping of raw block devices (those without a partition table)
to partition names for first stage mount and ueventd. For example, a
block device `vdb` that contains only an ext4 metadata partition could
be mapped to `metadata` such that /dev/block/by-name/metadata is
created.
The mapping is provided by the `androidboot.partition_map` bootconfig
or kernel command line parameter.
Bug: 159943320
Test: boot with raw vdb,metadata;vdc,userdata partitions
Change-Id: Ib6a939d6fb88b85c46c81d613425a127627a734b
If a `*` appears within (but not at the end) of a /dev or /sys path in
a ueventd.rc file, then that path is matched with fnmatch() using the
FNM_PATHNAME, which means `*` will not match `/`. That is not always
the intended behavior and this change creates the no_fnm_pathname
option, which will not use the FNM_PATHNAME flag and will have `*`
match `/`.
Bug: 172880724
Test: these unit tests
Change-Id: I85b813d89237dbf3af47564e5cbf6806df5d412f
We want ashmem to only be used via libcutils API, with long-term goal
being deprecation of ashmem with memfd. To do that we route libcutils to
a new source of ashmem fds. We then phase out uses of /dev/ashmem that
doesn't go through libcutils using SELinux.
In Q, we introduced ashmemd as the source of ashmem fds to libcutils.
However, having a separate process and, consequently, binder hops to
handle /dev/ashmem results in performance/memory overhead.
To address the overhead, replace ashmemd with a duplicate of
/dev/ashmem. Name it /dev/ashmem<boot_id>, where boot_id is a random
number generated on each boot. This way we make sure that developers
don't accidentally depend on /dev/ashmem<boot_id>, as that name can't be
hardcoded.
Bug: 139855428
Test: writing "add"/"remove" to /sys/class/misc/ashmem/uevent correctly
adds/removes /dev/ashmem and /dev/ashmem/boot_id
Change-Id: I36d23116048bfcd99903ba46cc133161835a2cfa
Some devices have modules.alias and modules.dep for modprobe and other
purposes but do not want to opt into ueventd auto loading their
modules. Therefore we add a flag that can be added to ueventd
configuration files to opt into this behavior.
Bug: 111916071
Bug: 112048758
Test: check that modules are loaded with this opt-in
Test: check that modules are not loaded without this opt-in
Change-Id: Ifb281b273059b4671eea1ca5bc726c9e79f3adfb
Since some vendors will have firmware in mount points in
/mnt/vendor/..., we extend the ueventd script language to allow
specifying the firmware directories.
Also, move the existing 4 directories to ueventd.rc as a primary user
of this mechanism.
Bug: 111337229
Test: boot sailfish; firmwares load
Change-Id: I0854b0b786ad761e40d2332312c637610432fce2
During uevent processing, some "by-name" symlinks will be created.
/dev/block/<type>/<device>/by-name/<partition>
<type> can be: platform, pci or vbd.
<device> might be: soc.0/f9824900.sdhci, soc.0/f9824900.sdhci, etc.
<partition> might be: system, vendor, system_a, system_b, etc.
e.g., on a non-A/B device:
/dev/block/platform/soc.0/f9824900.sdhci/by-name/system
/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
On a A/B device:
/dev/block/platform/soc/1da4000.ufshc/by-name/system_a
/dev/block/platform/soc/1da4000.ufshc/by-name/system_b
/dev/block/platform/soc/1da4000.ufshc/by-name/vendor_a
/dev/block/platform/soc/1da4000.ufshc/by-name/vendor_b
However, those symlinks are "device-specific".
This change adds the "generic" symlinks in ueventd, in addition to
the existing symlinks, when the possible "boot devices" are specified
in device tree. e.g.,
&firmware_android {
compatible = "android,firmware";
boot_devices ="soc/1da4000.ufshc,soc.0/f9824900.sdhci";
}
The following symlinks will then be created on the aforementioned non-A/B
and A/B devices, respectively.
/dev/block/by-name/system
/dev/block/by-name/vendor
/dev/block/by-name/system_a
/dev/block/by-name/system_b
/dev/block/by-name/vendor_a
/dev/block/by-name/vendor_b
Note that both <type> and <device> are skipped in the newly create symlinks.
It assumes there is no more than one devices with the same <partition>,
which is the assumption of current first stage mount flow.
Finally, when 'boot_devices' in DT is absent, it fallbacks to extract
'boot_devices' from fstab settings. e.g., using 'soc/1da4000.ufshc',
'soc.0/f9824900.sdhci' for a fstab with the following content:
/dev/block/platform/soc/1da4000.ufshc/by-name/system
/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
Bug: 78613232
Test: adb shell ls /dev/block/by-name
Change-Id: Iec920b5a72409b6a2bdbeeb290f0a3acd2046b5d
1) Check subsystems list before doing usb subsystem logic. This allows
developers to handle usb* subsystems in ueventd.rc files.
2) Fix a bug where each subsystem_ instance is not reinitialized, but
rather only the name_ member was set.
Test: boot bullhead
Test: check that multiple uevent_devname subsystems work when
specified in ueventd.rc
Change-Id: Ifcac04763afcaf72a3b14ef5f3a6cb89981b51a1
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
While refactoring ueventd, I was looking for code the character device
symlinks (/dev/usb/*) that ueventd creates, such that I could test it
on a real device. I found none in our tree, and history showing Xoom,
which was last supported years ago, was the last user. If this code
is in fact obsolete, let's remove it.
Test: boot bullhead
Test: init unit tests
Change-Id: I601f7165eb06d36b31b6dcf69ee9e0a449d81a96
In order to create symlinks for USB and block devices, the path for
their parent platform device must be known.
Previously, ueventd would save each platform device that it encounters
to a list and query this list when creating the symlinks. That,
however, is racy because the uevent socket does not differentiate
uevents from RegenerateUevents() and uevents sent by the kernel when
probing a device first the first time. The below scenario is the
faulty case:
1) Kernel probes parent platform device for a block device
2) ueventd calls RegenerateUevents() and starts processing uevents
3) Kernel probes block device and sends its uevents
4) ueventd picks up the block device uevent during its uevent processing,
without yet regenerating the platform device uevent, causing improper
symlinks to be created.
This change stops storing the platform devices in a list, and instead
traverses up the directory structure for each USB or block device
until it reaches a platform device, defined as one whose subsystem is
the platform bus. This fixes the race and simplifies the ueventd
code.
Bug: 62436493
Bug: 62681642
Test: Boot bullhead
Test: Boot sailfish
Test: Init unit tests
Test: Boot hikey + hotplug/unplug sdcard
Change-Id: I21636355d8e434f30e0cba568598a6cf139e67f9
fork() subprocesses to handle uevents in parallel.
This reduces coldboot time on bullhead from ~446ms to ~230ms.
This reduces coldboot time on sailfish from ~690ms to ~360ms.
This reduces coldboot time on ryu from ~187ms to ~122ms.
Bug: 33785894
Test: boot bullhead x40, observe no major differences in /dev and /sys
Test: boot sailfish x40, observe no major differences in /dev and /sys
Test: boot ryu x40, observe no major differences in /dev and /sys
Test: boottime tests on bullhead and sailfish
Test: init unit tests
Change-Id: Ie2f63e000b8af78d187477d31fe109f20304d749
devices.cpp handles too many things for creating one class. This
change breaks it up into various files and classes.
* Parsing is moved to ueventd_parser.cpp
* Reading from the uevent socket and Cold booting is moved to a
UeventListener class, in uevent_listener.cpp
* Firmware handling is moved to firmware_handler.cpp
* The remaining contents form a DeviceHandler class within devices.cpp
Bug: 33785894
Test: boot bullhead x40, observe no major differences in /dev and /sys
Test: boot sailfish x40, observe no major differences in /dev and /sys
Test: init unit tests
Change-Id: I846a2e5995fbb344c7a8e349065c18a934fa6aba
Previously init_parser.cpp was made generic and capable of parsing any
number of differently named 'sections' or prefixed lines. We now use
these capabilities to do the parsing for ueventd.
Bug: 36250207
Bug: 33785894
Test: boot bullhead and ensure the right /dev nodes exist
with the right permissions set
Test: verify no boot time difference
Change-Id: I698ca962d414f8135af32f6c9cd778841b2b8b53
Create classes for dev and sys permissions and store these permissions
in std::vector instead of the C list.
Test: boot bullhead
Test: init unit tests
Change-Id: I874039a3db29b4c70149506da8e407123ab7eca2
Also simplify this code a bit.
There's only one consumer that removes the /devices/platform prefix,
so have them handle it instead of storing two copies of the string.
Remove an unneeded search for '/' in get_character_device_symlinks()
as a / will always be the next character after a parent path, by
nature of FindPlatformDevice().
Test: boot bullhead
Test: init unit tests
Change-Id: I9d0482d137b1342ae7509ae993ff99198be814f0
Additionally replace the associated C string parsing with C++ and write
unit tests.
Bug: 33785894
Bug: 36250207
Test: Boot bullhead + unit tests
Change-Id: Iee1f72d248bca3bd2e1227045628935b3dd6195a
Remove includes of "log.h" that really want <android-base/logging.h>
Fix header include order
Remove headers included in .cpp files that their associated .h already includes
Remove some unused headers
Test: boot bullhead
Change-Id: I2b415adfe86a5c8bbe4fb1ebc53c7b0ee2253824
This is done by parsing 'androidboot.fstab=<fstab>' kernel cmdline
option to get the fstab file that *only* specifies partitions to be
mounted early (i.e. in init's first stage).
Note that, the same fstab file may not be used as an argument to
mount_all later in the boot as that will cause fs_mgr to fail with
EBUSY.
TODO:
- Possibly add a new mount_mode so the same fstab can be used for
early_mount, 'mount_all --early/--late' etc.
- Add support for dm-verity enabled partitions to mount early.
- Add support for getting fstab arguments through DT instead of kernel
cmdline.
Bug: 27805372
Test:
Boot angler by passing a seperate fstab file using the kernel
cmdline option to mount vendor partition early, remove the vendor
partition entry from the main fstab file for the test.
Boot sailfish by passing a seperate fstab entry via device tree
to mount vendor partition early. Remove vendor partition entry from
the main fstab file for the test
Change-Id: I18785b893c54c8cee960ab44d5e8f83e5d624aa8
Signed-off-by: Sandeep Patil <sspatil@google.com>
keeps parts of the code that are still needed for the fs_mgr
+ dt based implementation
b/27805372
Test: boot angler, sailfish without regressions
Change-Id: I1b08f8b7b4f2e67118d328443a5011c0f5ead919
Signed-off-by: Sandeep Patil <sspatil@google.com>
We don't want to spend time creating devices that are unncessesary
during early (init first-stage) mount. So, refactor the devices code
tha allows us to call into coldboot and has the
- ability to only create devices that are specified by the caller
- ability to stop coldboot cycle when all devices that the caller is
interested in
- ability to run coldboot for a specific syspath
- ability to run ueventd code unmodified
Test: Tested boot on angler, sailfish
Change-Id: Id8f3492380696760414eadc20d624d300c904f8e
Signed-off-by: Sandeep Patil <sspatil@google.com>
Right now these two partitions are mounted in the fs stage of the init
process. As a result, many vendor/ODM files needed earlier in the boot
process (e.g., init.<hardware>.rc, fstab.<hardware>.rc,
uevent.<hardware>.rc, SELinux policy files etc) can only live on the root
partition.
To prevent vendors/ODMs from polluting the root partition, this patch makes
it possible to mount the vendor and ODM partitions in the first stage of the
init process. The fstab info of both partitions to be mounted early is
composed from new kernel cmdline arguments android.early.prefix and
android.early.fstab.
For example, with:
android.early.prefix=/sys/devices/1010000.msdc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/
android.early.fstab=mmcblk0p10+/odm+ext4+ro+verify\nmmcblk0p09+/vendor+ext4+ro+verify
the final fstab string will be:
/sys/devices/1010000.msdc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p10 /odm ext4 ro verify
/sys/devices/1010000.msdc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p09 /vendor ext4 ro verify
The android.early.prefix is optional. When it is missing, the final fstab
string will be directly converted from android.early.fstab.
This patch also makes sure that the early mounted partitions are dm-verity
enabled so that they are trust worthy to store system files.
BUG=27805372
Change-Id: I3cf32482a5ec65445ba3aedab2164c7ba8f12694
The sysfs nodes can change from devices to devices for
a particular class of peripheral. Some of them even change
after suspend/resume, e.g. rfkill for USB bluetooth adapters.
This patch adds to the way how ueventd rules with wildcard are
handled. In addition to matching the prefix with a trailing
wildcard, now rules can have wildcard anywhere in the rule.
The wildcard matching is implemented using fnmatch(), where
its matching is simliar to shell pathname expansion. It suits
this particular usage model well. To avoid abuse, the number of
slashes has to match between path name and the rule.
For example, instead of creating a rule to match:
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/rfkill*
, this would suffice:
/sys/devices/pci0000:00/0000:00:1d.0/*/*/*/*/bluetooth/hci0/rfkill*
The prefix matching behavior is retained, such that those
rules do not have to pay for processing penalty with fnmatch().
Change-Id: I3ae6a39c838f6d12801cb71958e481b016f731f5
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This should be much nicer than peppering init.rc with chown/chmod
directives.
Also, remove some dead code and obsolete comments.
Change-Id: I10895f10a9cf2f1226c8d12976cd3db3743da9ec
