this patches improves two areas:
1) it checks for keyslot areas overlaping each other
2) it checks if all keyslot areas fit in header area of device
(pre-data-offset area) or if it can fit file (detached header)
it's being loaded from. Those new checks are based on real data
found in header (offsets) rather than based on assumption calculated
from key length
Because there are already 3 targets used, the current detection
based only on dm-crypt is not sufficient.
Add new definition of dm_flags that allows separate target version detect.
Note: we do not want to load targets explicitly; instead, we repeats
detection after operation that could trigger target load.
If dm_flags() call fails, then the target is not yet loaded.
The dm-integrity target is intended to be used for authenticated
encryption through LUKS and dm-crypt.
It can be used in standalone as well; for this use case there
is a simple configuration utility called integritysetup
(similar to veritysetup to dm-verity).
It is possible to trigger a double free with an invalid verity
partition. All it takes is an unknown hash algorithm, which makes it
a bit more likely than a completely broken partition header. But all
it takes is an error return value of VERITY_read_sb() or strdup().
If crypt_load fails before setting cd->type, crypt_free will handle
the union as if it was of type "none", which means it will call free()
for "active_name", a field which is only properly set up when the
type was actually "none".
In all other cases, "active_name" contains the first 4 or 8 bytes of
the actually used header structure. Fortunately it can be only a
pointer or NULL, so an attacker has no direct control of the value.
Nonetheless it can easily trigger a double free.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Somehow testing in qemu resulted sometimes in an endless loop.
Either the timing or the settle fixed the issue.
When the VM was in an endless loop, an strace showed, that the first 512
and 1024 of the crypt partition was read over and over. Either it was
the udev blkid, or some device mapper udev rule.
Maybe the reencrypt tool opens and closes the device fd, where the close
triggers a udev blkid and causes the reencrypt tool to reread the device...
Anyhow.. with this settle the issue was not seen anymore.
This patch adds a udev rule, so that you can specify
rd.luks.reencrypt=<UUID> instead of rd.luks.reencrypt=<devname>
It also moves the job to the "settled" queue, which means, that it is
executed after udev has settled.
A finished hook prevents dracut-initqueue from exiting and lets it
finish the batched jobs. Without a "finished hook" and without
"root=<dev>" on the kernel command line, the reencrypt job would not be
executed.
Normally you want to reencrypt without a "root=<dev>" on the kernel
command and want to reboot after the reencrypt job is done.
This patch adds the missing "finished hook".
