From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8wNO-0004OW-Uz for qemu-devel@nongnu.org; Wed, 28 Sep 2011 11:48:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8wNN-0001FQ-7F for qemu-devel@nongnu.org; Wed, 28 Sep 2011 11:48:50 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:46721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8wNM-0001Em-Lx for qemu-devel@nongnu.org; Wed, 28 Sep 2011 11:48:48 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p8SFOZBo030871 for ; Wed, 28 Sep 2011 11:24:35 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8SFmhFR227494 for ; Wed, 28 Sep 2011 11:48:44 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8SFmXQd010484 for ; Wed, 28 Sep 2011 12:48:33 -0300 Message-ID: <4E8341C3.8000104@linux.vnet.ibm.com> Date: Wed, 28 Sep 2011 11:48:19 -0400 From: Stefan Berger MIME-Version: 1.0 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> <20110922063744.GB29819@redhat.com> In-Reply-To: <20110922063744.GB29819@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: Anthony Liguori , qemu-devel@nongnu.org, Markus Armbruster On 09/22/2011 02:37 AM, Michael S. Tsirkin wrote: > 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. > Presumably if you feed bad data into a device it either has its own way of integrity checking the blob (we actually do this for the TPM) or it will blow up/show wrong behavior at some point - hopefully sooner rather than later. Though the detection of bad data *can* be an NVRAM operation rather than the operation of a device using the data stored in the NVRAM. >> 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. [I still would add at least a CRC32 (or maybe even a SHA1) for detection of corruption of the ASN.1 encoded blob without having to hunt the data through a ASN.1 decoder.] If we now say that data should be encryptable even if QCoW2 wasn't used, then is a command line option -nvram id=,key=,... something we should support to make the key applicable to the whole NVRAM? Stefan