From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSdoSG5Czv41 for ; Mon, 2 Apr 2012 15:06:56 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 2 Apr 2012 15:06:55 +0200 (CEST) Message-ID: <4F79A46B.505@redhat.com> Date: Mon, 02 Apr 2012 15:06:51 +0200 From: Milan Broz MIME-Version: 1.0 References: <4F79665F.8080706@redhat.com> <4F7980D1.4080703@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] about invalid key slots List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ".. ink .." Cc: dm-crypt 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 " if there is some invalid values... It is not 100% but should help.) Milan