From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzK06-0002X8-NL for qemu-devel@nongnu.org; Thu, 01 Sep 2011 23:01:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzK05-0008VJ-3s for qemu-devel@nongnu.org; Thu, 01 Sep 2011 23:01:02 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:43710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzK04-0008VF-Qx for qemu-devel@nongnu.org; Thu, 01 Sep 2011 23:01:01 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p822r5j5014445 for ; Thu, 1 Sep 2011 20:53:05 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8230wWi178622 for ; Thu, 1 Sep 2011 21:00:58 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p81L0ufd004245 for ; Thu, 1 Sep 2011 15:00:57 -0600 Message-ID: <4E6046E8.60403@linux.vnet.ibm.com> Date: Thu, 01 Sep 2011 23:00:56 -0400 From: Stefan Berger MIME-Version: 1.0 References: <20110831143551.127339744@linux.vnet.ibm.com> <20110831143625.419705972@linux.vnet.ibm.com> <20110901181024.GJ10989@redhat.com> In-Reply-To: <20110901181024.GJ10989@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V8 14/14] Allow to provide inital TPM state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: chrisw@redhat.com, anbang.ruan@cs.ox.ac.uk, qemu-devel@nongnu.org, rrelyea@redhat.com, alevy@redhat.com, andreas.niederl@iaik.tugraz.at, serge@hallyn.com On 09/01/2011 02:10 PM, Michael S. Tsirkin wrote: > On Wed, Aug 31, 2011 at 10:36:05AM -0400, Stefan Berger wrote: >> This patch adds a -tpm ...,initstate=...,... command line option to the >> TPM's existing options and enables the TPM to be initialized with an >> existing state blob. This in turn allows us to simulate TPM manufacturing >> and equip the TPM with an endorsement key, certificates and initialize its >> NVRAM areas etc.. This step is typically done during manufacturng of the TPM >> and/or the (physical) machine. >> >> The initial state can be passed either as file or via a file descriptor. The >> encoding of the state can either be binary or in form of a base64-encoded >> blob surrounded by tags indicating the start and end. >> >> The intial state can be produced through a yet-to-be-published tpm-authoring >> tool. >> >> Signed-off-by: Stefan Berger > I am guessing we get the base64 format from tpmlib? The tpm-authoring tool uses a libtpms-based TPM to create this initial state. In libvirt I (would like to) have the possibility to execute an external script as part of the start of the VM that can create this initial state. The output of that program is pipe()ed into Qemu via a filedescriptor, where libvirt sets up the pipe and passed one end to the program and the other to Qemu. This external script can display other information but the data between the begin and end marker of the base64-encode state are critical and are finally digested by this patch. >> --- >> hw/tpm_builtin.c | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- >> qemu-config.c | 12 +++++ >> qemu-options.hx | 40 ++++++++++++++++- >> 3 files changed, 172 insertions(+), 3 deletions(-) >> >> Index: qemu-git/hw/tpm_builtin.c >> =================================================================== >> --- qemu-git.orig/hw/tpm_builtin.c >> +++ qemu-git/hw/tpm_builtin.c >> @@ -170,9 +170,16 @@ static struct enckey { >> AES_KEY tpm_dec_key; >> } enckey; >> >> +static int tpm_initstatefd = -1; >> +static bool tpm_initstate_bin; >> + > This hardcodes assumption of a single backend. > Yes, there's typically a single TPM in a system. >> static int tpm_builtin_load_sized_data_from_bs(BlockDriverState *bs, >> enum BSEntryType be, >> TPMSizedBuffer *tsb); >> +static TPM_RESULT tpm_builtin_get_initial_state(unsigned char **data, >> + uint32_t *length, >> + size_t tpm_number, >> + const char *name); >> >> >> >> @@ -1269,7 +1276,7 @@ static TPM_RESULT tpm_builtin_nvram_load >> *length = permanent_state.size; >> >> if (*length == 0) { >> - rc = TPM_RETRY; >> + rc = tpm_builtin_get_initial_state(data, length, tpm_number, name); >> } else { >> /* keep a copy of the last permanent state */ >> rc = TPM_Malloc(data, *length); >> @@ -1452,6 +1459,94 @@ static TPM_RESULT tpm_builtin_io_getphys >> } >> >> >> +static TPM_RESULT tpm_builtin_get_initial_state(unsigned char **data, >> + uint32_t *length, >> + size_t tpm_number, >> + const char *name) >> +{ >> + TPM_RESULT rc = TPM_RETRY; >> + uint32_t allocated = 0; >> + int len, flags; >> + unsigned char buf[1024]; >> + unsigned char *result = NULL; >> + size_t result_len; >> + >> + if (tpm_initstatefd>= 0) { >> + *data = NULL; >> + *length = 0; >> + >> + flags = fcntl(tpm_initstatefd, F_GETFL); >> + if (flags< 0 || >> + fcntl(tpm_initstatefd, F_SETFL, flags& ~O_NONBLOCK)< 0) { >> + return TPM_FAIL; >> + } >> + >> + while (TRUE) { >> + len = read(tpm_initstatefd, buf, sizeof(buf)); >> + >> + if (len> 0) { >> + if (len> allocated - *length) { >> + allocated = *length + len + 1024; >> + if (TPM_Realloc(data, allocated) != TPM_SUCCESS) { >> + goto err_exit; >> + } >> + } >> + memcpy(&(*data)[*length], buf, len); >> + *length += len; >> + (*data)[*length] = 0; >> + } else if (len == 0) { >> + rc = TPM_SUCCESS; >> + break; >> + } else if (len< 0) { >> + if (errno == EINTR) { >> + continue; >> + } >> + goto err_exit; >> + } >> + } >> + >> + if (*data == NULL) { >> + /* nothing read */ >> + rc = TPM_FAIL; >> + goto err_exit; >> + } >> + >> + if (!tpm_initstate_bin) { >> + if (TPMLIB_DecodeBlob((char *)*data, TPMLIB_BLOB_TYPE_INITSTATE, >> +&result,&result_len) != TPM_SUCCESS) { >> + goto err_exit; >> + } >> + TPM_Free(*data); >> + *data = result; >> + *length = result_len; >> + result = NULL; >> + } >> + /* sanity check for the size of the blob */ >> + if (*length> tpmlib_get_prop(TPMPROP_TPM_MAX_NV_SPACE)) { >> + goto err_exit; >> + } > Do we really have to hand-craft file reading? > How large is TPMPROP_TPM_MAX_NV_SPACE? > If not too large, we can just allocate that > and do a single fread call? Yes, I could do that, too. > Or, we rely on glib now - can we use > g_io_channel_read_to_end () or something like that? > > GIOStatus g_io_channel_read_to_end (GIOChannel *channel, gchar **str_return, gsize *length, GError **error); I'd rather not use it. Presumably it uses g_malloc() to internally allocate the str_return. However, the buffer we are allocating in this function is given to the libtpms, which in turn will call plain free() on it. I don't want this to cause a problem if not g_free() is called on this buffer. >> + /* have it written into the BlockStorage */ >> + rc = tpm_builtin_nvram_storedata(*data, *length, tpm_number, name); > What if that backend is compiled-out? > link will fail? No, the called function is in the same file. >> + if (rc != TPM_SUCCESS) { >> + goto err_exit; >> + } >> + } >> + >> +norm_exit: >> + close(tpm_initstatefd); >> + tpm_initstatefd = -1; >> + >> + return rc; >> + >> +err_exit: >> + TPM_Free(*data); >> + *data = NULL; >> + *length = 0; >> + TPM_Free(result); >> + >> + goto norm_exit; >> +} >> + >> /*****************************************************************/ >> >> >> @@ -1748,6 +1843,7 @@ static TPMBackend *tpm_builtin_create(Qe >> const char *value; >> unsigned char keyvalue[256/8]; >> int keysize = sizeof(keyvalue); >> + unsigned int offset; >> >> driver = g_malloc(sizeof(TPMBackend)); >> if (!driver) { >> @@ -1801,6 +1897,28 @@ static TPMBackend *tpm_builtin_create(Qe >> enckey.enctype = BS_DIR_ENCTYPE_NONE; >> } >> >> + value = qemu_opt_get(opts, "initstate"); >> + if (value) { >> + offset = 0; >> + >> + if (!strncmp(value, "bin:", 4)) { >> + tpm_initstate_bin = true; >> + offset = 4; >> + } else if (!strncmp(value, "base64:", 7)) { >> + tpm_initstate_bin = false; >> + offset = 7; >> + } >> + >> + if (sscanf(&value[offset], "fd:%d",&tpm_initstatefd) != 1) { >> + tpm_initstatefd = open(&value[offset], O_RDONLY); >> + if (tpm_initstatefd< 0) { >> + fprintf(stderr, "tpm: could not open file '%s' for reading.\n", >> + value); >> + goto err_exit; >> + } >> + } >> + } >> + > Separate options for fd and for file mode would be better. > initstate_fd=base64: initstate_fd=bin: initstate=base64: initstate=bin: Along these lines? >> return driver; >> >> err_exit: >> @@ -1816,6 +1934,9 @@ static void tpm_builtin_destroy(TPMBacke >> g_free(driver->id); >> g_free(driver->model); >> g_free(driver); >> + >> + close(tpm_initstatefd); >> + tpm_initstatefd = -1; >> } >> >> >> Index: qemu-git/qemu-config.c >> =================================================================== >> --- qemu-git.orig/qemu-config.c >> +++ qemu-git/qemu-config.c >> @@ -527,6 +527,12 @@ static QemuOptsList qemu_tpmdev_opts = { >> .type = QEMU_OPT_STRING, >> .help = "Data encryption key", >> }, >> + { >> + .name = "initstate", >> + .type = QEMU_OPT_STRING, >> + .help = "File or file descriptor for reading initial TPM state " >> + "from", >> + }, >> { /* end of list */ } >> }, >> }; >> @@ -556,6 +562,12 @@ static QemuOptsList qemu_tpm_opts = { >> .type = QEMU_OPT_STRING, >> .help = "Data encryption key", >> }, >> + { >> + .name = "initstate", >> + .type = QEMU_OPT_STRING, >> + .help = "File or file descriptor for reading initial TPM state " >> + "from", >> + }, >> { /* end of list */ } >> }, >> }; > I think description should document the magic bin:/base64: etc strings, > or better get rid of them. > I would like to keep both formats... >> Index: qemu-git/qemu-options.hx >> =================================================================== >> --- qemu-git.orig/qemu-options.hx >> +++ qemu-git/qemu-options.hx >> @@ -1767,8 +1767,10 @@ DEFHEADING(TPM device options:) >> DEF("tpm", HAS_ARG, QEMU_OPTION_tpm, \ >> "" \ >> "-tpm builtin,path=[,model=][,key=]\n" \ >> + " [,initstate=[bin:|base64:]fd:|]\n" \ >> " enable a builtin TPM with state in file in path\n" \ >> " and encrypt the TPM's state with the given AES key\n" \ >> + " initstate= path to initial state of TPM; default is base64\n" \ >> "-tpm null enable a TPM null driver that responds with a fault\n" \ >> " message to every TPM request\n" \ >> "-tpm model=? to list available TPM device models\n" \ >> @@ -1800,7 +1802,7 @@ Use ? to print all available TPM backend >> qemu -tpmdev ? >> @end example >> >> -@item -tpmdev builtin ,id=@var{id}, path=@var{path} [,key=@var{key}] >> +@item -tpmdev builtin ,id=@var{id}, path=@var{path} [,key=@var{key}] [,initstate=@var{path}] >> >> Creates an instance of the built-in TPM. >> >> @@ -1830,6 +1832,40 @@ using AES-CBC encryption scheme supply t >> -tpmdev builtin,id=tpm0,path=,key=aes-cbc:0x1234567890abcdef01234567890abcdef -device tpm-tis,tpmdev=tpm0 >> @end example >> >> +@option{initstate} specifies the path to a file containing the initial >> +state of the TPM. It can be used to provide the TPM with an EK and certificates >> +for the EK, TPM and Platform. Since the file contains binary data that >> +have to conform to the TPM's layout of data, it must have been created using >> +an approriate authoring tool. >> + >> +The initstate option allows to provide a binary state blob or one that is >> +encode in base 64. The base64-encode state blob must have the format >> + >> +@example >> +-----BEGIN INITSTATE----- >> + >> +-----END INITSTATE----- >> +@end example >> + >> +The initstate option is only effective when Qemu is started with blank >> +state. >> + >> +The initstate option supports several formats: >> + >> +@table @option >> + @item [base64:] >> + Provide the path to the TPM's initial state blob in base64 format. >> + @item bin: >> + Provide the path to the TPM's initial state blob in binary format. >> + @item [base64:]fd: >> + Provide the base64 formatted initial state via a file descriptor to read from. >> + @item bin:fd: >> + Provide the binary initial state via a file descriptor to read from. > The command line is non standard. E.g. what if the path starts with fd? > Yes, that's a problem. Above would require bin:file: to be understood. Stefan