Stefan Berger <stef...@linux.vnet.ibm.com> writes: > 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 <stef...@linux.vnet.ibm.com> writes: >>> >>>> On 03/27/2013 03:12 PM, Stefan Berger wrote: >>>>> On 03/27/2013 02:27 PM, Anthony Liguori wrote: >>>>>> Stefan Berger <stef...@linux.vnet.ibm.com> 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
Error creating device. > - user skipped over using the external tool, storage is not formatted > - provided storage contains unknown / corrupted data Garbage in, garbage out. > - encryption / decryption key is missing (yes, we want blob encryption!) > - encryption / decryption key is wrong and decrypted data therefore are > corrupted No, encrypting the nvram is not the device's job. A user can either use ecryptfs or AES encryption in qcow2 if they feel this is important. There is nothing special about the TPM's nvram compared to a normal virtual disk image. Any argument you would make regarding key storage is equally applicable to a virtual disk image. An awful lot of private keys are stored in virtual disk images today... > 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. Same applies to virtual disk images. If someone hands a guest a garbage disk image, the behavior will be ambiguous. It's not a job to prevent users from doing this. (In fact, it may even be desirable to test these conditions) > 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. You're overcomplicating things. QEMU's role is not to prevent a user from doing something unusual. This isn't GNOME. Regards, Anthony Liguori > > Thanks. > > Stefan
