Re: [dm-crypt] about invalid key slots

[Milan Broz <mbroz@redhat.com>]

On 04/02/2012 02:14 PM, .. ink .. wrote:
> 
> Please do not try to parse physical header structure outside of
> cryptsetup, header can change in future (new version) etc.
> libcryptsetup should be wrapper over these internals.
> 
> was not going to. I was puzzled by the "CRYPT_SLOT_INVALID" entry in
> the "crypt_keyslot_info" structure when i looked at the API couple of
> months ago but i never asked about it. All these posts about invalid
> key slots just made me relooked the puzzle and ask about it.

Well, then we should add better documentation...

> CRYPT_SLOT_INVALID is returned if e.g. slot # is above limit, not if
> header is corrupted.

> An invalid key slot due to a corrupted header is a serious problem
> and everybody seem to be reporting on this. How serious is the
> "CRYPT_SLOT_INVALID" status on a key slot as reported by
> crypt_keyslot_status()?

Corrupted LUKS header is very rare.

crypt_keyslot_status() returns currently CRYPT_SLOT_INVALID 

- if you run it over crypto context which does not support keyslots
(non-LUKS)

- if keyslot number is out of limits for the crypt type

- for LUKS, if keyslot status is in some unexpected state
(either not active or active) - well, this one can be caused by
partial header corruption.
(This check should be perhaps in crypt_load as well...
Anyway, slot with invalid status is the same like non-active slot
- cannot be used for unlocking.

> Since my code goes further enoght to see this one( crypt_load() pass
> ) and can open volumes if key is on another slot,it seem useful to
> inform my users of this status but not confuse them with the more
> serious one.

Crypt_load checks only if keyslot area is in some limits (does not
overlap with user data). So some minor corruptuions
can be undetected by crypt_load but status returns invalid...
Nothing is perfect :)

(I am thinking to export current repair code, so it can suggest
to user to run something like "cryptsetup repair <device>" if
there is some invalid values... It is not 100% but should help.)

Milan