> If there's still a race remaining, it would be solved by the time the
> user went to enter their password for the device.
For the passphrase case that would be indeed the ideal
solution. Problems with that approach:
- the user might use a keyfile on a removable media (usb, etc.)
- we need to name the drive the user is about to enter his password for
TBH, I thought we decided to drop the non-LUKS case ages ago. Probably
it happened to start working after my last merge, but I have to admit
that while integrating the proposed patch, I didn't really consider
the non-LUKS case.
Having said this, I'd really welcome a proper solution for
cryptset/initramfs integration. kirkland told me that the work he did on
the degraided-raid spec would be very helpful for the use case we are
talking here about.
I suggest that a bof is scheduled with at least kirkland, pitti, kees at
the next UDS. If time is permitting, I'll try to join via VOIP.
Kees Cook <email address hidden> writes:
> If there's still a race remaining, it would be solved by the time the
> user went to enter their password for the device.
For the passphrase case that would be indeed the ideal
solution. Problems with that approach:
- the user might use a keyfile on a removable media (usb, etc.)
- we need to name the drive the user is about to enter his password for
TBH, I thought we decided to drop the non-LUKS case ages ago. Probably
it happened to start working after my last merge, but I have to admit
that while integrating the proposed patch, I didn't really consider
the non-LUKS case.
Having said this, I'd really welcome a proper solution for
cryptset/initramfs integration. kirkland told me that the work he did on
the degraided-raid spec would be very helpful for the use case we are
talking here about.
I suggest that a bof is scheduled with at least kirkland, pitti, kees at
the next UDS. If time is permitting, I'll try to join via VOIP.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4