gpt-auto-generator: enable TPM2 unlocking in gpt-auto-generator #30185
Conversation
github-actions
bot
added
the
please-review
This comment was marked as off-topic.
This comment was marked as off-topic.
|
So this should fix the specific issue in #30176, and we probably should merge this, before v255. But we actually have a bigger problem in general, and I am not sure how to address this best: since token module support was added to cryptsetup we'd try a "blanket" activation via token before doing the finer grained stuff. Butt that's a mess, because it will pull in our own token modules, and run them before we get to do so explicitly. This is a mess because this way we don't get the chance to pass our various settings into the token modules, hence they run without... We probably should tweak the blanket activation to do so only for tokens that are not ours, i.e. foreign. Man this is all so complex... |
|
That fixes it for me, thanks. |
YHNdnzj
added
good-to-merge/with-minor-suggestions
and removed
please-review
|
any reason not to merge this? |
If we detect a TPM, let's also unlock the disk with it, if it has an enrollment for that. Fixes: systemd#30176
YHNdnzj
force-pushed
the
gpt-auto-tpm2-enable
branch
from
7c7227c
to
f367026
Compare
YHNdnzj
added
good-to-merge/waiting-for-ci 👍
github-actions
bot
removed
the
good-to-merge/waiting-for-ci 👍
|
Ah nice, Goodbye setting |
|
If I'm understanding correctly, the way |
…ailable After systemd#30185 every attach operation has a TPM device configured, even if it is not used, so attach_luks_or_plain_or_bitlk() attempts to use it (first in the list), fails and falls back to the loop, but the pass/keyfile parameters are cleared out. If multiple methods are configured and the ones tried first fail with EAGAIN, try immediately the next one, without returning to the loop. Follow-up for 0d5f59a
…ailable After systemd#30185 every attach operation has a TPM device configured, even if it is not used, so attach_luks_or_plain_or_bitlk() attempts to use it (first in the list), fails and falls back to the loop, but the pass/keyfile parameters are cleared out. If multiple methods are configured and the ones tried first fail with EAGAIN, try immediately the next one, without returning to the loop. Fixes systemd#30425 Follow-up for 0d5f59a
If we couldn't unlock a device with the chosen unlock path, let's not fall back to the lowest one right away, but only flush out one path, and try the next. Fixes: systemd#30425 Follow-up-for: systemd#30185 Alternative-to: systemd#33183
If we couldn't unlock a device with the chosen unlock path, let's not fall back to the lowest one right away, but only flush out one path, and try the next. Fixes: systemd#30425 Follow-up-for: systemd#30185 Alternative-to: systemd#33183
If we couldn't unlock a device with the chosen unlock path, let's not fall back to the lowest one right away, but only flush out one path, and try the next. Fixes: systemd#30425 Follow-up-for: systemd#30185 Alternative-to: systemd#33183
If we detect a TPM, let's also unlock the disk with it, if it has an enrollment for that.
See: #30176