From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULZlx-0006Ww-Ud for qemu-devel@nongnu.org; Fri, 29 Mar 2013 09:55:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULZlu-0006OR-Bj for qemu-devel@nongnu.org; Fri, 29 Mar 2013 09:55:13 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:53220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULZlu-0006NX-7E for qemu-devel@nongnu.org; Fri, 29 Mar 2013 09:55:10 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 29 Mar 2013 09:55:07 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 827996E803C for ; Fri, 29 Mar 2013 09:55:02 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2TDt4wB319330 for ; Fri, 29 Mar 2013 09:55:04 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2TDt4Mt025963 for ; Fri, 29 Mar 2013 09:55:04 -0400 Message-ID: <51559D37.9060402@linux.vnet.ibm.com> Date: Fri, 29 Mar 2013 09:55:03 -0400 From: Stefan Berger MIME-Version: 1.0 References: <20130327155303.GB29523@redhat.com> <51531A51.3050709@linux.vnet.ibm.com> <51532268.40102@linux.vnet.ibm.com> <87k3os7okn.fsf@codemonkey.ws> <51532C0B.1050108@linux.vnet.ibm.com> <87ehf03dgw.fsf@codemonkey.ws> <515344AB.2030403@linux.vnet.ibm.com> <51546BAA.60504@linux.vnet.ibm.com> <87y5d7a0z2.fsf@codemonkey.ws> <20130328173909.GA31181@redhat.com> In-Reply-To: <20130328173909.GA31181@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] vNVRAM / blobstore design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Stefan Hajnoczi , Kent E Yoder , Corey Bryant , qemu-devel , Michael Roth , Joel Schopp , Kenneth Goldman , Anthony Liguori On 03/28/2013 01:39 PM, Michael S. Tsirkin wrote: > On Thu, Mar 28, 2013 at 12:27:45PM -0500, Anthony Liguori wrote: >> Stefan Berger writes: >> >>> On 03/27/2013 03:12 PM, Stefan Berger wrote: >>>> On 03/27/2013 02:27 PM, Anthony Liguori wrote: >>>>> Stefan Berger writes: >>>>> >>>>>> On 03/27/2013 01:14 PM, Anthony Liguori wrote: >>>>>> >>>>> Okay, the short response is: >>>>> >>>>> Just make the TPM have a DRIVE property, drop all notion of >>>>> NVRAM/blobstore, and used fixed offsets into the BlockDriverState for >>>>> each blob. >>>> Fine by me. I don't see the need for visitors. I guess sharing of the >>>> persistent storage between different types of devices is not a goal >>>> here so that a layer that hides the layout and the blobs' position >>>> within the storage would be necessary. Also fine by me for as long as >>>> we don't come back to this discussion. >>> One thing I'd like to get clarity about is the following corner-case. A >>> user supplies some VM image as persistent storage for the TPM. >> What Would Hardware Do? >> >> If you need to provide a tool to initialize the state, then just provide >> a small tool to do that or provide device option to initialize it that >> can be used on first run or something. >> >> Don't bother trying to add complexity with CRCs or anything like that. >> Just keep it simple. >> >> Regards, >> >> Anthony Liguori > > External tool sounds better. Update on first use creates > nasty corner cases - use isn't a well defined thing. > So it creates nasty interactions with migration etc. What do we do with the following error cases: - provided storage is too small to fit blobs into - user skipped over using the external tool, storage is not formatted - provided storage contains unknown / corrupted data - encryption / decryption key is missing (yes, we want blob encryption!) - encryption / decryption key is wrong and decrypted data therefore are corrupted Starting a device and providing it with corrupted data or data that could not be properly decrypted becomes ambiguous. We can do better and determine these error cases without starting up the device and having the user guess what may be wrong : wrong key versus corrupted data. Corrupted data is hopeless while a wrong key can be fixed. My suggestion would be to have a layer inside of QEMU that handles these error cases and QEMU would not start up unless these errors get resolved. I think there is probably not much concern regarding the separation of core vTPM functionality and this layer, but more how big this layer becomes, what all it provides in terms of services and one step further then whether it should not be a generic layer that can be used by other devices as well. Some additional HMP/QMP commands to query for the above error conditions can be implemented and depending on how severe they are another HMP/QMP command can be implemented to resolve some of these error condition, i.e., provide another AES key or go through the step of formatting etc. If a block device is not big enough it may require the user to use qemu-img again and start over. Thanks. Stefan