dissect: avoid clobbering device-mapper error when activating verity

The device-mapper driver can return a wild variety of errors when trying
to activate the same dm-verity volume concurrently, as it might happen
with an image. There is a fallback logic in place, but the original
return code was clobbered when userspace signature check was added.
Add it back.

Follow-up for c2fa92e7e8
This commit is contained in:
Luca Boccassi
2023-10-09 15:56:37 +01:00
committed by Luca Boccassi
parent 3c1f396f69
commit ace07128ac

View File

@@ -2609,7 +2609,7 @@ static int do_crypt_activate_verity(
const VeritySettings *verity) {
bool check_signature;
int r;
int r, k;
assert(cd);
assert(name);
@@ -2639,20 +2639,23 @@ static int do_crypt_activate_verity(
if (r >= 0)
return r;
log_debug("Validation of dm-verity signature failed via the kernel, trying userspace validation instead.");
log_debug_errno(r, "Validation of dm-verity signature failed via the kernel, trying userspace validation instead: %m");
#else
log_debug("Activation of verity device with signature requested, but not supported via the kernel by %s due to missing crypt_activate_by_signed_key(), trying userspace validation instead.",
program_invocation_short_name);
r = 0; /* Set for the propagation below */
#endif
/* So this didn't work via the kernel, then let's try userspace validation instead. If that
* works we'll try to activate without telling the kernel the signature. */
r = validate_signature_userspace(verity);
if (r < 0)
return r;
if (r == 0)
return log_debug_errno(SYNTHETIC_ERRNO(ENOKEY),
/* Preferably propagate the original kernel error, so that the fallback logic can work,
* as the device-mapper is finicky around concurrent activations of the same volume */
k = validate_signature_userspace(verity);
if (k < 0)
return r < 0 ? r : k;
if (k == 0)
return log_debug_errno(r < 0 ? r : SYNTHETIC_ERRNO(ENOKEY),
"Activation of signed Verity volume worked neither via the kernel nor in userspace, can't activate.");
}