From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1NHB-0003E3-Rl for qemu-devel@nongnu.org; Wed, 07 Sep 2011 14:55:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1NHA-0003Fb-Tr for qemu-devel@nongnu.org; Wed, 07 Sep 2011 14:55:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1NHA-0003F8-Mh for qemu-devel@nongnu.org; Wed, 07 Sep 2011 14:55:08 -0400 Date: Wed, 7 Sep 2011 21:55:36 +0300 From: "Michael S. Tsirkin" Message-ID: <20110907185536.GA15276@redhat.com> References: <20110831143551.127339744@linux.vnet.ibm.com> <20110831143623.043146580@linux.vnet.ibm.com> <20110901192659.GM10989@redhat.com> <4E603E37.40901@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E603E37.40901@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH V8 10/14] Encrypt state blobs using AES CBC encryption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: chrisw@redhat.com, anbang.ruan@cs.ox.ac.uk, qemu-devel@nongnu.org, rrelyea@redhat.com, alevy@redhat.com, andreas.niederl@iaik.tugraz.at, serge@hallyn.com On Thu, Sep 01, 2011 at 10:23:51PM -0400, Stefan Berger wrote: > >>An additional 'layer' for reading and writing the blobs to the underlying > >>block storage is added. This layer encrypts the blobs for writing if a key is > >>available. Similarly it decrypts the blobs after reading. So a couple of further thoughts: 1. Raw storage should work too, and with e.g. NFS migration will be fine, right? So I'd say it's worth supporting. 2. File backed nvram is interesting outside tpm. For example,vpd and chassis number for pci, eeprom emulation for network cards. Using a file per device might be inconvenient though. So please think of a format and API that will allow sections for use by different devices. 3. Home-grown file formats give us enough trouble in migration. Could this use one of the variants of ASN.1? There are portable libraries to read/write that, even. -- MST