On Thu, May 23, 2013 at 01:44:40PM -0400, Corey Bryant wrote:
> This patch series provides VNVRAM persistent storage support that
> QEMU can use internally. The initial target user will be a software
> vTPM 1.2 backend that needs to store keys in VNVRAM and be able to
> reboot/migrate and retain the keys.
>
> This support uses QEMU's block driver to provide persistent storage
> by reading/writing VNVRAM data from/to a drive image. The VNVRAM
> drive image is provided with the -drive command line option just like
> any other drive image and the vnvram_create() API will find it.
>
> The APIs allow for VNVRAM entries to be registered, one at a time,
> each with a maximum blob size. Entry blobs can then be read/written
> from/to an entry on the drive. Here's an example of usage:
>
> VNVRAM *vnvram;
> int errcode
> const VNVRAMEntryName entry_name;
> const char *blob_w = "blob data";
> char *blob_r;
> uint32_t blob_r_size;
>
> vnvram = vnvram_create("drive-ide0-0-0", false, &errcode);
> strcpy((char *)entry_name, "first-entry");
VNVRAMEntryName is very prone to buffer overflow. I hope real code
doesn't use strcpy(). The cast is ugly, please don't hide the type.
> vnvram_register_entry(vnvram, &entry_name, 1024);
> vnvram_write_entry(vnvram, &entry_name, (char *)blob_w, strlen(blob_w)+1);
> vnvram_read_entry(vnvram, &entry_name, &blob_r, &blob_r_size);
These are synchronous functions. If I/O is involved then this is a
problem: QEMU will be blocked waiting for host I/O to complete and the
big QEMU lock is held. This can cause poor guest interactivity and poor
scalability because vcpus cannot make progress, neither can the QEMU
monitor respond.
Stefan
