summaryrefslogtreecommitdiff
path: root/src/cryptsetup
Commit message (Collapse)AuthorAgeFilesLines
* meson: move source file list for systemd-cryptsetupYu Watanabe2021-01-191-0/+21
|
* cryptsetup: use crypt_token_max if availableLuca Boccassi2021-01-053-3/+3
| | | | | | New API added upstream: https://gitlab.com/cryptsetup/cryptsetup/-/commit/8a12f6dc2c75f8fd0c4969fbdc421895eb418072
* cryptsetup: add support for workqueue optionsJonathan G. Underwood2020-12-231-0/+12
| | | | | | | | This commit adds support for disabling the read and write workqueues with the new crypttab options no-read-workqueue and no-write-workqueue. These correspond to the cryptsetup options --perf-no_read_workqueue and --perf-no_write_workqueue respectively.
* tree-wide: fix typoYu Watanabe2020-12-182-2/+2
|
* cryptsetup: add support for TPM2 unlocking of volumesLennart Poettering2020-12-173-4/+470
|
* cryptsetup: add fido2 supportLennart Poettering2020-12-173-4/+454
|
* cryptsetup: split up attach_luks_or_plain_or_bitlk() into smaller functionsLennart Poettering2020-12-171-180/+250
| | | | Just some refactoring.
* cryptsetup: read PKCS#11 key and token info from LUKS2 metadataLennart Poettering2020-12-173-13/+138
| | | | | | | | | | | | | | Optionally, embedd PKCS#11 token URI and encrypted key in LUKS2 JSON metadata header. That way it becomes very easy to unlock properly set up PKCS#11-enabled LUKS2 volumes, a simple /etc/crypttab line like the following suffices: mytest /dev/disk/by-partuuid/41c1df55-e628-4dbb-8492-bc69d81e172e - pkcs11-uri=auto Such a line declares that unlocking via PKCS#11 shall be attempted, and the token URI and the encrypted key shall be read from the LUKS2 header. An external key file for the encrypted PKCS#11 key is hence no longer necessary, nor is specifying the precise URI to use.
* cryptsetup: be more careful with erasing key material from memoryLennart Poettering2020-12-171-4/+5
|
* cryptsetup: split code that allocates udev security device monitor into its ↵Lennart Poettering2020-12-171-14/+28
| | | | own function
* cryptsetup: give command line parameters proper namesLennart Poettering2020-12-041-36/+45
| | | | | | | | It's highly confusing to reference the command line parameters via argv[] indexes. Let's clean this up, and introduce properly named local variables that make this easier to follow. No actualy code changes, just some renaming of variables.
* cryptsetup: modify keyfile search logic to use read_file_full() tooLennart Poettering2020-12-013-92/+44
| | | | | | | | Let's move the 3rd way how cryptsetup acquires key files to read_file_full() too. Since load_key_file()'s raison d'etre now is just the search path logic, let's rename the function to find_key_file().
* cryptsetup: port cryptsetup's main key file logic over to read_full_file_full()Lennart Poettering2020-12-011-5/+32
| | | | | | | | | | | | | | Previously, we'd load the file with libcryptsetup's calls. Let's do that in our own, so that we can make use of READ_FULL_FILE_CONNECT_SOCKET, i.e. read in keys via AF_UNIX sockets, so that people can plug key providers into our logic. This provides functionality similar to Debian's keyscript= crypttab option (see → #3007), as it allows key scripts to be run as socket activated services, that have stdout connected to the activated socket. In contrast to traditional keyscript= support this logic runs stuff out of process however, which is beneficial, since it allows sandboxing and similar.
* cryptsetup: port PKCS#11 code to read key file with read_full_file()Lennart Poettering2020-12-013-2/+19
| | | | | Now that we can read from offsets/with size, let's port the cryptsetup PKCS#11 key file logic over to read_full_file_full().
* cryptsetup: drop unnecessary bracketYu Watanabe2020-11-271-2/+1
|
* cryptsetup: use log_warning_errno() where we can, instead of log_warning()Lennart Poettering2020-11-251-4/+3
|
* cryptsetup: use strjoin() for concatenating stringsLennart Poettering2020-11-251-1/+2
|
* license: LGPL-2.1+ -> LGPL-2.1-or-laterYu Watanabe2020-11-096-6/+6
|
* Revert "units: add initrd-cryptsetup.target"Zbigniew Jędrzejewski-Szmek2020-10-271-10/+5
| | | | | | | | | | This reverts commit 6c5496c492a8d74e54d22bf8824160cab1e63c10. sysinit.target is shared between the initrd and the host system. Pulling in initrd-cryptsetup.target into sysinit.target causes the following warning at boot: Oct 27 10:42:30 workstation-uefi systemd[1]: initrd-cryptsetup.target: Starting requested but asserts failed. Oct 27 10:42:30 workstation-uefi systemd[1]: Assertion failed for initrd-cryptsetup.target.
* units: add initrd-cryptsetup.targetJonathan Lebon2020-10-211-5/+10
| | | | | | | | | | | | | | | | | | For encrypted block devices that we need to unlock from the initramfs, we currently rely on dracut shipping `cryptsetup.target`. This works, but doesn't cover the case where the encrypted block device requires networking (i.e. the `remote-cryptsetup.target` version). That target however is traditionally dynamically enabled. Instead, let's rework things here by adding a `initrd-cryptsetup.target` specifically for initramfs encrypted block device setup. This plays the role of both `cryptsetup.target` and `remote-cryptsetup.target` in the initramfs. Then, adapt `systemd-cryptsetup-generator` to hook all generated services to this new unit when running from the initrd. This is analogous to `systemd-fstab-generator` hooking all mounts to `initrd-fs.target`, regardless of whether they're network-backed or not.
* Merge pull request #16444 from oniko/luks-detached-headerLennart Poettering2020-10-211-59/+222
|\ | | | | Add support for detached LUKS header on kernel cmd line
| * cryptsetup-generator: Add support for header device in crypttabOndrej Kozina2020-09-251-2/+16
| |
| * cryptsetup-generator: add detached LUKS header supportOndrej Kozina2020-09-251-11/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for LUKS detached header device on kernel command line. It's introduced via extension to existing luks.options 'header=' argument beyond colon (see examples below). If LUKS header device is specified it's expected to contain filesystem with LUKS header image on a path specified in the first part of header specification. The second parameter 'luks.data' specifies LUKS data device supposed to be paired with detached LUKS header (note that encrypted LUKS data device with detached header is unrecognisable by standard blkid probe). This adds support for LUKS encrypted rootfs partition with detached header. It can also be used for initializing online LUKS2 encryption of data device. Examples: luks.data=<luks_uuid>=/dev/sdz luks.data=<luks_uuid>=/dev/vg/lv luks.data=<luks_uuid>=/dev/mapper/lv luks.data=<luks_uuid>=PARTUUID=<part_uuid> luks.data=<luks_uuid>=PARTLABEL=<part_uuid> luks.options=<luks_uuid>=header=/header/path:UUID=<fs_uuid> luks.options=<luks_uuid>=header=/header/path:PARTUUID=<part_uuid> luks.options=<luks_uuid>=header=/header/path:PARTLABEL=<part_label> luks.options=<luks_uuid>=header=/header/path:LABEL=<fs_label> luks.options=<luks_uuid>=header=/header/path:/dev/sdx luks.options=<luks_uuid>=header=/header/path:/dev/vg/lv The '/header/path' is considered to be relative location within filesystem residing on the header device specified beyond colon character
| * cryptsetup-generator: rename split_keyspec to split_locationspecOndrej Kozina2020-09-251-25/+25
| | | | | | | | To be used later not only for splitting key specifications
| * cryptsetup-generator: Add warn_uuid_invalid helperOndrej Kozina2020-09-251-3/+12
| |
| * cryptsetup-generator: rename and extend device mount helpers.Ondrej Kozina2020-09-251-18/+29
| | | | | | | | | | Those functions will be used later also for (u)mounting LUKS header devices.
| * cryptsetup-generator: use proper constant for uuid alphabetOndrej Kozina2020-09-251-1/+1
| |
* | tree-wide: assorted coccinelle fixesFrantisek Sumsal2020-10-092-6/+4
| |
* | Merge pull request #17154 from keszybz/crypttab-commasLennart Poettering2020-10-012-8/+5
|\ \ | |/ |/| Allow escaping commas in crypttab
| * fstab,crypttab: allow escaping of commasZbigniew Jędrzejewski-Szmek2020-09-251-1/+4
| | | | | | | | | | | | Fixes #17035. We use "," as the separator between arguments in fstab and crypttab options field, but the kernel started using "," within arguments. Users will need to escape those nested commas.
| * cryptsetup: upgrade log line for option parsing errorZbigniew Jędrzejewski-Szmek2020-09-241-1/+1
| | | | | | | | If we failed here, we would exit with only a debug message.
| * cryptsetup-generator: drop unused fstat()Zbigniew Jędrzejewski-Szmek2020-09-241-6/+0
| | | | | | | | The result stopped being used in 71e4e1258436e7e81d772aed52a02bb5d9c87cb8.
* | cryptsetup-generator: avoid magic value in ternaryJonathan Lebon2020-09-241-1/+1
| | | | | | | | | | | | | | | | | | `startswith` already returns the string with the prefix skipped, so we can simplify this further and avoid using a magic value. Noticed in passing. Co-authored-by: Lennart Poettering <lennart@poettering.net>
* | cryptsetup-generator: use "/proc/cmdline" as source when appropriateJonathan Lebon2020-09-231-4/+6
|/ | | | | | | | Right now, we always say `/etc/crypttab` even if the source was fully derived from the kargs. Let's match what `systemd-fstab-generator` does and use `/proc/cmdline` when that's the case.
* cryptsetup: generate the unit to umount keydev filesystemMichal Sekletár2020-09-111-6/+55
| | | | | | | | | | | | | | | | | | | | | | | | Previously we would call umount from ExecStartPost= of systemd-cryptsetup instance in order to get rid of the keydev mount (i.e. filesystem containing keyfile). Let's generate unit to handle umount. Making this symmetrical (both mount and umount of keydev are handled by units) fixes the problem with lingering keydev mounts. Motivation for the change is the issue where keydev mount would stay around even if device was successfully unlocked and mount is no longer needed. That could happen previously because when generator options are not prefixed with "rd." we run generators twice (e.g. rd.luks.key=...). In such case disk is unlocked in initramfs phase of boot (assuming the initrd image contains the generator and is able to handle unlocking of LUKS devices). After switchroot we however enqueue start job for systemd-cryptsetup instance (because units are regenerated second time) and that pulls in its dependencies into transaction. Later the main systemd-cryptsetup unit not actually started since it is already active and has RemainaAfterExit=yes. Nevertheless, dependencies get activated and keydev mount is attached again. Because previously we called umount from ExecStartPost= of systemd-cryptsetup instance the umount is not called second time and keydev filesystem stays lingering.
* Merge pull request #16635 from keszybz/do-not-for-each-wordLennart Poettering2020-09-091-10/+10
|\ | | | | Drop FOREACH_WORD
| * cryptsetup: use extract_first_word()Zbigniew Jędrzejewski-Szmek2020-09-091-10/+10
| |
* | tree-wide: define iterator inside of the macroZbigniew Jędrzejewski-Szmek2020-09-081-2/+1
|/
* shared: rename crypt-util.c → cryptsetup-util.cLennart Poettering2020-09-024-3/+3
| | | | | | | | | | | "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-6/+3
| | | | | Avoid always setting to debug, as it will incur in many more callbacks from libcrypsetup that then get discarded, wasting resources.
* tree-wide: avoid some loaded termsLennart Poettering2020-06-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | https://tools.ietf.org/html/draft-knodel-terminology-02 https://lwn.net/Articles/823224/ This gets rid of most but not occasions of these loaded terms: 1. scsi_id and friends are something that is supposed to be removed from our tree (see #7594) 2. The test suite defines an API used by the ubuntu CI. We can remove this too later, but this needs to be done in sync with the ubuntu CI. 3. In some cases the terms are part of APIs we call or where we expose concepts the kernel names the way it names them. (In particular all remaining uses of the word "slave" in our codebase are like this, it's used by the POSIX PTY layer, by the network subsystem, the mount API and the block device subsystem). Getting rid of the term in these contexts would mean doing some major fixes of the kernel ABI first. Regarding the replacements: when whitelist/blacklist is used as noun we replace with with allow list/deny list, and when used as verb with allow-list/deny-list.
* cryptsetup: pass selected mode to crypt_load() when doing LUKSLennart Poettering2020-06-091-2/+2
| | | | | | | | | | This doesn't fix anything IRL, but is a bit cleaner, since it makes sure that arg_type is properly passed to crypt_load() in all cases. We actually never set arg_type to CRYPT_LUKS2, which is why this wasn't noticed before, but theoretically this might change one day, and existing comments suggest it as possible value for arg_type, hence let's process it properly.
* cryptsetup: try to load bitlocker superblock only if requestedLennart Poettering2020-06-091-1/+1
| | | | | | | | | | | | | let's do automatic discovery only for our native LUKS/LUKS2 headers, since they are Linux stuff, and let's require that BitLocker to be requested explicitly. This makes sure cryptsetup without either "luks" nor "bitlk" in the option string will work. Right now it would fail because we'd load the superblock once with luks and once with bitlk and one of them would necessarily fail. Follow-up for #15979
* Add 'bitlk' option to mount Bitlocker drives with cryptsetup.Maxim Fomin2020-06-091-3/+17
|
* cryptsetup: support tmp= file system argumentLennart Poettering2020-05-262-9/+22
| | | | | | | | Let's catch up with Debian a bit more. This also changes the default from ext2 to ext4. Fixes: #952
* cryptsetup: fix minor indentation issueLennart Poettering2020-05-191-1/+1
|
* cryptsetup: optionally, see if empty password works for unlocking the file ↵Lennart Poettering2020-05-191-6/+44
| | | | | | | | | | | | | | | | | system This adds a new switch try-empty-password. If set and none of PKCS#11 or key files work, it is attempted to unlock the volume with an empty password, before the user is asked for a password. Usecase: an installer generates an OS image on one system, which is the booted up for the first time in a possibly different system. The image is encrypted using a random volume key, but an empty password. A tool that runs on first boot then queries the user for a password to set or enrols the volume in the TPM, removing the empty password. (Of course, in such a scenario it is important to never reuse the installer image on multiple systems as they all will have the same volume key, but that's a different question.)
* cryptsetup: fix minor memory leakLennart Poettering2020-05-191-2/+3
|
* cryptsetup: also check for /dev/hwrng as random device nodeLennart Poettering2020-05-191-2/+8
|
* cryptsetup: make sure to return EAGAIN on wrong tcrypt password tooLennart Poettering2020-05-191-6/+4
| | | | | | Only then we'll try again to ask the user for a password. Fixes: #12152
View Lorry Controller Status