summaryrefslogtreecommitdiffstats
path: root/src/veritysetup (follow)
Commit message (Collapse)AuthorAgeFilesLines
* various: check meson feature flag earlyMike Yuan2024-11-131-2/+4
| | | | Prompted by https://github.com/systemd/systemd/pull/35110#discussion_r1835885340
* veritysetup-generator: remove unused codeAntonio Alvarez Feijoo2024-10-241-9/+0
|
* hexdecoct: make unbase64mem and unhexmem always use SIZE_MAXMike Yuan2024-01-082-4/+4
|
* tree-wide: port various parsers over to read_stripped_line()Lennart Poettering2023-10-171-5/+4
|
* tree-wise: drop unnecessary use of proc_cmdline_key_streq()Yu Watanabe2023-08-081-3/+5
| | | | | | | If the key does not contain '-' or '_', then it is not necessary to use proc_cmdline_key_streq(), and streq() is sufficient. This also adds missing assertions about 'key' argument.
* meson: move declarations of cryptsetup and friendsYu Watanabe2023-07-311-0/+15
|
* veritysetup: remove double escaping of data device + hash device specLennart Poettering2023-06-011-1/+1
| | | | | | generator_write_veritysetup_service_section() already escapes the parameters internally, doing so in the caller means double escaping, which is a bug. Fix it.
* veritysetup: minor renaming of functionsLennart Poettering2023-06-011-5/+10
| | | | | | | | | | | | create_device() and create_disk() so far did very similar things, but the name didn't give a hint what the difference was. Hence let's rename them to create_special_device() and create_veritytab_device() to make this more understandabe, as one creates /proc/cmdline specified roothash=/usrhash= devices, and the other one devices for items listed in /etc/veritytab. No code changes besides renaming.
* {crypt|verity}setup: mention volume name in some error messagesLennart Poettering2023-06-011-4/+4
|
* {crypt|verity}setup: replace dep on systemd-tmpfiles-setup-dev.service by ↵Lennart Poettering2023-06-011-4/+5
| | | | | | | | | | | | modprobe@loop.service Both should have the same effect: the /dev/loop-control devices should become available. systemd-tmpfiles-setup-dev.service creates the device node "dry" based on modalias data, while modprobe@loop.service creates it fully, because the module backing it is loaded properly. This should shorten the deps chain a bit, simplify things and allows us to focus on the stuff we actually need (i.e. the loopback infra) instead of all entrypoints anyone might possibly need (i.e. the device nodes)
* veritysetup-generator: only generate one set of deps on ↵Lennart Poettering2023-06-011-17/+14
| | | | | | | | | | systemd-tmpfiles-setup-dev.service If both the data and the hash device are a regular file we might create two sets of deps on s-t-s-d.s, which is of course redundant. Shorten the code to only generate this once. No change in behaviour.
* veritysetup-generator: imply x-initrd.attach for "usr" and "root" volumesLennart Poettering2023-06-011-11/+21
| | | | Similar to the previous commit, just vor Verity rather than LUKS.
* veritysetup-generator: use generic veritysetup writers at one more placeLennart Poettering2023-06-011-46/+21
| | | | | | | | | | | | Let's use the common generator_write_veritysetup_unit_section(), ggenerator_write_veritysetup_service_section(), generator_add_symlink() implementation we already have at one more place. This mostly generates the same unit, but for the first time hooks up blockdev@dev-mapper-*.device for the device, which means things like growfs on usr+root volumes will actually work now. (I mean, growfs won#t, because verity devices are immutable after all, but things *like* it that want to run between the device popping up and being mounted.)
* veritysetup: add support for fec optionsGaël PORTAY2023-04-131-0/+47
| | | | | | | | | | | | | | The verity fec_* parameters allows to use Forward Error Correction to recover from corruption if hash verification fails. This adds the options fec_device, fec_offset and fec_roots (sixth argument) which are the equivalent of the options --fec-device, --fec-offset and --fec-roots in the veritysetup world. - fec-device=FILE - fec-offset=BYTES - fec-roots=UINT64 See `veritysetup(8)` for more details.
* veritysetup: add support for superblock and underlying optionsGaël PORTAY2023-04-131-6/+132
| | | | | | | | | | | | | | | | | | | | | | | The verity parameter no_superblock allows to format/open an hash device without the superblock. However, the superblock data must be set to open the data-device. This adds the option superblocks (sixth argument) and all the underlying options which are implied to set the superblock manually if hash device has no superblock: - superblock=BOOL - format=NUMBER (hash version type, 0 for original ChromeOS, 1 for modern) - data-block-size=BYTES (max page-size, multiple of 512) - hash-block-size=BYTES (max page-size, multiple of 512) - data-blocks=BLOCKS (size of data-device in blocks) - salt=HEXSTR (salt used at format, max 256 bytes) - uuid=UUID - hash=STR (algorithm name for dm-verity used at format, default is sha256) See `veritysetup(8)` for more details.
* veritysetup: add support for hash-offset optionGaël PORTAY2023-04-131-2/+17
| | | | | | | | | | | The verity parameter hash_area_offset allows to locate the superblock in the hash device. It can be used to have a single device which contains both data and hashes. This adds the option hash-offset=BYTES (sixth argument) which is the equivalent of the option --hash-offset in the veritysetup world. See `veritysetup(8)` for more details.
* veritysetup: fix memory corruptionLennart Poettering2022-04-011-5/+11
| | | | | | | | | We must copy the option string, since in one case we are called with a pointer into dynamic memory that will be freed by the caller. As discussed here: https://github.com/systemd/systemd/pull/22908/files#r839394490 Follow-up for: #22908
* tree-wide: unify some code that looks for --help in the command lineLennart Poettering2022-03-311-4/+2
|
* veritysetup: do some superficial checking on volume nameLennart Poettering2022-03-311-0/+6
| | | | cryptsetup does this too, so let's better be safe here, too.
* veritysetup: mangle option strings like in cryptsetupLennart Poettering2022-03-311-2/+2
|
* veritysetup: give command line parameters proper namesLennart Poettering2022-03-311-15/+28
| | | | | | | | Accessing the various arguments always through argv[] is nasty, since it's not obvious what we are talking about here. Let's give things nice names. We did the same in cryptsetup a while back.
* veritysetup: fix parsing of root-hash-signature= optionZbigniew Jędrzejewski-Szmek2022-03-311-34/+17
| | | | | | | | | | The function was named confusingly and we managed to confused ourselves. The parameter was assigned incorrectly and then reassigned correctly in the caller. Let's simplify the whole thing by just saving the optarg param. I considered moving the unhexmemming and/or reading of the file to the parse function, but decided against it. I think it's nicer to parse all options before opening external files.
* veritysetup: fix typo (#22886)Gaël PORTAY2022-03-281-1/+1
|
* veritysetup: whitespace fixLennart Poettering2022-02-141-1/+1
|
* sd128: export sd_id128_to_uuid_string()Lennart Poettering2022-02-141-2/+2
| | | | | | | | | We expose various other forms of UUID helpers already, i.e. SD_ID128_UUID_FORMAT_STR and SD_ID128_MAKE_UUID_STR(), and we parse UUIDs, hence add a high-level helper for formatting UUIDs too. This doesn't add any new code, it just moves some helpers id128-util.[ch] → sd-id128.[ch], to make them public.
* veritysetup-generator: generate service for usr deviceMark Boudreau2021-11-191-54/+139
| | | | | | If 'usrhash' is present as a kernel command line parameter, generate a veritysetup service for usr. Also recognize systemd.verity_usr_* parameters.
* dm-verity: Remove usage of integrityTony Asleson2021-10-142-2/+2
| | | | | | There is a difference between dm-verity and dm-integrity. Remove usage of integrity from verity documentation in man pages and target files.
* tree-wide: port everything over to new sd-id128 compund literal blissLennart Poettering2021-08-201-3/+2
|
* man: describe veritysetup command syntaxZbigniew Jędrzejewski-Szmek2021-08-031-1/+1
| | | | It makes it easier to diagnose what the generated units actually do.
* veritysetup: print help for --help/-h/helpZbigniew Jędrzejewski-Szmek2021-08-031-1/+4
| | | | | In general our commands print help on --help, but here this would trigger the error that two arguments are needed. Let's make this more user-friendly.
* cryptsetup: explicitl set default log functions wherever neededLennart Poettering2021-06-011-0/+2
| | | | | | | Code using libcryptsetup already sets the global log function if it uses dlopen_cryptsetup(). Make sure we do the same for the three programs that explicitly link against libcryptsetup and hence to not use dlopen_cryptsetup().
* tree-wide: coccinelle fixesFrantisek Sumsal2021-03-181-1/+1
| | | | Another batch of fixes (mostly) generated by Coccinelle.
* tree-wide: enable colorized logging for daemons when run in consoleYu Watanabe2021-01-311-1/+1
| | | | It may be useful when debugging daemons.
* tree-wide: Drop custom formatting for print() help messagesDaan De Meyer2021-01-311-5/+4
| | | | | | | | | | | | I think this formatting was originally used because it simplified adding new options to the help messages. However, these days, most tools their help message end with "\nSee the %s for details.\n" so the final line almost never has to be edited which eliminates the benefit of the custom formatting used for printf() help messages. Let's make things more consistent and use the same formatting for printf() help messages that we use everywhere else. Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
* veritysetup-generator: drop unused struct and variableYu Watanabe2021-01-181-18/+2
| | | | | | | | Follow-ups for 08b04ec7e72b7327b4803809732b1b8fce8dd069. This also drops unnecessary inclusion. Fixes CID#1443889.
* veritysetup: remove unused globalsGaël PORTAY2021-01-151-6/+0
| | | | | | This removes the three global variables arg_root_hash, arg_data_what and arg_hash_what which were presents since the beginning but were never being used.
* veritysetup-generator: add support for veritytabGaël PORTAY2021-01-152-6/+230
| | | | | | | | | | | | | | | | | | | | | | | | This adds the support for veritytab. The veritytab file contains at most five fields, the first four are mandatory, the last one is optional: - The first field contains the name of the resulting verity volume; its block device is set up /dev/mapper/</filename>. - The second field contains a path to the underlying block data device, or a specification of a block device via UUID= followed by the UUID. - The third field contains a path to the underlying block hash device, or a specification of a block device via UUID= followed by the UUID. - The fourth field is the roothash in hexadecimal. - The fifth field, if present, is a comma-delimited list of options. The following options are recognized only: ignore-corruption, restart-on-corruption, panic-on-corruption, ignore-zero-blocks, check-at-most-once and root-hash-signature. The others options will be implemented later. Also, this adds support for the new kernel verity command line boolean option "veritytab" which enables the read for veritytab, and the new environment variable SYSTEMD_VERITYTAB which sets the path to the file veritytab to read.
* veritysetup-generator: add support for verity root optionsGaël PORTAY2021-01-151-4/+22
| | | | | | | | This adds support for a new kernel root verity command line option "verity_root_options=" which controls the behaviour of dm-verity by forwarding options directly to systemd-veritysetup. See `veritysetup(8)` for more details.
* veritysetup: add support for dm-verity optionsGaël PORTAY2021-01-151-7/+100
| | | | | | | | | | | | | | | This patch allows controlling the behaviour of dm-verity by reusing the fifth argument that was used to set the roothash signature. That argument is now a comma-separated list of dm-verity options in the given format: option[=value]. The option is the name of the long option in the world of veritysetup. See `veritysetup(8)` for more details. Note: The former ROOTHASHSIG the positional argument is now deprecated in favour of the option root-hash-signature=(base64:SIG|FILE). However, the previous format is maintained and a warning is logged.
* veritysetup: also place udev socket depLennart Poettering2020-12-101-1/+1
| | | | | In light of #17848, also place udev socket dep in veritysetup, it's the same issue after all.
* fileio: teach read_full_file_full() to read from offset/with maximum sizeLennart Poettering2020-12-011-1/+5
|
* license: LGPL-2.1+ -> LGPL-2.1-or-laterYu Watanabe2020-11-092-2/+2
|
* fileio: beef up READ_FULL_FILE_CONNECT_SOCKET to allow setting sender socket ↵Lennart Poettering2020-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | name This beefs up the READ_FULL_FILE_CONNECT_SOCKET logic of read_full_file_full() a bit: when used a sender socket name may be specified. If specified as NULL behaviour is as before: the client socket name is picked by the kernel. But if specified as non-NULL the client can pick a socket name to use when connecting. This is useful to communicate a minimal amount of metainformation from client to server, outside of the transport payload. Specifically, these beefs up the service credential logic to pass an abstract AF_UNIX socket name as client socket name when connecting via READ_FULL_FILE_CONNECT_SOCKET, that includes the requesting unit name and the eventual credential name. This allows servers implementing the trivial credential socket logic to distinguish clients: via a simple getpeername() it can be determined which unit is requesting a credential, and which credential specifically. Example: with this patch in place, in a unit file "waldo.service" a configuration line like the following: LoadCredential=foo:/run/quux/creds.sock will result in a connection to the AF_UNIX socket /run/quux/creds.sock, originating from an abstract namespace AF_UNIX socket: @$RANDOM/unit/waldo.service/foo (The $RANDOM is replaced by some randomized string. This is included in the socket name order to avoid namespace squatting issues: the abstract socket namespace is open to unprivileged users after all, and care needs to be taken not to use guessable names) The services listening on the /run/quux/creds.sock socket may thus easily retrieve the name of the unit the credential is requested for plus the credential name, via a simpler getpeername(), discarding the random preifx and the /unit/ string. This logic uses "/" as separator between the fields, since both unit names and credential names appear in the file system, and thus are designed to use "/" as outer separators. Given that it's a good safe choice to use as separators here, too avoid any conflicts. This is a minimal patch only: the new logic is used only for the unit file credential logic. For other places where we use READ_FULL_FILE_CONNECT_SOCKET it is probably a good idea to use this scheme too, but this should be done carefully in later patches, since the socket names become API that way, and we should determine the right amount of info to pass over.
* shared: rename crypt-util.c → cryptsetup-util.cLennart Poettering2020-09-021-1/+1
| | | | | | | | | | | "crypt-util.c" is such a generic name, let's avoid that, in particular as libc's/libcrypt's crypt() function is so generically named too that one might thing this is about that. Let's hence be more precise, and make clear that this is about cryptsetup, and nothing else. We already had cryptsetup-util.[ch] in src/cryptsetup/ doing keyfile management. To avoid the needless confusion, let's rename that file to cryptsetup-keyfile.[ch].
* tree-wide: enable/disable libcrypsetup debug output depending on our levelLuca Boccassi2020-08-141-2/+2
| | | | | Avoid always setting to debug, as it will incur in many more callbacks from libcrypsetup that then get discarded, wasting resources.
* tree-wide: use READ_FULL_FILE_CONNECT_SOCKET at various placesLennart Poettering2020-07-211-1/+1
| | | | | | | | | | | Let's use the new flag wherever we read key material/passphrases/hashes off disk, so that people can plug in their own IPC service as backend if they like, easily. (My main goal was actually to support this for crypttab key files — i.e. that you can specify AF_UNIX sockets as third column in crypttab — but that's harder to implement, since the keys are read via libcryptsetup's API, not ours.)
* veritysetup: add support for dm-verity root hash signatureLuca Boccassi2020-06-251-2/+25
| | | | | | | Since cryptsetup 2.3.0 a new API to verify dm-verity volumes by a pkcs7 signature, with the public key in the kernel keyring, is available. Use it if libcryptsetup supports it in the veritysetup helper binary.
* id128: introduce ID128_UUID_STRING_MAX for sizing UUID buffersLennart Poettering2019-12-101-1/+1
|
* tree-wide: replace strjoin() with path_join()Yu Watanabe2019-06-241-2/+3
|
* generators: define custom main func definer and use it where applicableZbigniew Jędrzejewski-Szmek2018-12-121-14/+4
| | | | | | | | | | There should be no functional difference, except that the error message is changd from "three or no arguments" to "zero or three arguments". Somehow the inverted form always seemed strange. umask() call is also dropped from run-generator. I think it wasn't dropped in 053254e3cb215df3b8c905bc39b920f8817e1c7d because the run generator was merged around the same time.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 14:38:00 +0100