From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6cti-0000PM-QV for qemu-devel@nongnu.org; Thu, 22 Sep 2011 02:36:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6cth-000851-UL for qemu-devel@nongnu.org; Thu, 22 Sep 2011 02:36:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6cth-00084m-Mg for qemu-devel@nongnu.org; Thu, 22 Sep 2011 02:36:37 -0400 Date: Thu, 22 Sep 2011 09:37:44 +0300 From: "Michael S. Tsirkin" Message-ID: <20110922063744.GB29819@redhat.com> References: <20110915122842.GA6302@redhat.com> <4E720CA9.9050208@linux.vnet.ibm.com> <20110916144443.GB20933@redhat.com> <4E737D70.8030801@linux.vnet.ibm.com> <20110917192857.GB6127@redhat.com> <4E776C2A.5020006@linux.vnet.ibm.com> <20110919190412.GA9062@redhat.com> <4E7A9305.909@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7A9305.909@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] blobstore disk format (was Re: Design of the blobstore) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: Anthony Liguori , qemu-devel@nongnu.org, Markus Armbruster On Wed, Sep 21, 2011 at 09:44:37PM -0400, Stefan Berger wrote: > On 09/19/2011 03:04 PM, Michael S. Tsirkin wrote: > >On Mon, Sep 19, 2011 at 12:22:02PM -0400, Stefan Berger wrote: > >>On 09/17/2011 03:28 PM, Michael S. Tsirkin wrote: > >>>On Fri, Sep 16, 2011 at 12:46:40PM -0400, Stefan Berger wrote: > >> > >>The checksuming I think makes sense if encryption is being added so > >>decryption and testing for proper key material remains an NVRAM > >>operation rather than a device operation. > >Not sure how this addresses the question of what to do > >on checksum failure. > > > Checksum failure on an unencrypted blob would mean that the blob is > corrupted. In case of encryption 'corrupted' would overlap with a > 'badly decrypted' blob. In either way the startup of the device > cannot happen. With corruption - why not? A specific block being corrupted does not mean all data is lost. > We could refuse the NVRAM key suggesting that likely > this is the wrong key for decryption but corruption is also > possible. I'm guessing that if we find a correct ber structure in the file, this most likely means the key is correct. -- MST