[Qemu-devel] vNVRAM / blobstore design

[Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

[-- Attachment #1: Type: text/plain, Size: 9810 bytes --]

[argh, just posted this to qemu-trivial -- it's not trivial]


Hello!

I am posting this message to revive the previous discussions about the 
design of vNVRAM / blobstore cc'ing (at least) those that participated 
in this discussion 'back then'.

The first goal of the implementation is to provide an vNVRAM storage for 
a software implementation of a TPM to store its different blobs into. 
Some of the data that the TPM writes into persistent memory needs to 
survive a power down / power up cycle of a virtual machine, therefore 
this type of persistent storage is needed. For the vNVRAM not to become 
a road-block for VM migration, we would make use of block device 
migration and layer the vNVRAM on top of the block device, therefore 
using virtual machine images for storing the vNVRAM data.

Besides the TPM blobs the vNVRAM should of course also be able able to 
accommodate other use cases where persistent data is stored into NVRAM, 
BBRAM (battery backed-up RAM) or EEPROM. As far as I know more recent 
machines with UEFI also have such types of persistent memory. I believe 
the current design of the vNVRAM layer accommodates other use cases as 
well, though additional 'glue devices' would need to be implemented to 
interact with this vNVRAM layer.

Here is a reference to the previous discussion:

http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg01791.html
http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg01967.html

Two aspects of the vNVRAM seem of primary interest: its API and how the 
data is organized in the virtual machine image leaving its inner 
workings to the side for now.


API of the vNVRAM:
------------------

The following functions and data structures are important for devices:


enum NVRAMRWOp {
     NVRAM_OP_READ,
     NVRAM_OP_WRITE,
     NVRAM_OP_FORMAT
};

/**
  * Callback function a device must provide for reading and writing
  * of blobs as well as for indicating to the NVRAM layer the maximum
  * blob size of the given entry. Due to the layout of the data in the
  * NVRAM, the device must always write a blob with the size indicated
  * during formatting.
  * @op: Indication of the NVRAM operation
  * @v: Input visitor in case of a read operation, output visitor in
  *     case of a write or format operation.
  * @entry_name: Unique name of the NVRAM entry
  * @opaque: opaque data previously provided when registering the NVRAM
  *          entry
  * @errp: Pointer to an Error pointer for the visitor to indicate error
  */
typedef int (*NVRAMRWData)(enum NVRAMRWOp op, Visitor *v,
                            const NVRAMEntryName *entry_name, void *opaque,
                            Error **errp);

/**
  * nvram_setup:
  * @drive_id: The ID of the drive to be used as NVRAM. Following the 
command
  *            line '-drive if=none,id=tpm-bs,file=<file>' 'tpm-bs' would
  *            have to be passed.
  * @errcode: Pointer to an integer for an error code
  * @resetfn : Device reset function
  * @dev: The DeviceState to be passed to the device reset function @resetfn
  *
  * This function returns a pointer to VNVRAM or NULL in case an error 
occurred
  */
VNVRAM *nvram_setup(const char *drive_id, int *errcode,
                     qdev_resetfn resetfn, DeviceState *dev);

/**
  * nvram_delete:
  * @nvram: The NVRAM to destroy
  *
  * Destroy the NVRAM previously allocated using nvram_setup.
  */
int nvram_delete(VNVRAM *nvram);

/**
  * nvram_start:
  * @nvram: The NVRAM to start
  * @fail_on_encrypted_drive: Fail if the drive is encrypted but no
  *                           key was provided so far to lower layers.
  *
  * After all blobs that the device intends to write have been registered
  * with the NVRAM, this function is used to start up the NVRAM. In case
  * no error occurred, 0 is returned, an error code otherwise.
  */
int nvram_start(VNVRAM *nvram, bool fail_on_encrypted_drive);

/**
  * nvram_process_requests:
  *
  * Have the NVRAM layer process all outstanding requests and wait
  * for their completion.
  */
void nvram_process_requests(void);

/**
  * nvram_register_entry:
  *
  * @nvram: The NVRAM to register an entry with
  * @entry_name: The unique name of the blob to register
  * @rwdata_callback: Callback function for the NVRAM layer to
  *                   invoke for asynchronous requests such as
  *                   delivering the results of a read operation
  *                   or requesting the maximum size of the blob
  *                   when formatting.
  * @opaque: Data to pass to the callback function
  *
  * Register an entry for the NVRAM layer to write. In case of success
  * this function returns 0, an error code otherwise.
  */
int nvram_register_entry(VNVRAM *nvram, const NVRAMEntryName *entry_name,
                          NVRAMRWData rwdata_callback, void *opaque);

/**
  * nvram_deregister_entry:
  * @nvram: The NVRAM to deregister an entry from
  * @entry_name: the unique name of the entry
  *
  * Deregister an NVRAM entry previously registered with the NVRAM layer.
  * The function returns 0 on success, an error code on failure.
  */
int nvram_deregister_entry(VNVRAM *nvram, const NVRAMEntryName *entry_name);

/**
  * nvram_had_fatal_error:
  * @nvram: The NVRAM to check
  *
  * Returns true in case the NVRAM had a fatal error and
  * is unusable, false if the device can be used.
  */
bool nvram_had_fatal_error(VNVRAM *nvram);

/**
  * nvram_write_data:
  * @nvram: The NVRAM to write the data to
  * @entry_name: The name of the blob to write
  * @flags: Flags indicating sychronouse or asynchronous
  *         operation and whether to wait for completion
  *         of the operation.
  * @cb: callback to invoke for an async write
  * @opaque: data to pass to the callback
  *
  * Write data into NVRAM. This function will invoke the callback
  * provided in nvram_setup where an output visitor will be
  * provided for writing the blob. This function returns 0 in case
  * of success, an error code otherwise.
  */
int nvram_write_data(VNVRAM *nvram, const NVRAMEntryName *entry_name,
                      int flags, NVRAMRWFinishCB cb, void *opaque);

/**
  * nvram_write_data:
  * @nvram: The NVRAM to read the data from
  * @entry_name: The name of the blob tow rite
  * @flags: Flags indicating sychronouse or asynchronous
  *         operation and whether to wait for completion
  *         of the operation.
  * @cb: callback to invoke for an async read
  * @opaque: data to pass to the callback
  *
  * Read data from NVRAM. This function will invoke the callback
  * provided in nvram_setup where an input visitor will be
  * provided for reading the data. This function return 0 in
  * case of success, an error code otherwise.
  */
int nvram_read_data(VNVRAM *nvram, const NVRAMEntryName *entry_name,
                     int flags, NVRAMRWFinishCB cb, void *opaque);

/* flags used above */
#define VNVRAM_ASYNC_F              (1 << 0)
#define VNVRAM_WAIT_COMPLETION_F    (1 << 1)



Organization of the data in the virtual machine image:
------------------------------------------------------

All data on the VM image are written as a single ASN.1 stream with a 
header followed by the individual fixed-sized NVRAM entries. The NVRAM 
layer creates the header during an NVRAM formatting step that must be 
initiated by the user (or libvirt) through an HMP or QMP command.

The fact that we are writing ASN.1 formatted data into the virtual 
machine image is also the reason for the recent posts of the ASN.1 
visitor patch series.


/*
  * The NVRAM on-disk format is as follows:
  * Let '{' and '}' denote an ASN.1 sequence start and end.
  *
  * {
  *   NVRAM-header: "qemu-nvram"
  *   # a sequence of blobs:
  *   {
  *     1st NVRAM entry's name
  *     1st NVRAM entry's ASN.1 blob (fixed size)
  *   }
  *   {
  *     2nd NVRAM entry's name
  *     2nd NVRAM entry's ASN.1 blob (fixed size)
  *   }
  *   ...
  * }
  */

NVRAM entries are read by searching for the entry identified by its 
unique name. If it is found, the device's callback function is invoked 
with an input visitor for the device to read the data.

NVRAM entries are written by searching for the entry identified by its 
unique name. If it is found, the device's callback function is invoked 
with an output visitor positioned to where the data need to be written 
to in the VM image. The device then uses the visitor directly to write 
the blob.

The ASN.1 blobs have to be of fixed size since an inflating or deflating 
1st blob would require that all subsequent blobs be moved or destroy the 
integrity of the ASN.1 stream.


One complication is the requirements on size of the NVRAM and the fact 
the virtual machine images typically don't grow. Here users may need 
a-priori knowledge as to what the size of the NVRAM has to be for the 
device to properly work. In case of the the TPM for example, the TPM 
requires a virtual machine image of a certain size for it to be able to 
write all its blobs into. It may be necessary for human users to start 
QEMU once to find out the required size of the NVRAM image (using an HMP 
command) or get it through documentation. In the case of libvirt the 
required image size could be hard coded into libvirt since it will not 
change anymore and is a property of the device. Another possibility 
would be to use QEMU APIs to re-size the image before formatting (this 
at least did not work a few months ago if I recall correctly, or did not 
work with all VM image formats; details here faded from memory...)

I think this is enough detail for now. Please let me know of any 
comments you may have. My primary concern for now is to get clarity on 
the layout of the data inside the virtual machine image. The ASN.1 
visitors were written for this purpose.


Thanks and regards,
     Stefan


[-- Attachment #2: Type: text/html, Size: 16424 bytes --]

Re: [Qemu-devel] vNVRAM / blobstore design

[Anthony Liguori]

Stefan Berger <stefanb@linux.vnet.ibm.com> writes:

> [argh, just posted this to qemu-trivial -- it's not trivial]
>
>
> Hello!
>
> I am posting this message to revive the previous discussions about the 
> design of vNVRAM / blobstore cc'ing (at least) those that participated 
> in this discussion 'back then'.
>
> The first goal of the implementation is to provide an vNVRAM storage for 
> a software implementation of a TPM to store its different blobs into. 
> Some of the data that the TPM writes into persistent memory needs to 
> survive a power down / power up cycle of a virtual machine, therefore 
> this type of persistent storage is needed. For the vNVRAM not to become 
> a road-block for VM migration, we would make use of block device 
> migration and layer the vNVRAM on top of the block device, therefore 
> using virtual machine images for storing the vNVRAM data.
>
> Besides the TPM blobs the vNVRAM should of course also be able able to 
> accommodate other use cases where persistent data is stored into
> NVRAM, 

Well let's focus more on the "blob store".  What are the semantics of
this?  Is there a max number of blobs?  Are the sizes fixed or variable?
How often are new blobs added/removed?

Regards,

Anthony Liguori


> BBRAM (battery backed-up RAM) or EEPROM. As far as I know more recent 
> machines with UEFI also have such types of persistent memory. I believe 
> the current design of the vNVRAM layer accommodates other use cases as 
> well, though additional 'glue devices' would need to be implemented to 
> interact with this vNVRAM layer.
>
> Here is a reference to the previous discussion:
>
> http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg01791.html
> http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg01967.html
>
> Two aspects of the vNVRAM seem of primary interest: its API and how the 
> data is organized in the virtual machine image leaving its inner 
> workings to the side for now.
>
>
> API of the vNVRAM:
> ------------------
>
> The following functions and data structures are important for devices:
>
>
> enum NVRAMRWOp {
>      NVRAM_OP_READ,
>      NVRAM_OP_WRITE,
>      NVRAM_OP_FORMAT
> };
>
> /**
>   * Callback function a device must provide for reading and writing
>   * of blobs as well as for indicating to the NVRAM layer the maximum
>   * blob size of the given entry. Due to the layout of the data in the
>   * NVRAM, the device must always write a blob with the size indicated
>   * during formatting.
>   * @op: Indication of the NVRAM operation
>   * @v: Input visitor in case of a read operation, output visitor in
>   *     case of a write or format operation.
>   * @entry_name: Unique name of the NVRAM entry
>   * @opaque: opaque data previously provided when registering the NVRAM
>   *          entry
>   * @errp: Pointer to an Error pointer for the visitor to indicate error
>   */
> typedef int (*NVRAMRWData)(enum NVRAMRWOp op, Visitor *v,
>                             const NVRAMEntryName *entry_name, void *opaque,
>                             Error **errp);
>
> /**
>   * nvram_setup:
>   * @drive_id: The ID of the drive to be used as NVRAM. Following the 
> command
>   *            line '-drive if=none,id=tpm-bs,file=<file>' 'tpm-bs' would
>   *            have to be passed.
>   * @errcode: Pointer to an integer for an error code
>   * @resetfn : Device reset function
>   * @dev: The DeviceState to be passed to the device reset function @resetfn
>   *
>   * This function returns a pointer to VNVRAM or NULL in case an error 
> occurred
>   */
> VNVRAM *nvram_setup(const char *drive_id, int *errcode,
>                      qdev_resetfn resetfn, DeviceState *dev);
>
> /**
>   * nvram_delete:
>   * @nvram: The NVRAM to destroy
>   *
>   * Destroy the NVRAM previously allocated using nvram_setup.
>   */
> int nvram_delete(VNVRAM *nvram);
>
> /**
>   * nvram_start:
>   * @nvram: The NVRAM to start
>   * @fail_on_encrypted_drive: Fail if the drive is encrypted but no
>   *                           key was provided so far to lower layers.
>   *
>   * After all blobs that the device intends to write have been registered
>   * with the NVRAM, this function is used to start up the NVRAM. In case
>   * no error occurred, 0 is returned, an error code otherwise.
>   */
> int nvram_start(VNVRAM *nvram, bool fail_on_encrypted_drive);
>
> /**
>   * nvram_process_requests:
>   *
>   * Have the NVRAM layer process all outstanding requests and wait
>   * for their completion.
>   */
> void nvram_process_requests(void);
>
> /**
>   * nvram_register_entry:
>   *
>   * @nvram: The NVRAM to register an entry with
>   * @entry_name: The unique name of the blob to register
>   * @rwdata_callback: Callback function for the NVRAM layer to
>   *                   invoke for asynchronous requests such as
>   *                   delivering the results of a read operation
>   *                   or requesting the maximum size of the blob
>   *                   when formatting.
>   * @opaque: Data to pass to the callback function
>   *
>   * Register an entry for the NVRAM layer to write. In case of success
>   * this function returns 0, an error code otherwise.
>   */
> int nvram_register_entry(VNVRAM *nvram, const NVRAMEntryName *entry_name,
>                           NVRAMRWData rwdata_callback, void *opaque);
>
> /**
>   * nvram_deregister_entry:
>   * @nvram: The NVRAM to deregister an entry from
>   * @entry_name: the unique name of the entry
>   *
>   * Deregister an NVRAM entry previously registered with the NVRAM layer.
>   * The function returns 0 on success, an error code on failure.
>   */
> int nvram_deregister_entry(VNVRAM *nvram, const NVRAMEntryName *entry_name);
>
> /**
>   * nvram_had_fatal_error:
>   * @nvram: The NVRAM to check
>   *
>   * Returns true in case the NVRAM had a fatal error and
>   * is unusable, false if the device can be used.
>   */
> bool nvram_had_fatal_error(VNVRAM *nvram);
>
> /**
>   * nvram_write_data:
>   * @nvram: The NVRAM to write the data to
>   * @entry_name: The name of the blob to write
>   * @flags: Flags indicating sychronouse or asynchronous
>   *         operation and whether to wait for completion
>   *         of the operation.
>   * @cb: callback to invoke for an async write
>   * @opaque: data to pass to the callback
>   *
>   * Write data into NVRAM. This function will invoke the callback
>   * provided in nvram_setup where an output visitor will be
>   * provided for writing the blob. This function returns 0 in case
>   * of success, an error code otherwise.
>   */
> int nvram_write_data(VNVRAM *nvram, const NVRAMEntryName *entry_name,
>                       int flags, NVRAMRWFinishCB cb, void *opaque);
>
> /**
>   * nvram_write_data:
>   * @nvram: The NVRAM to read the data from
>   * @entry_name: The name of the blob tow rite
>   * @flags: Flags indicating sychronouse or asynchronous
>   *         operation and whether to wait for completion
>   *         of the operation.
>   * @cb: callback to invoke for an async read
>   * @opaque: data to pass to the callback
>   *
>   * Read data from NVRAM. This function will invoke the callback
>   * provided in nvram_setup where an input visitor will be
>   * provided for reading the data. This function return 0 in
>   * case of success, an error code otherwise.
>   */
> int nvram_read_data(VNVRAM *nvram, const NVRAMEntryName *entry_name,
>                      int flags, NVRAMRWFinishCB cb, void *opaque);
>
> /* flags used above */
> #define VNVRAM_ASYNC_F              (1 << 0)
> #define VNVRAM_WAIT_COMPLETION_F    (1 << 1)
>
>
>
> Organization of the data in the virtual machine image:
> ------------------------------------------------------
>
> All data on the VM image are written as a single ASN.1 stream with a 
> header followed by the individual fixed-sized NVRAM entries. The NVRAM 
> layer creates the header during an NVRAM formatting step that must be 
> initiated by the user (or libvirt) through an HMP or QMP command.
>
> The fact that we are writing ASN.1 formatted data into the virtual 
> machine image is also the reason for the recent posts of the ASN.1 
> visitor patch series.
>
>
> /*
>   * The NVRAM on-disk format is as follows:
>   * Let '{' and '}' denote an ASN.1 sequence start and end.
>   *
>   * {
>   *   NVRAM-header: "qemu-nvram"
>   *   # a sequence of blobs:
>   *   {
>   *     1st NVRAM entry's name
>   *     1st NVRAM entry's ASN.1 blob (fixed size)
>   *   }
>   *   {
>   *     2nd NVRAM entry's name
>   *     2nd NVRAM entry's ASN.1 blob (fixed size)
>   *   }
>   *   ...
>   * }
>   */
>
> NVRAM entries are read by searching for the entry identified by its 
> unique name. If it is found, the device's callback function is invoked 
> with an input visitor for the device to read the data.
>
> NVRAM entries are written by searching for the entry identified by its 
> unique name. If it is found, the device's callback function is invoked 
> with an output visitor positioned to where the data need to be written 
> to in the VM image. The device then uses the visitor directly to write 
> the blob.
>
> The ASN.1 blobs have to be of fixed size since an inflating or deflating 
> 1st blob would require that all subsequent blobs be moved or destroy the 
> integrity of the ASN.1 stream.
>
>
> One complication is the requirements on size of the NVRAM and the fact 
> the virtual machine images typically don't grow. Here users may need 
> a-priori knowledge as to what the size of the NVRAM has to be for the 
> device to properly work. In case of the the TPM for example, the TPM 
> requires a virtual machine image of a certain size for it to be able to 
> write all its blobs into. It may be necessary for human users to start 
> QEMU once to find out the required size of the NVRAM image (using an HMP 
> command) or get it through documentation. In the case of libvirt the 
> required image size could be hard coded into libvirt since it will not 
> change anymore and is a property of the device. Another possibility 
> would be to use QEMU APIs to re-size the image before formatting (this 
> at least did not work a few months ago if I recall correctly, or did not 
> work with all VM image formats; details here faded from memory...)
>
> I think this is enough detail for now. Please let me know of any 
> comments you may have. My primary concern for now is to get clarity on 
> the layout of the data inside the virtual machine image. The ASN.1 
> visitors were written for this purpose.
>
>
> Thanks and regards,
>      Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/25/2013 06:05 PM, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> [argh, just posted this to qemu-trivial -- it's not trivial]
>>
>>
>> Hello!
>>
>> I am posting this message to revive the previous discussions about the
>> design of vNVRAM / blobstore cc'ing (at least) those that participated
>> in this discussion 'back then'.
>>
>> The first goal of the implementation is to provide an vNVRAM storage for
>> a software implementation of a TPM to store its different blobs into.
>> Some of the data that the TPM writes into persistent memory needs to
>> survive a power down / power up cycle of a virtual machine, therefore
>> this type of persistent storage is needed. For the vNVRAM not to become
>> a road-block for VM migration, we would make use of block device
>> migration and layer the vNVRAM on top of the block device, therefore
>> using virtual machine images for storing the vNVRAM data.
>>
>> Besides the TPM blobs the vNVRAM should of course also be able able to
>> accommodate other use cases where persistent data is stored into
>> NVRAM,
> Well let's focus more on the "blob store".  What are the semantics of
> this?  Is there a max number of blobs?  Are the sizes fixed or variable?
> How often are new blobs added/removed?

In case of TPM 1.2 there are 3 blobs that can be written at different 
times for different reasons.

Examples: As with a real-world TPM users loading an owner-evict key into 
the TPM will cause the TPM to write that owner-evict key into is own 
NVRAM. This key survives a power-off of the machine. Further, the TPM 
models its own NVRAM slots. Someone writing into this type of memory 
will cause data to be written into the NVRAM. There are other commands 
that the TPM offers that will cause data to be written into NVRAM which 
users can invoke at any time.

The sizes of the NVRAM blobs of the TPM at least vary in size but I 
handle this in the TPM emulation to pad them to fixed size. Depending on 
how many such owner-evict keys are loaded into the TPM its permanent 
state blob size may vary. Other devices may act differently.

We have a-priori knowledge about  the 3 different types of blobs the TPM 
device produces. They are 'registered' once at the beginning (see API) 
and are not 'removed' as such.

Regards,
     Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Corey Bryant]

On 03/25/2013 06:20 PM, Stefan Berger wrote:
> On 03/25/2013 06:05 PM, Anthony Liguori wrote:
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>>> [argh, just posted this to qemu-trivial -- it's not trivial]
>>>
>>>
>>> Hello!
>>>
>>> I am posting this message to revive the previous discussions about the
>>> design of vNVRAM / blobstore cc'ing (at least) those that participated
>>> in this discussion 'back then'.
>>>
>>> The first goal of the implementation is to provide an vNVRAM storage for
>>> a software implementation of a TPM to store its different blobs into.
>>> Some of the data that the TPM writes into persistent memory needs to
>>> survive a power down / power up cycle of a virtual machine, therefore
>>> this type of persistent storage is needed. For the vNVRAM not to become
>>> a road-block for VM migration, we would make use of block device
>>> migration and layer the vNVRAM on top of the block device, therefore
>>> using virtual machine images for storing the vNVRAM data.
>>>
>>> Besides the TPM blobs the vNVRAM should of course also be able able to
>>> accommodate other use cases where persistent data is stored into
>>> NVRAM,
>> Well let's focus more on the "blob store".  What are the semantics of
>> this?  Is there a max number of blobs?  Are the sizes fixed or variable?
>> How often are new blobs added/removed?

The max number of blobs and frequency of usage depends on the usage 
scenario and NVRAM size.  But that's probably obvious.

I think we should focus on worst case scenarios where NVRAM is filled up 
and used frequently.

One example is that an application can use TSS APIs to define, undefine, 
read, and write to the TPM's NVRAM storage.  (The TPM owner password is 
required to define NVRAM data.)  An application could potentially fill 
up NVRAM and frequently store, change, retrieve data in various places 
within NVRAM.  And the data could have various sizes.

For an example of total NVRAM size, Infineon's TPM has 16K of NVRAM.

-- 
Regards,
Corey Bryant

>
> In case of TPM 1.2 there are 3 blobs that can be written at different
> times for different reasons.
>
> Examples: As with a real-world TPM users loading an owner-evict key into
> the TPM will cause the TPM to write that owner-evict key into is own
> NVRAM. This key survives a power-off of the machine. Further, the TPM
> models its own NVRAM slots. Someone writing into this type of memory
> will cause data to be written into the NVRAM. There are other commands
> that the TPM offers that will cause data to be written into NVRAM which
> users can invoke at any time.
>
> The sizes of the NVRAM blobs of the TPM at least vary in size but I
> handle this in the TPM emulation to pad them to fixed size. Depending on
> how many such owner-evict keys are loaded into the TPM its permanent
> state blob size may vary. Other devices may act differently.
>
> We have a-priori knowledge about  the 3 different types of blobs the TPM
> device produces. They are 'registered' once at the beginning (see API)
> and are not 'removed' as such.
>
> Regards,
>      Stefan
>

Re: [Qemu-devel] vNVRAM / blobstore design

[Corey Bryant]

On 03/27/2013 11:17 AM, Corey Bryant wrote:
>
>
> On 03/25/2013 06:20 PM, Stefan Berger wrote:
>> On 03/25/2013 06:05 PM, Anthony Liguori wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> [argh, just posted this to qemu-trivial -- it's not trivial]
>>>>
>>>>
>>>> Hello!
>>>>
>>>> I am posting this message to revive the previous discussions about the
>>>> design of vNVRAM / blobstore cc'ing (at least) those that participated
>>>> in this discussion 'back then'.
>>>>
>>>> The first goal of the implementation is to provide an vNVRAM storage
>>>> for
>>>> a software implementation of a TPM to store its different blobs into.
>>>> Some of the data that the TPM writes into persistent memory needs to
>>>> survive a power down / power up cycle of a virtual machine, therefore
>>>> this type of persistent storage is needed. For the vNVRAM not to become
>>>> a road-block for VM migration, we would make use of block device
>>>> migration and layer the vNVRAM on top of the block device, therefore
>>>> using virtual machine images for storing the vNVRAM data.
>>>>
>>>> Besides the TPM blobs the vNVRAM should of course also be able able to
>>>> accommodate other use cases where persistent data is stored into
>>>> NVRAM,
>>> Well let's focus more on the "blob store".  What are the semantics of
>>> this?  Is there a max number of blobs?  Are the sizes fixed or variable?
>>> How often are new blobs added/removed?
>
> The max number of blobs and frequency of usage depends on the usage
> scenario and NVRAM size.  But that's probably obvious.
>
> I think we should focus on worst case scenarios where NVRAM is filled up
> and used frequently.
>
> One example is that an application can use TSS APIs to define, undefine,
> read, and write to the TPM's NVRAM storage.  (The TPM owner password is
> required to define NVRAM data.)  An application could potentially fill
> up NVRAM and frequently store, change, retrieve data in various places
> within NVRAM.  And the data could have various sizes.
>
> For an example of total NVRAM size, Infineon's TPM has 16K of NVRAM.
>
> --
> Regards,
> Corey Bryant
>

I just wanted to add that we could really use some direction on which 
way the community would prefer we go with this.  The 2 options that are 
on the table at the moment for encoding/decoding the vNVRAM byte stream 
are BER or JSON visitors.

-- 
Regards,
Corey Bryant

>>
>> In case of TPM 1.2 there are 3 blobs that can be written at different
>> times for different reasons.
>>
>> Examples: As with a real-world TPM users loading an owner-evict key into
>> the TPM will cause the TPM to write that owner-evict key into is own
>> NVRAM. This key survives a power-off of the machine. Further, the TPM
>> models its own NVRAM slots. Someone writing into this type of memory
>> will cause data to be written into the NVRAM. There are other commands
>> that the TPM offers that will cause data to be written into NVRAM which
>> users can invoke at any time.
>>
>> The sizes of the NVRAM blobs of the TPM at least vary in size but I
>> handle this in the TPM emulation to pad them to fixed size. Depending on
>> how many such owner-evict keys are loaded into the TPM its permanent
>> state blob size may vary. Other devices may act differently.
>>
>> We have a-priori knowledge about  the 3 different types of blobs the TPM
>> device produces. They are 'registered' once at the beginning (see API)
>> and are not 'removed' as such.
>>
>> Regards,
>>      Stefan
>>
>

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Wed, Mar 27, 2013 at 11:20:43AM -0400, Corey Bryant wrote:
> 
> 
> On 03/27/2013 11:17 AM, Corey Bryant wrote:
> >
> >
> >On 03/25/2013 06:20 PM, Stefan Berger wrote:
> >>On 03/25/2013 06:05 PM, Anthony Liguori wrote:
> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>>
> >>>>[argh, just posted this to qemu-trivial -- it's not trivial]
> >>>>
> >>>>
> >>>>Hello!
> >>>>
> >>>>I am posting this message to revive the previous discussions about the
> >>>>design of vNVRAM / blobstore cc'ing (at least) those that participated
> >>>>in this discussion 'back then'.
> >>>>
> >>>>The first goal of the implementation is to provide an vNVRAM storage
> >>>>for
> >>>>a software implementation of a TPM to store its different blobs into.
> >>>>Some of the data that the TPM writes into persistent memory needs to
> >>>>survive a power down / power up cycle of a virtual machine, therefore
> >>>>this type of persistent storage is needed. For the vNVRAM not to become
> >>>>a road-block for VM migration, we would make use of block device
> >>>>migration and layer the vNVRAM on top of the block device, therefore
> >>>>using virtual machine images for storing the vNVRAM data.
> >>>>
> >>>>Besides the TPM blobs the vNVRAM should of course also be able able to
> >>>>accommodate other use cases where persistent data is stored into
> >>>>NVRAM,
> >>>Well let's focus more on the "blob store".  What are the semantics of
> >>>this?  Is there a max number of blobs?  Are the sizes fixed or variable?
> >>>How often are new blobs added/removed?
> >
> >The max number of blobs and frequency of usage depends on the usage
> >scenario and NVRAM size.  But that's probably obvious.
> >
> >I think we should focus on worst case scenarios where NVRAM is filled up
> >and used frequently.
> >
> >One example is that an application can use TSS APIs to define, undefine,
> >read, and write to the TPM's NVRAM storage.  (The TPM owner password is
> >required to define NVRAM data.)  An application could potentially fill
> >up NVRAM and frequently store, change, retrieve data in various places
> >within NVRAM.  And the data could have various sizes.
> >
> >For an example of total NVRAM size, Infineon's TPM has 16K of NVRAM.
> >
> >--
> >Regards,
> >Corey Bryant
> >
> 
> I just wanted to add that we could really use some direction on
> which way the community would prefer we go with this.  The 2 options
> that are on the table at the moment for encoding/decoding the vNVRAM
> byte stream are BER or JSON visitors.
> 
> -- 
> Regards,
> Corey Bryant

I think I like BER better. JSON seems like a bad fit for a
bunch of binary blobs.

> >>
> >>In case of TPM 1.2 there are 3 blobs that can be written at different
> >>times for different reasons.
> >>
> >>Examples: As with a real-world TPM users loading an owner-evict key into
> >>the TPM will cause the TPM to write that owner-evict key into is own
> >>NVRAM. This key survives a power-off of the machine. Further, the TPM
> >>models its own NVRAM slots. Someone writing into this type of memory
> >>will cause data to be written into the NVRAM. There are other commands
> >>that the TPM offers that will cause data to be written into NVRAM which
> >>users can invoke at any time.
> >>
> >>The sizes of the NVRAM blobs of the TPM at least vary in size but I
> >>handle this in the TPM emulation to pad them to fixed size. Depending on
> >>how many such owner-evict keys are loaded into the TPM its permanent
> >>state blob size may vary. Other devices may act differently.
> >>
> >>We have a-priori knowledge about  the 3 different types of blobs the TPM
> >>device produces. They are 'registered' once at the beginning (see API)
> >>and are not 'removed' as such.
> >>
> >>Regards,
> >>     Stefan
> >>
> >

Re: [Qemu-devel] vNVRAM / blobstore design

[Kenneth Goldman]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

A few comments FWIW

When I first did TPM 1.2, I stored different parts of the TPM NV data 
(permanent data, owner evict keys, defined space) in different files.  It 
got ugly and I eventually changed to one big blob, This was far more 
portable, worked better for real flash memory, etc.  It also handles 
integrity and/or encryption with less overhead.

As for encoding, I didn't bother with DER, XML, etc, as the TPM was big 
enough without importing complex parsers.  The TPM already requires 
marshalling and unmarshalling code in its native binary format for command 
and response handling, so I just reused that code.  I added version 
numbers and count values to handle changes to the format, and a hash to 
detect corruption.

--
Ken Goldman   kgoldman@us.ibm.com 
914-945-2415 (862-2415)

[-- Attachment #2: Type: text/html, Size: 1009 bytes --]

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Wed, Mar 27, 2013 at 11:43:53AM -0400, Kenneth Goldman wrote:
> A few comments FWIW
> 
> When I first did TPM 1.2, I stored different parts of the TPM NV data
> (permanent data, owner evict keys, defined space) in different files.  It got
> ugly and I eventually changed to one big blob, This was far more portable,
> worked better for real flash memory, etc.  It also handles integrity and/or
> encryption with less overhead.
> 
> As for encoding, I didn't bother with DER, XML, etc, as the TPM was big enough
> without importing complex parsers.  The TPM already requires marshalling and
> unmarshalling code in its native binary format for command and response
> handling, so I just reused that code.  I added version numbers and count values
> to handle changes to the format, and a hash to detect corruption.
> 
> --
> Ken Goldman   kgoldman@us.ibm.com  
> 914-945-2415 (862-2415)

Yea it's not hard to invent a random format each time we write something
on disk.

But I think ASN.1 BER will be useful to have in qemu anyway.  E.g. it's a
better format for migration than what we have now.  Once we have it in
tree re-using it seems cleaner than maintaining some per-TPM thing.

-- 
MST

Re: [Qemu-devel] vNVRAM / blobstore design

[mdroth]

On Wed, Mar 27, 2013 at 05:30:09PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 27, 2013 at 11:20:43AM -0400, Corey Bryant wrote:
> > 
> > 
> > On 03/27/2013 11:17 AM, Corey Bryant wrote:
> > >
> > >
> > >On 03/25/2013 06:20 PM, Stefan Berger wrote:
> > >>On 03/25/2013 06:05 PM, Anthony Liguori wrote:
> > >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> > >>>
> > >>>>[argh, just posted this to qemu-trivial -- it's not trivial]
> > >>>>
> > >>>>
> > >>>>Hello!
> > >>>>
> > >>>>I am posting this message to revive the previous discussions about the
> > >>>>design of vNVRAM / blobstore cc'ing (at least) those that participated
> > >>>>in this discussion 'back then'.
> > >>>>
> > >>>>The first goal of the implementation is to provide an vNVRAM storage
> > >>>>for
> > >>>>a software implementation of a TPM to store its different blobs into.
> > >>>>Some of the data that the TPM writes into persistent memory needs to
> > >>>>survive a power down / power up cycle of a virtual machine, therefore
> > >>>>this type of persistent storage is needed. For the vNVRAM not to become
> > >>>>a road-block for VM migration, we would make use of block device
> > >>>>migration and layer the vNVRAM on top of the block device, therefore
> > >>>>using virtual machine images for storing the vNVRAM data.
> > >>>>
> > >>>>Besides the TPM blobs the vNVRAM should of course also be able able to
> > >>>>accommodate other use cases where persistent data is stored into
> > >>>>NVRAM,
> > >>>Well let's focus more on the "blob store".  What are the semantics of
> > >>>this?  Is there a max number of blobs?  Are the sizes fixed or variable?
> > >>>How often are new blobs added/removed?
> > >
> > >The max number of blobs and frequency of usage depends on the usage
> > >scenario and NVRAM size.  But that's probably obvious.
> > >
> > >I think we should focus on worst case scenarios where NVRAM is filled up
> > >and used frequently.
> > >
> > >One example is that an application can use TSS APIs to define, undefine,
> > >read, and write to the TPM's NVRAM storage.  (The TPM owner password is
> > >required to define NVRAM data.)  An application could potentially fill
> > >up NVRAM and frequently store, change, retrieve data in various places
> > >within NVRAM.  And the data could have various sizes.
> > >
> > >For an example of total NVRAM size, Infineon's TPM has 16K of NVRAM.
> > >
> > >--
> > >Regards,
> > >Corey Bryant
> > >
> > 
> > I just wanted to add that we could really use some direction on
> > which way the community would prefer we go with this.  The 2 options
> > that are on the table at the moment for encoding/decoding the vNVRAM
> > byte stream are BER or JSON visitors.
> > 
> > -- 
> > Regards,
> > Corey Bryant
> 
> I think I like BER better. JSON seems like a bad fit for a
> bunch of binary blobs.
> 

I agree, but I also think that if we use visitors it shouldn't matter
what visitor implementation we use on the backend. It might be a good
idea to build the code around a stable, existing visitor implementation
like the JSON visitors, and then plug in a BER visitor prior to merge
(or after, if the encoding is configurable/detectable).

If a BER visitor provides benefits over JSON (and I do see that being the
case here) and is general enough that it's interchangeable with a JSON
visitor, then I don't see any reason that code wouldn't stand on it's own
rather than as a prereq for vTPM/nvram.

> > >>
> > >>In case of TPM 1.2 there are 3 blobs that can be written at different
> > >>times for different reasons.
> > >>
> > >>Examples: As with a real-world TPM users loading an owner-evict key into
> > >>the TPM will cause the TPM to write that owner-evict key into is own
> > >>NVRAM. This key survives a power-off of the machine. Further, the TPM
> > >>models its own NVRAM slots. Someone writing into this type of memory
> > >>will cause data to be written into the NVRAM. There are other commands
> > >>that the TPM offers that will cause data to be written into NVRAM which
> > >>users can invoke at any time.
> > >>
> > >>The sizes of the NVRAM blobs of the TPM at least vary in size but I
> > >>handle this in the TPM emulation to pad them to fixed size. Depending on
> > >>how many such owner-evict keys are loaded into the TPM its permanent
> > >>state blob size may vary. Other devices may act differently.
> > >>
> > >>We have a-priori knowledge about  the 3 different types of blobs the TPM
> > >>device produces. They are 'registered' once at the beginning (see API)
> > >>and are not 'removed' as such.
> > >>
> > >>Regards,
> > >>     Stefan
> > >>
> > >
> 

Re: [Qemu-devel] vNVRAM / blobstore design

[Joel Schopp]

> Yea it's not hard to invent a random format each time we write something
> on disk.
>
> But I think ASN.1 BER will be useful to have in qemu anyway.  E.g. it's a
> better format for migration than what we have now.  Once we have it in
> tree re-using it seems cleaner than maintaining some per-TPM thing.
>

The asn.1 patches that have been posted seem to be getting a cool 
reception.  If people think asn.1 is the way to go some more review 
comments, acked-bys, reviewed-bys, or signed-off-bys would make that 
more likely to happen.  The patches have gone through several rounds of 
review and come with a decent set of tests but still haven't been 
merged.  I think they are very mergable.

I'm pretty agnostic on the encoding format.  If the community wanted 
nvram encoded in sandscrit I'd go off and write a sandscrit encoder.  We 
need to decide on something.

Re: [Qemu-devel] vNVRAM / blobstore design

[Kenneth Goldman]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

> Yea it's not hard to invent a random format each time we write something
> on disk.

> But I think ASN.1 BER will be useful to have in qemu anyway.  E.g. it's 
a
> better format for migration than what we have now.  Once we have it in
> tree re-using it seems cleaner than maintaining some per-TPM thing.


The DER can be reused, but someone has to go through every possible TPM 
structure that could be written to NV and define ASN.1 for it.  Even more 
work
is writing tests for all the corner cases. 

I wasn't suggesting inventing a random format, but rather using the native 
TPM
binary formats that are part of its standard and for which implementation 
and 
test code will already exist. 

[-- Attachment #2: Type: text/html, Size: 1022 bytes --]

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/27/2013 12:12 PM, Joel Schopp wrote:
>
>> Yea it's not hard to invent a random format each time we write something
>> on disk.
>>
>> But I think ASN.1 BER will be useful to have in qemu anyway. E.g. it's a
>> better format for migration than what we have now.  Once we have it in
>> tree re-using it seems cleaner than maintaining some per-TPM thing.
>>
>
> The asn.1 patches that have been posted seem to be getting a cool 
> reception.  If people think asn.1 is the way to go some more review 
> comments, acked-bys, reviewed-bys, or signed-off-bys would make that 
> more likely to happen.  The patches have gone through several rounds 
> of review and come with a decent set of tests but still haven't been 
> merged.  I think they are very mergable.

Let me post another version that makes all the tests in 
test-visitor-serialize pass, including the ones using visit_optional.

I also think they are mergeable, but we should discuss a few aspects 
around it. There are standards behind this that we may or may not need 
to implement as such. I am thinking of CER encoding for example that 
imposes restrictions on the size of primitive elements to be less than 
1000 bytes (section 9.2) and need constructed encoding when bigger. We 
may be able to change this limit to PAGE_SIZE * n with n = ?. There may 
be other aspects.

Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Anthony Liguori]

Stefan Berger <stefanb@linux.vnet.ibm.com> writes:

> On 03/27/2013 12:12 PM, Joel Schopp wrote:
>>
>>> Yea it's not hard to invent a random format each time we write something
>>> on disk.
>>>
>>> But I think ASN.1 BER will be useful to have in qemu anyway. E.g. it's a
>>> better format for migration than what we have now.  Once we have it in
>>> tree re-using it seems cleaner than maintaining some per-TPM thing.
>>>
>>
>> The asn.1 patches that have been posted seem to be getting a cool 
>> reception.  If people think asn.1 is the way to go some more review 
>> comments, acked-bys, reviewed-bys, or signed-off-bys would make that 
>> more likely to happen.  The patches have gone through several rounds 
>> of review and come with a decent set of tests but still haven't been 
>> merged.  I think they are very mergable.
>
> Let me post another version that makes all the tests in 
> test-visitor-serialize pass, including the ones using visit_optional.

What I struggle with is that we're calling this a "blobstore".  Using
BER to store "blobs" seems kind of pointless especially when we're
talking about exactly three blobs.

I suspect real hardware does something like, flash is N bytes, blob 1 is
a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X - Y)
bytes.

Do we really need to do anything more than that?

Regards,

Anthony Liguori

>
> I also think they are mergeable, but we should discuss a few aspects 
> around it. There are standards behind this that we may or may not need 
> to implement as such. I am thinking of CER encoding for example that 
> imposes restrictions on the size of primitive elements to be less than 
> 1000 bytes (section 9.2) and need constructed encoding when bigger. We 
> may be able to change this limit to PAGE_SIZE * n with n = ?. There may 
> be other aspects.
>
> Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/27/2013 01:14 PM, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>>
> What I struggle with is that we're calling this a "blobstore".  Using
> BER to store "blobs" seems kind of pointless especially when we're
> talking about exactly three blobs.
>
> I suspect real hardware does something like, flash is N bytes, blob 1 is
> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X - Y)
> bytes.
>
> Do we really need to do anything more than that?

I typically call it NVRAM, but earlier discussions seemed to prefer 
'blobstore'.

Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't 
use any visitors but used a directory in the first sector pointing to 
the actual blobs in other sectors of the block device. The organization 
of the directory and assignment of the blobs to their sectors, aka 'the 
layout of the data' in the disk image, was handled by the 
NVRAM/blobstore implementation.

I think the least one needs is to make the NVRAM/blobstore a bit more 
generic than making it too TPM-specific is to provide a layer that 
organizes the blobs the device may produce and provides functions to 
register those blobs, have them read or written to without the device 
knowing where exactly the data are located on the storage device. A 
nugget of the 1st implementation was that we could encrypt the blobs 
themselves easily which made it also easier to support encrypted blobs 
on non-QCOW2 devices (modulo the loss of snapshotting then).

    Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Wed, Mar 27, 2013 at 12:14:00PM -0500, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> 
> > On 03/27/2013 12:12 PM, Joel Schopp wrote:
> >>
> >>> Yea it's not hard to invent a random format each time we write something
> >>> on disk.
> >>>
> >>> But I think ASN.1 BER will be useful to have in qemu anyway. E.g. it's a
> >>> better format for migration than what we have now.  Once we have it in
> >>> tree re-using it seems cleaner than maintaining some per-TPM thing.
> >>>
> >>
> >> The asn.1 patches that have been posted seem to be getting a cool 
> >> reception.  If people think asn.1 is the way to go some more review 
> >> comments, acked-bys, reviewed-bys, or signed-off-bys would make that 
> >> more likely to happen.  The patches have gone through several rounds 
> >> of review and come with a decent set of tests but still haven't been 
> >> merged.  I think they are very mergable.
> >
> > Let me post another version that makes all the tests in 
> > test-visitor-serialize pass, including the ones using visit_optional.
> 
> What I struggle with is that we're calling this a "blobstore".  Using
> BER to store "blobs" seems kind of pointless especially when we're
> talking about exactly three blobs.
> 
> I suspect real hardware does something like, flash is N bytes, blob 1 is
> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X - Y)
> bytes.
> 
> Do we really need to do anything more than that?
> 
> Regards,
> 
> Anthony Liguori

Last I looked some metadata was stored per blob, for example
I think it has a concept of "number of bytes initialized".
So we'll need to serialize that.
More can come with time ...

> 
> >
> > I also think they are mergeable, but we should discuss a few aspects 
> > around it. There are standards behind this that we may or may not need 
> > to implement as such. I am thinking of CER encoding for example that 
> > imposes restrictions on the size of primitive elements to be less than 
> > 1000 bytes (section 9.2) and need constructed encoding when bigger. We 
> > may be able to change this limit to PAGE_SIZE * n with n = ?. There may 
> > be other aspects.
> >
> > Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Anthony Liguori]

Stefan Berger <stefanb@linux.vnet.ibm.com> writes:

> On 03/27/2013 01:14 PM, Anthony Liguori wrote:
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>>>
>> What I struggle with is that we're calling this a "blobstore".  Using
>> BER to store "blobs" seems kind of pointless especially when we're
>> talking about exactly three blobs.
>>
>> I suspect real hardware does something like, flash is N bytes, blob 1 is
>> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X - Y)
>> bytes.
>>
>> Do we really need to do anything more than that?
>
> I typically call it NVRAM, but earlier discussions seemed to prefer 
> 'blobstore'.
>
> Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't 
> use any visitors but used a directory in the first sector pointing to 
> the actual blobs in other sectors of the block device. The organization 
> of the directory and assignment of the blobs to their sectors, aka 'the 
> layout of the data' in the disk image, was handled by the 
> NVRAM/blobstore implementation.

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.

The long version is below.

> I think the least one needs is to make the NVRAM/blobstore a bit more 
> generic than making it too TPM-specific

'blobstore' is not a hardware concept so making it generic is solving a
problem that doesn't exist.  Hardware typically falls into one of a few
categories:

1) No persistent state

2) Persistent state stored in flash/eeprom in a way that's completely
opaque to software

3) Persistent state stored in flash/eeprom that's visible (either
directly or indirectly) to software.

For (1), there's no discussion here.  For (3), we're forced to use the
same layout that real hardware uses to make the software interface the
same.

As it turns out (2) is almost always such a small amount of state that
it basically doesn't matter.  It's usually stuff like hardware mac
addresses so we don't even bother storing in a marshalled format.  We
just accept properties during device creation.

(2) is rare for large amounts of state because it'd be a waste of
hardware to design an interface on top of NVRAM that is only going to
serve as an API for the device driver which is usually produced by the
same company anyway.

So this is really just not a problem even worth trying to solve.  Even
if it was....

> is to provide a layer that 
> organizes the blobs the device may produce and provides functions to 
> register those blobs, have them read or written to without the device 
> knowing where exactly the data are located on the storage device. A 
> nugget of the 1st implementation was that we could encrypt the blobs 
> themselves easily which made it also easier to support encrypted blobs 
> on non-QCOW2 devices (modulo the loss of snapshotting then).

There is already an API for store named "blobs" that allow them to be
individually encrypted or handled in QEMU.  It's called the Linux VFS
interface.

Really, this whole blobstore thing is just a half-hearted filesystem.
This is why the design rat-holed so quickly.  If we need to use a
filesystem, just use the host filesystem and call it a day.

Regards,

Anthony Liguori

>
>     Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/27/2013 02:27 PM, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 03/27/2013 01:14 PM, Anthony Liguori wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>> What I struggle with is that we're calling this a "blobstore".  Using
>>> BER to store "blobs" seems kind of pointless especially when we're
>>> talking about exactly three blobs.
>>>
>>> I suspect real hardware does something like, flash is N bytes, blob 1 is
>>> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X - Y)
>>> bytes.
>>>
>>> Do we really need to do anything more than that?
>> I typically call it NVRAM, but earlier discussions seemed to prefer
>> 'blobstore'.
>>
>> Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
>> use any visitors but used a directory in the first sector pointing to
>> the actual blobs in other sectors of the block device. The organization
>> of the directory and assignment of the blobs to their sectors, aka 'the
>> layout of the data' in the disk image, was handled by the
>> NVRAM/blobstore implementation.
> 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.

    Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/27/2013 03:12 PM, Stefan Berger wrote:
> On 03/27/2013 02:27 PM, Anthony Liguori wrote:
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>>> On 03/27/2013 01:14 PM, Anthony Liguori wrote:
>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>
>>>> What I struggle with is that we're calling this a "blobstore".  Using
>>>> BER to store "blobs" seems kind of pointless especially when we're
>>>> talking about exactly three blobs.
>>>>
>>>> I suspect real hardware does something like, flash is N bytes, blob 
>>>> 1 is
>>>> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X 
>>>> - Y)
>>>> bytes.
>>>>
>>>> Do we really need to do anything more than that?
>>> I typically call it NVRAM, but earlier discussions seemed to prefer
>>> 'blobstore'.
>>>
>>> Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
>>> use any visitors but used a directory in the first sector pointing to
>>> the actual blobs in other sectors of the block device. The organization
>>> of the directory and assignment of the blobs to their sectors, aka 'the
>>> layout of the data' in the disk image, was handled by the
>>> NVRAM/blobstore implementation.
>> 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. It 
contains garbage. How do we handle this case? Does the TPM then just 
start writing its state into this image or do we want to have some layer 
in place that forces a user to go through the step of formatting after 
that layer indicates that the data are unreadable. Besides that a 
completely empty image also contains garbage from the perspective of TPM 
persistent state and for that layer.

My intention would (again) be to put a header in front of every blob. 
That header would contain a crc32 covering that header (minus the crc32 
field itself of course) plus the blob to determine whether the blob is 
garbage or not. It is similar in those terms as the 1st implementation 
where we also had a directory that contained that crc32 for the 
directory itself and for each blob. This is not a filesystem, I know that.

    Regards,
       Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Thu, Mar 28, 2013 at 12:11:22PM -0400, Stefan Berger wrote:
> On 03/27/2013 03:12 PM, Stefan Berger wrote:
> >On 03/27/2013 02:27 PM, Anthony Liguori wrote:
> >>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>
> >>>On 03/27/2013 01:14 PM, Anthony Liguori wrote:
> >>>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>>>
> >>>>What I struggle with is that we're calling this a "blobstore".  Using
> >>>>BER to store "blobs" seems kind of pointless especially when we're
> >>>>talking about exactly three blobs.
> >>>>
> >>>>I suspect real hardware does something like, flash is N
> >>>>bytes, blob 1 is
> >>>>a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is
> >>>>(N - X - Y)
> >>>>bytes.
> >>>>
> >>>>Do we really need to do anything more than that?
> >>>I typically call it NVRAM, but earlier discussions seemed to prefer
> >>>'blobstore'.
> >>>
> >>>Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
> >>>use any visitors but used a directory in the first sector pointing to
> >>>the actual blobs in other sectors of the block device. The organization
> >>>of the directory and assignment of the blobs to their sectors, aka 'the
> >>>layout of the data' in the disk image, was handled by the
> >>>NVRAM/blobstore implementation.
> >>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. It contains garbage. How do we handle this case? Does the
> TPM then just start writing its state into this image or do we want
> to have some layer in place that forces a user to go through the
> step of formatting after that layer indicates that the data are
> unreadable. Besides that a completely empty image also contains
> garbage from the perspective of TPM persistent state and for that
> layer.
> 
> My intention would (again) be to put a header in front of every
> blob. That header would contain a crc32 covering that header (minus
> the crc32 field itself of course) plus the blob to determine whether
> the blob is garbage or not. It is similar in those terms as the 1st
> implementation where we also had a directory that contained that
> crc32 for the directory itself and for each blob. This is not a
> filesystem, I know that.
> 
>    Regards,
>       Stefan
> 
> 

It was precisely this addition of more and more metadata
that made me suggest a format like BER. But of course
a file per field will do too: following what Anthony suggested you would
put the checksum in a separate file?

-- 
MST

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/28/2013 12:31 PM, Michael S. Tsirkin wrote:
> On Thu, Mar 28, 2013 at 12:11:22PM -0400, Stefan Berger wrote:
>> On 03/27/2013 03:12 PM, Stefan Berger wrote:
>>> On 03/27/2013 02:27 PM, Anthony Liguori wrote:
>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>
>>>>> On 03/27/2013 01:14 PM, Anthony Liguori wrote:
>>>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>>>
>>>>>> What I struggle with is that we're calling this a "blobstore".  Using
>>>>>> BER to store "blobs" seems kind of pointless especially when we're
>>>>>> talking about exactly three blobs.
>>>>>>
>>>>>> I suspect real hardware does something like, flash is N
>>>>>> bytes, blob 1 is
>>>>>> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is
>>>>>> (N - X - Y)
>>>>>> bytes.
>>>>>>
>>>>>> Do we really need to do anything more than that?
>>>>> I typically call it NVRAM, but earlier discussions seemed to prefer
>>>>> 'blobstore'.
>>>>>
>>>>> Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
>>>>> use any visitors but used a directory in the first sector pointing to
>>>>> the actual blobs in other sectors of the block device. The organization
>>>>> of the directory and assignment of the blobs to their sectors, aka 'the
>>>>> layout of the data' in the disk image, was handled by the
>>>>> NVRAM/blobstore implementation.
>>>> 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. It contains garbage. How do we handle this case? Does the
>> TPM then just start writing its state into this image or do we want
>> to have some layer in place that forces a user to go through the
>> step of formatting after that layer indicates that the data are
>> unreadable. Besides that a completely empty image also contains
>> garbage from the perspective of TPM persistent state and for that
>> layer.
>>
>> My intention would (again) be to put a header in front of every
>> blob. That header would contain a crc32 covering that header (minus
>> the crc32 field itself of course) plus the blob to determine whether
>> the blob is garbage or not. It is similar in those terms as the 1st
>> implementation where we also had a directory that contained that
>> crc32 for the directory itself and for each blob. This is not a
>> filesystem, I know that.
>>
>>     Regards,
>>        Stefan
>>
>>
> It was precisely this addition of more and more metadata
> that made me suggest a format like BER. But of course
> a file per field will do too: following what Anthony suggested you would
> put the checksum in a separate file?
>

My intention would be to still support migration, so a block device / 
image file is then probably the best choice addressing this concern 
unless we force every setup to provide a shared filesystem. I think the 
latter wouldn't be accepted.

Another idea (again) would be to support encryption on other image file 
than QCoW2. Here the user would supply the AES key to that persistent 
storage layer and that layer would keep a flag whether the blobs are 
encrypted and encrypt them upon writing , decrypt them upon reading. The 
crc32 also here could serve the purpose of seeing whether the right key 
was supplied, which can be detected upon decryption and the blob's crc 
not matching what was computed when it was written. If crc32 is not good 
enough, we can use a sha1 for this 'integrity' check or possibly the 
padding of AES can reveal the bad decryption as well. Some form of 
integrity checking in conjunction with a formatting step seems 
necessary. Besides that not having to use QCoW2, and with that getting 
automatic support for snapshotting, addresses a concern from the 
virtualized TPM spec that as far as I know doesn't want to see multiple 
states of the same TPM, which in effect snapshotting could cause. So if 
one wanted to be compliant to that spec one could use raw VM image files 
and along with that get encryption and migration.

At least in the following aspects we are away from the hardware-world:

- image files are accessible through the filesystem and can be looked 
into and their secrets retrieved while the NVRAM of a device may be 
shielded and more difficult to be examined (it's not impossible) -> so 
we may want to have encryption for every type of image file and not just 
rely on QCoW2 encryption or assume the image files always reside in 
encrypted filesystems

- admittedly a corner case: persistent storage that contains garbage 
needs to be consciously formatted or the user asked what to do; an image 
file with all zeros could probably be detected, though, but if we 
require formatting for the case where garbage is found,we may as well 
require it here also

I understand your suggestion with the BER encoding.  One problematic 
aspect of the whole BER stuff including all the other patches around it 
seem to be that they are be too big (~5.5ksloc) to find much love.

    Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Anthony Liguori]

Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 03/27/2013 01:14 PM, Anthony Liguori wrote:
>>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>>
>>>>> What I struggle with is that we're calling this a "blobstore".  Using
>>>>> BER to store "blobs" seems kind of pointless especially when we're
>>>>> talking about exactly three blobs.
>>>>>
>>>>> I suspect real hardware does something like, flash is N bytes, blob 
>>>>> 1 is
>>>>> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X 
>>>>> - Y)
>>>>> bytes.
>>>>>
>>>>> Do we really need to do anything more than that?
>>>> I typically call it NVRAM, but earlier discussions seemed to prefer
>>>> 'blobstore'.
>>>>
>>>> Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
>>>> use any visitors but used a directory in the first sector pointing to
>>>> the actual blobs in other sectors of the block device. The organization
>>>> of the directory and assignment of the blobs to their sectors, aka 'the
>>>> layout of the data' in the disk image, was handled by the
>>>> NVRAM/blobstore implementation.
>>> 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

> It 
> contains garbage. How do we handle this case? Does the TPM then just 
> start writing its state into this image or do we want to have some layer 
> in place that forces a user to go through the step of formatting after 
> that layer indicates that the data are unreadable. Besides that a 
> completely empty image also contains garbage from the perspective of TPM 
> persistent state and for that layer.
>
> My intention would (again) be to put a header in front of every blob. 
> That header would contain a crc32 covering that header (minus the crc32 
> field itself of course) plus the blob to determine whether the blob is 
> garbage or not. It is similar in those terms as the 1st implementation 
> where we also had a directory that contained that crc32 for the 
> directory itself and for each blob. This is not a filesystem, I know that.
>
>     Regards,
>        Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/28/2013 01:27 PM, Anthony Liguori wrote:
> Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com> writes:
>>>>
>>>>> On 03/27/2013 01:14 PM, Anthony Liguori wrote:
>>>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>>>
>>>>>> What I struggle with is that we're calling this a "blobstore".  Using
>>>>>> BER to store "blobs" seems kind of pointless especially when we're
>>>>>> talking about exactly three blobs.
>>>>>>
>>>>>> I suspect real hardware does something like, flash is N bytes, blob
>>>>>> 1 is
>>>>>> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X
>>>>>> - Y)
>>>>>> bytes.
>>>>>>
>>>>>> Do we really need to do anything more than that?
>>>>> I typically call it NVRAM, but earlier discussions seemed to prefer
>>>>> 'blobstore'.
>>>>>
>>>>> Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
>>>>> use any visitors but used a directory in the first sector pointing to
>>>>> the actual blobs in other sectors of the block device. The organization
>>>>> of the directory and assignment of the blobs to their sectors, aka 'the
>>>>> layout of the data' in the disk image, was handled by the
>>>>> NVRAM/blobstore implementation.
>>>> 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?

Firmware inside the hardware may zero out the memory or format it upon 
first run and set a flag indicating that the memory is now in valid 
state -- is that too far fetched ? I don't know what it would do in 
subsequent steps, whether it would add some sort of integrity check to 
the blobs or not or even maintain some form of journal to recover from 
disasters -- it may depend on the quality of the device. Hardware also 
knows that the chip will unlikely be taken apart and the firmware, when 
it sees garbage in memory, may refuse to start up or automatically 
format the device.

    Stefan

> 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
>
>> It
>> contains garbage. How do we handle this case? Does the TPM then just
>> start writing its state into this image or do we want to have some layer
>> in place that forces a user to go through the step of formatting after
>> that layer indicates that the data are unreadable. Besides that a
>> completely empty image also contains garbage from the perspective of TPM
>> persistent state and for that layer.
>>
>> My intention would (again) be to put a header in front of every blob.
>> That header would contain a crc32 covering that header (minus the crc32
>> field itself of course) plus the blob to determine whether the blob is
>> garbage or not. It is similar in those terms as the 1st implementation
>> where we also had a directory that contained that crc32 for the
>> directory itself and for each blob. This is not a filesystem, I know that.
>>
>>      Regards,
>>         Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Thu, Mar 28, 2013 at 12:27:45PM -0500, Anthony Liguori wrote:
> Stefan Berger <stefanb@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 <stefanb@linux.vnet.ibm.com> writes:
> >>>
> >>>> On 03/27/2013 01:14 PM, Anthony Liguori wrote:
> >>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>>>>
> >>>>> What I struggle with is that we're calling this a "blobstore".  Using
> >>>>> BER to store "blobs" seems kind of pointless especially when we're
> >>>>> talking about exactly three blobs.
> >>>>>
> >>>>> I suspect real hardware does something like, flash is N bytes, blob 
> >>>>> 1 is
> >>>>> a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X 
> >>>>> - Y)
> >>>>> bytes.
> >>>>>
> >>>>> Do we really need to do anything more than that?
> >>>> I typically call it NVRAM, but earlier discussions seemed to prefer
> >>>> 'blobstore'.
> >>>>
> >>>> Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
> >>>> use any visitors but used a directory in the first sector pointing to
> >>>> the actual blobs in other sectors of the block device. The organization
> >>>> of the directory and assignment of the blobs to their sectors, aka 'the
> >>>> layout of the data' in the disk image, was handled by the
> >>>> NVRAM/blobstore implementation.
> >>> 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.

> > It 
> > contains garbage. How do we handle this case? Does the TPM then just 
> > start writing its state into this image or do we want to have some layer 
> > in place that forces a user to go through the step of formatting after 
> > that layer indicates that the data are unreadable. Besides that a 
> > completely empty image also contains garbage from the perspective of TPM 
> > persistent state and for that layer.
> >
> > My intention would (again) be to put a header in front of every blob. 
> > That header would contain a crc32 covering that header (minus the crc32 
> > field itself of course) plus the blob to determine whether the blob is 
> > garbage or not. It is similar in those terms as the 1st implementation 
> > where we also had a directory that contained that crc32 for the 
> > directory itself and for each blob. This is not a filesystem, I know that.
> >
> >     Regards,
> >        Stefan

Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

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 <stefanb@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 <stefanb@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
- 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

Re: [Qemu-devel] vNVRAM / blobstore design

[Anthony Liguori]

Stefan Berger <stefanb@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 <stefanb@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 <stefanb@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

Re: [Qemu-devel] vNVRAM / blobstore design

[Kenneth Goldman]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

> 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. It 
> contains garbage. How do we handle this case? Does the TPM then just 
> start writing its state into this image or do we want to have some layer 

> in place that forces a user to go through the step of formatting after 
> that layer indicates that the data are unreadable. Besides that a 
> completely empty image also contains garbage from the perspective of TPM 

> persistent state and for that layer.

A garbage persistent storage should be handled the same way a physical TPM
would handle an NV failure - failure mode.  It's a broken part that must 
be
replaced with a factory fresh part.  That's done by some admin tool 
nulling 
the storage.

Empty (length zero or non-existent) is different from corrupt.  The TPM 
should 
detect that and initialize itself to factory defaults.  Those defaults are 

specified in the TPM specification.

> My intention would (again) be to put a header in front of every blob. 
> That header would contain a crc32 covering that header (minus the crc32 
> field itself of course) plus the blob to determine whether the blob is 
> garbage or not. It is similar in those terms as the 1st implementation 
> where we also had a directory that contained that crc32 for the 
> directory itself and for each blob. This is not a filesystem, I know 
that.

I agree that an integrity value should be included.  This is a security
device, and layers of protection are good.

I wonder about the choice of algorithm.  The TPM doesn't have crc32 code
but it does have SHA-1.  Why not reuse code rather than add a new 
function?

[-- Attachment #2: Type: text/html, Size: 2266 bytes --]

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Fri, Mar 29, 2013 at 01:33:01PM -0400, Kenneth Goldman wrote:
> > 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. It
> > contains garbage. How do we handle this case? Does the TPM then just
> > start writing its state into this image or do we want to have some layer
> > in place that forces a user to go through the step of formatting after
> > that layer indicates that the data are unreadable. Besides that a
> > completely empty image also contains garbage from the perspective of TPM
> > persistent state and for that layer.
> 
> A garbage persistent storage should be handled the same way a physical TPM
> would handle an NV failure - failure mode.  It's a broken part that must be
> replaced with a factory fresh part.  That's done by some admin tool nulling
> the storage.
> 
> Empty (length zero or non-existent) is different from corrupt.  The TPM should
> detect that and initialize itself to factory defaults.  Those defaults are
> specified in the TPM specification.
> 
> > My intention would (again) be to put a header in front of every blob.
> > That header would contain a crc32 covering that header (minus the crc32
> > field itself of course) plus the blob to determine whether the blob is
> > garbage or not. It is similar in those terms as the 1st implementation
> > where we also had a directory that contained that crc32 for the
> > directory itself and for each blob. This is not a filesystem, I know that.
> 
> I agree that an integrity value should be included.  This is a security
> device, and layers of protection are good.
> 
> I wonder about the choice of algorithm.  The TPM doesn't have crc32 code
> but it does have SHA-1.  Why not reuse code rather than add a new function?

You want to protect against someone who is able to
manipulate some bits in the file (content) but not others (hash)?
What's the attack you are trying to protect against here?

I'm guessing the only result of extra checksums would be
unbootable guests when qemu manages to corrupt the checksum
without any help from attackers ...

-- 
MST

Re: [Qemu-devel] vNVRAM / blobstore design

[Kenneth Goldman]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

"Michael S. Tsirkin" <mst@redhat.com> wrote on 03/31/2013 04:17:28 AM:
> 
> You want to protect against someone who is able to
> manipulate some bits in the file (content) but not others (hash)?
> What's the attack you are trying to protect against here?
> 
> I'm guessing the only result of extra checksums would be
> unbootable guests when qemu manages to corrupt the checksum
> without any help from attackers ...

You are of course correct.  I advised an integrity value just to detect
a hardware or software fault.  The check value would not protect against 
an
attack.

[-- Attachment #2: Type: text/html, Size: 792 bytes --]

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Sun, Mar 31, 2013 at 04:48:24PM -0400, Kenneth Goldman wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 03/31/2013 04:17:28 AM:
> >
> > You want to protect against someone who is able to
> > manipulate some bits in the file (content) but not others (hash)?
> > What's the attack you are trying to protect against here?
> >
> > I'm guessing the only result of extra checksums would be
> > unbootable guests when qemu manages to corrupt the checksum
> > without any help from attackers ...
> 
> You are of course correct.  I advised an integrity value just to detect
> a hardware or software fault.  The check value would not protect against an
> attack.

Fair enough, but why protect these bits specifically?
E.g. disk corruption seems more likely (since it's bigger). Add
integrity at that level? Why even stop at detection, let's do error
correction ...

-- 
MST

Re: [Qemu-devel] vNVRAM / blobstore design

[Kenneth Goldman]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

> > You are of course correct.  I advised an integrity value just to 
detect
> > a hardware or software fault.  The check value would not protect 
against an
> > attack.
> 
> Fair enough, but why protect these bits specifically?
> E.g. disk corruption seems more likely (since it's bigger). Add
> integrity at that level? Why even stop at detection, let's do error
> correction ...

Why ... just because it's a security device.  Whenever I code for 
security,
I add layers of protection, constantly looking for "this should never 
happen"
cases.

It might be just a small benefit, but hashing a few kbytes is a small part
of TPM startup time, and the function is already there.  Think of it as 
part
of the larger (and required) TPM self test that a TPM must do.

[-- Attachment #2: Type: text/html, Size: 1088 bytes --]

Re: [Qemu-devel] vNVRAM / blobstore design

[Michael S. Tsirkin]

On Tue, Apr 02, 2013 at 09:24:51AM -0400, Kenneth Goldman wrote:
> > > You are of course correct.  I advised an integrity value just to detect
> > > a hardware or software fault.  The check value would not protect against an
> > > attack.
> >
> > Fair enough, but why protect these bits specifically?
> > E.g. disk corruption seems more likely (since it's bigger). Add
> > integrity at that level? Why even stop at detection, let's do error
> > correction ...
> 
> Why ... just because it's a security device.  Whenever I code for security,

This is virtualization. Everything is for security here.

> I add layers of protection, constantly looking for "this should never happen"
> cases.

Confused. You said this checksum is for integrity not protection ...

> It might be just a small benefit, but hashing a few kbytes is a small part
> of TPM startup time, and the function is already there.

You are ignoring atomicity issues this can introduce in case of e.g.
host or qemu crash. Most likely, the result just will be data loss
in a situation which would be recoverable otherwise.
The reverse of what you were trying to achieve.

>  Think of it as part
> of the larger (and required) TPM self test that a TPM must do.

Required?

-- 
MST