ac1f3ad05f
Opening a verity device is an expensive operation. The kernelspace operations are mostly sequential with a global lock held regardless of which device is being opened. In userspace jumps in and out of multiple libraries are required. When signatures are used, there's the additional cryptographic checks. We know when two devices are identical: they have the same root hash. If libcrypsetup returns EEXIST, double check that the hashes are really the same, and that either both or none have a signature, and if everything matches simply remount the already open device. The kernel will do reference counting for us. In order to quickly and reliably discover if a device is already open, change the node naming scheme from '/dev/mapper/major:minor-verity' to '/dev/mapper/$roothash-verity'. Unfortunately libdevmapper is not 100% reliable, so in some case it will say that the device already exists and it is active, but in reality it is not usable. Fallback to an individually-activated unique device name in those cases for robustness. |
||
|---|---|---|
| .github | ||
| .lgtm/cpp-queries | ||
| .mkosi | ||
| catalog | ||
| coccinelle | ||
| docs | ||
| factory/etc | ||
| hwdb.d | ||
| man | ||
| modprobe.d | ||
| network | ||
| po | ||
| presets | ||
| rules.d | ||
| semaphoreci | ||
| shell-completion | ||
| src | ||
| sysctl.d | ||
| sysusers.d | ||
| test | ||
| tmpfiles.d | ||
| tools | ||
| travis-ci | ||
| units | ||
| xorg | ||
| .clang-format | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .lgtm.yml | ||
| .mailmap | ||
| .travis.yml | ||
| .vimrc | ||
| .ycm_extra_conf.py | ||
| azure-pipelines.yml | ||
| configure | ||
| LICENSE.GPL2 | ||
| LICENSE.LGPL2.1 | ||
| Makefile | ||
| meson_options.txt | ||
| meson.build | ||
| mkosi.build | ||
| NEWS | ||
| README | ||
| README.md | ||
| TODO | ||
| zanata.xml | ||
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.