* [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM @ 2013-11-06 14:38 Corey Bryant 2013-11-19 19:50 ` Anthony Liguori 0 siblings, 1 reply; 6+ messages in thread From: Corey Bryant @ 2013-11-06 14:38 UTC (permalink / raw) To: qemu-devel; +Cc: Corey Bryant, aliguori This patch series provides support for a software Trusted Platform Module (otherwise known as a vTPM). This support is provided via a new backend that works with the existing QEMU tpm-tis front end. With this patch series, multiple guests can run with their own vTPM. In comparison, the existing passthrough vTPM does not allow this because the host TPM cannot be shared. Note: There is seabios code that is not yet upstream that is required to run with this support. It provides support such as initialization, ACPI table updates, and menu updates. If anyone would like to run with that support, let me know and I can send you a bios.bin. Following is a sample command line: qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K qemu-system-x86_64 ... \ -drive file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \ -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \ -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0 Corey Bryant (4): tpm: Add TPM NVRAM implementation tpm: Share tpm_write_fatal_error_response tpm: QMP/HMP support for libtpms TPM backend tpm: Provide libtpms software TPM backend configure | 24 ++ hmp.c | 5 + hw/tpm/Makefile.objs | 2 + hw/tpm/tpm_libtpms.c | 885 ++++++++++++++++++++++++++++++++++++++++++ hw/tpm/tpm_nvram.c | 340 ++++++++++++++++ hw/tpm/tpm_nvram.h | 25 ++ hw/tpm/tpm_passthrough.c | 14 - hw/tpm/tpm_tis.h | 1 + include/sysemu/tpm_backend.h | 3 + qapi-schema.json | 18 +- qemu-options.hx | 31 ++- tpm.c | 28 ++- 12 files changed, 1357 insertions(+), 19 deletions(-) create mode 100644 hw/tpm/tpm_libtpms.c create mode 100644 hw/tpm/tpm_nvram.c create mode 100644 hw/tpm/tpm_nvram.h ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM 2013-11-06 14:38 [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM Corey Bryant @ 2013-11-19 19:50 ` Anthony Liguori 2013-11-19 21:32 ` Corey Bryant 0 siblings, 1 reply; 6+ messages in thread From: Anthony Liguori @ 2013-11-19 19:50 UTC (permalink / raw) To: Corey Bryant; +Cc: qemu-devel, Anthony Liguori On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote: > This patch series provides support for a software Trusted Platform > Module (otherwise known as a vTPM). This support is provided via a > new backend that works with the existing QEMU tpm-tis front end. We do device emulation within QEMU. This is fundamentally what QEMU does. Why should we link against an external library instead of providing TPM emulation within QEMU itself? What makes TPM so special here? I know the answer to these questions of course. There isn't a good reason but there exists vTPM as an external tool for historical reasons. I don't think that's a good justification for doing this. libtpms has had no review by anyone and does not have a community around it. Once we link against it, we are responsible for resolving any security issue around it and fixing any bug within it. That's essentially asking us to merge 70k+ LOCS without any review or validation ahead of time. That's an unreasonable request. Regards, Anthony Liguori > With this patch series, multiple guests can run with their own vTPM. > In comparison, the existing passthrough vTPM does not allow this > because the host TPM cannot be shared. > > Note: There is seabios code that is not yet upstream that is > required to run with this support. It provides support such as > initialization, ACPI table updates, and menu updates. If anyone > would like to run with that support, let me know and I can send you > a bios.bin. > > Following is a sample command line: > > qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K > > qemu-system-x86_64 ... \ > -drive file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \ > -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \ > -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0 > > Corey Bryant (4): > tpm: Add TPM NVRAM implementation > tpm: Share tpm_write_fatal_error_response > tpm: QMP/HMP support for libtpms TPM backend > tpm: Provide libtpms software TPM backend > > configure | 24 ++ > hmp.c | 5 + > hw/tpm/Makefile.objs | 2 + > hw/tpm/tpm_libtpms.c | 885 ++++++++++++++++++++++++++++++++++++++++++ > hw/tpm/tpm_nvram.c | 340 ++++++++++++++++ > hw/tpm/tpm_nvram.h | 25 ++ > hw/tpm/tpm_passthrough.c | 14 - > hw/tpm/tpm_tis.h | 1 + > include/sysemu/tpm_backend.h | 3 + > qapi-schema.json | 18 +- > qemu-options.hx | 31 ++- > tpm.c | 28 ++- > 12 files changed, 1357 insertions(+), 19 deletions(-) > create mode 100644 hw/tpm/tpm_libtpms.c > create mode 100644 hw/tpm/tpm_nvram.c > create mode 100644 hw/tpm/tpm_nvram.h > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM 2013-11-19 19:50 ` Anthony Liguori @ 2013-11-19 21:32 ` Corey Bryant 2013-11-19 23:03 ` Anthony Liguori 0 siblings, 1 reply; 6+ messages in thread From: Corey Bryant @ 2013-11-19 21:32 UTC (permalink / raw) To: Anthony Liguori; +Cc: qemu-devel, Anthony Liguori On 11/19/2013 02:50 PM, Anthony Liguori wrote: > On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote: >> This patch series provides support for a software Trusted Platform >> Module (otherwise known as a vTPM). This support is provided via a >> new backend that works with the existing QEMU tpm-tis front end. > > We do device emulation within QEMU. This is fundamentally what QEMU does. > > Why should we link against an external library instead of providing > TPM emulation within QEMU itself? What makes TPM so special here? Because 70k+ LOC *definitely* doesn't have a chance of getting into QEMU, so it makes more sense to link against a library. > > I know the answer to these questions of course. There isn't a good > reason but there exists vTPM as an external tool for historical > reasons. I don't think that's a good justification for doing this. > libtpms has had no review by anyone and does not have a community > around it. Once we link against it, we are responsible for resolving The source is now more readily available on github and while the community is small, there is a community. Besides, QEMU uses other libraries that have very small communities doesn't it? > any security issue around it and fixing any bug within it. Is this really true? Is QEMU responsible for fixing every bug in glibc? -- Regards, Corey Bryant > > That's essentially asking us to merge 70k+ LOCS without any review or > validation ahead of time. That's an unreasonable request. > > Regards, > > Anthony Liguori > >> With this patch series, multiple guests can run with their own vTPM. >> In comparison, the existing passthrough vTPM does not allow this >> because the host TPM cannot be shared. >> >> Note: There is seabios code that is not yet upstream that is >> required to run with this support. It provides support such as >> initialization, ACPI table updates, and menu updates. If anyone >> would like to run with that support, let me know and I can send you >> a bios.bin. >> >> Following is a sample command line: >> >> qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K >> >> qemu-system-x86_64 ... \ >> -drive file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \ >> -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \ >> -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0 >> >> Corey Bryant (4): >> tpm: Add TPM NVRAM implementation >> tpm: Share tpm_write_fatal_error_response >> tpm: QMP/HMP support for libtpms TPM backend >> tpm: Provide libtpms software TPM backend >> >> configure | 24 ++ >> hmp.c | 5 + >> hw/tpm/Makefile.objs | 2 + >> hw/tpm/tpm_libtpms.c | 885 ++++++++++++++++++++++++++++++++++++++++++ >> hw/tpm/tpm_nvram.c | 340 ++++++++++++++++ >> hw/tpm/tpm_nvram.h | 25 ++ >> hw/tpm/tpm_passthrough.c | 14 - >> hw/tpm/tpm_tis.h | 1 + >> include/sysemu/tpm_backend.h | 3 + >> qapi-schema.json | 18 +- >> qemu-options.hx | 31 ++- >> tpm.c | 28 ++- >> 12 files changed, 1357 insertions(+), 19 deletions(-) >> create mode 100644 hw/tpm/tpm_libtpms.c >> create mode 100644 hw/tpm/tpm_nvram.c >> create mode 100644 hw/tpm/tpm_nvram.h >> >> > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM 2013-11-19 21:32 ` Corey Bryant @ 2013-11-19 23:03 ` Anthony Liguori 2013-11-20 22:01 ` Stefan Berger 0 siblings, 1 reply; 6+ messages in thread From: Anthony Liguori @ 2013-11-19 23:03 UTC (permalink / raw) To: Corey Bryant; +Cc: qemu-devel, Anthony Liguori On Tue, Nov 19, 2013 at 1:32 PM, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote: > > On 11/19/2013 02:50 PM, Anthony Liguori wrote: >> >> On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant <coreyb@linux.vnet.ibm.com> >> wrote: >>> >>> This patch series provides support for a software Trusted Platform >>> Module (otherwise known as a vTPM). This support is provided via a >>> new backend that works with the existing QEMU tpm-tis front end. >> >> >> We do device emulation within QEMU. This is fundamentally what QEMU does. >> >> Why should we link against an external library instead of providing >> TPM emulation within QEMU itself? What makes TPM so special here? > > > Because 70k+ LOC *definitely* doesn't have a chance of getting into QEMU, so > it makes more sense to link against a library. That's not because we're terrible people who institute horribly bureaucratic procedures for getting code merged. It's because we have a high standard of quality and work hard to do things in a minimal yet robust fashion. That is a large blob of untested and untrustworthy code. That's nothing against the authors but that's simple a fact of life. >> I know the answer to these questions of course. There isn't a good >> reason but there exists vTPM as an external tool for historical >> reasons. I don't think that's a good justification for doing this. >> libtpms has had no review by anyone and does not have a community >> around it. Once we link against it, we are responsible for resolving > > > The source is now more readily available on github and while the community > is small, there is a community. Besides, QEMU uses other libraries that > have very small communities doesn't it? The repo has 4 commits with 1 contributor. It's a code dump. There is no community. We are extremely careful in the dependencies we carry. >> any security issue around it and fixing any bug within it. > > > Is this really true? Yes. > Is QEMU responsible for fixing every bug in glibc? If a guest can trigger an exploit from QEMU, then during the embargo period you can bet on the fact that QEMU developers would be working to resolve it along with the glibc developers. glibc isn't guest facing. Neither is glib. libtpms is making it a massive security exposure surface. TPMs aren't that complex of a device compared to other things on the platform. There's no reason for it to be 70k of code other than it was someone's playground. If someone wrote a concise implementation of TPM within QEMU, I'd be more than eager to merge it. libtpms is not that. Regards, Anthony Liguori > > -- > Regards, > Corey Bryant > > >> >> That's essentially asking us to merge 70k+ LOCS without any review or >> validation ahead of time. That's an unreasonable request. >> >> Regards, >> >> Anthony Liguori >> >>> With this patch series, multiple guests can run with their own vTPM. >>> In comparison, the existing passthrough vTPM does not allow this >>> because the host TPM cannot be shared. >>> >>> Note: There is seabios code that is not yet upstream that is >>> required to run with this support. It provides support such as >>> initialization, ACPI table updates, and menu updates. If anyone >>> would like to run with that support, let me know and I can send you >>> a bios.bin. >>> >>> Following is a sample command line: >>> >>> qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K >>> >>> qemu-system-x86_64 ... \ >>> -drive >>> file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \ >>> -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \ >>> -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0 >>> >>> Corey Bryant (4): >>> tpm: Add TPM NVRAM implementation >>> tpm: Share tpm_write_fatal_error_response >>> tpm: QMP/HMP support for libtpms TPM backend >>> tpm: Provide libtpms software TPM backend >>> >>> configure | 24 ++ >>> hmp.c | 5 + >>> hw/tpm/Makefile.objs | 2 + >>> hw/tpm/tpm_libtpms.c | 885 >>> ++++++++++++++++++++++++++++++++++++++++++ >>> hw/tpm/tpm_nvram.c | 340 ++++++++++++++++ >>> hw/tpm/tpm_nvram.h | 25 ++ >>> hw/tpm/tpm_passthrough.c | 14 - >>> hw/tpm/tpm_tis.h | 1 + >>> include/sysemu/tpm_backend.h | 3 + >>> qapi-schema.json | 18 +- >>> qemu-options.hx | 31 ++- >>> tpm.c | 28 ++- >>> 12 files changed, 1357 insertions(+), 19 deletions(-) >>> create mode 100644 hw/tpm/tpm_libtpms.c >>> create mode 100644 hw/tpm/tpm_nvram.c >>> create mode 100644 hw/tpm/tpm_nvram.h >>> >>> >> >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM 2013-11-19 23:03 ` Anthony Liguori @ 2013-11-20 22:01 ` Stefan Berger 2013-11-21 1:15 ` Anthony Liguori 0 siblings, 1 reply; 6+ messages in thread From: Stefan Berger @ 2013-11-20 22:01 UTC (permalink / raw) To: Anthony Liguori, Corey Bryant; +Cc: qemu-devel, Anthony Liguori On 11/19/2013 06:03 PM, Anthony Liguori wrote: > On Tue, Nov 19, 2013 at 1:32 PM, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote: >> On 11/19/2013 02:50 PM, Anthony Liguori wrote: >>> On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant <coreyb@linux.vnet.ibm.com> >>> wrote: >>>> This patch series provides support for a software Trusted Platform >>>> Module (otherwise known as a vTPM). This support is provided via a >>>> new backend that works with the existing QEMU tpm-tis front end. >>> >>> We do device emulation within QEMU. This is fundamentally what QEMU does. >>> >>> Why should we link against an external library instead of providing >>> TPM emulation within QEMU itself? What makes TPM so special here? >> >> Because 70k+ LOC *definitely* doesn't have a chance of getting into QEMU, so >> it makes more sense to link against a library. > That's not because we're terrible people who institute horribly > bureaucratic procedures for getting code merged. > > It's because we have a high standard of quality and work hard to do > things in a minimal yet robust fashion. > > That is a large blob of untested and untrustworthy code. That's > nothing against the authors but that's simple a fact of life. That this code is 'untested' is simply not true. There are 7 different function calls used in the patches that call into libtpms. res = TPMLIB_GetTPMProperty(prop, &result); res = TPMLIB_Process(&out, &resp_size, &out_len, in, in_len); res = TPMLIB_Terminate(); res = TPMLIB_MainInit(); TPMLIB_RegisterCallbacks(&callbacks); TPM_Realloc(&entry->buffer, length); TPM_Free((unsigned char *)*entry); The TPM library's most critical function call is TPMLIB_Process(). It takes a byte array containing a TPM command and processes it and returns a byte array with the command's response. Any kind of testing will concentrate on this function call since this function implements the TPM's core functionality. Any implementation of a software TPM will need this. I can now point you to the following: - the TSS test suite that exercises the TSS and with it it the TPM; the tests will ultimately run TPM commands, thus exercising this function call - a test suite that is part of a package at sourceforge and will also exercise this function call http://sourceforge.net/projects/ibmswtpm/files/?source=navbar - there is a test suite for TCG members that can be used for testing hardware TPMs and this software TPM; however, it's not open-source, but we could probably get some feedback about how well this software TPM passes this test suite So libtpms would be one of many (using ldd we counted more than 90) libraries that QEMU links against already today. Regards, Stefan > >>> I know the answer to these questions of course. There isn't a good >>> reason but there exists vTPM as an external tool for historical >>> reasons. I don't think that's a good justification for doing this. >>> libtpms has had no review by anyone and does not have a community >>> around it. Once we link against it, we are responsible for resolving >> >> The source is now more readily available on github and while the community >> is small, there is a community. Besides, QEMU uses other libraries that >> have very small communities doesn't it? > The repo has 4 commits with 1 contributor. It's a code dump. There > is no community. > > We are extremely careful in the dependencies we carry. > >>> any security issue around it and fixing any bug within it. >> >> Is this really true? > Yes. > >> Is QEMU responsible for fixing every bug in glibc? > If a guest can trigger an exploit from QEMU, then during the embargo > period you can bet on the fact that QEMU developers would be working > to resolve it along with the glibc developers. > > glibc isn't guest facing. Neither is glib. libtpms is making it a > massive security exposure surface. > > TPMs aren't that complex of a device compared to other things on the > platform. There's no reason for it to be 70k of code other than it > was someone's playground. > > If someone wrote a concise implementation of TPM within QEMU, I'd be > more than eager to merge it. libtpms is not that. > > Regards, > > Anthony Liguori > >> -- >> Regards, >> Corey Bryant >> >> >>> That's essentially asking us to merge 70k+ LOCS without any review or >>> validation ahead of time. That's an unreasonable request. >>> >>> Regards, >>> >>> Anthony Liguori >>> >>>> With this patch series, multiple guests can run with their own vTPM. >>>> In comparison, the existing passthrough vTPM does not allow this >>>> because the host TPM cannot be shared. >>>> >>>> Note: There is seabios code that is not yet upstream that is >>>> required to run with this support. It provides support such as >>>> initialization, ACPI table updates, and menu updates. If anyone >>>> would like to run with that support, let me know and I can send you >>>> a bios.bin. >>>> >>>> Following is a sample command line: >>>> >>>> qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K >>>> >>>> qemu-system-x86_64 ... \ >>>> -drive >>>> file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \ >>>> -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \ >>>> -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0 >>>> >>>> Corey Bryant (4): >>>> tpm: Add TPM NVRAM implementation >>>> tpm: Share tpm_write_fatal_error_response >>>> tpm: QMP/HMP support for libtpms TPM backend >>>> tpm: Provide libtpms software TPM backend >>>> >>>> configure | 24 ++ >>>> hmp.c | 5 + >>>> hw/tpm/Makefile.objs | 2 + >>>> hw/tpm/tpm_libtpms.c | 885 >>>> ++++++++++++++++++++++++++++++++++++++++++ >>>> hw/tpm/tpm_nvram.c | 340 ++++++++++++++++ >>>> hw/tpm/tpm_nvram.h | 25 ++ >>>> hw/tpm/tpm_passthrough.c | 14 - >>>> hw/tpm/tpm_tis.h | 1 + >>>> include/sysemu/tpm_backend.h | 3 + >>>> qapi-schema.json | 18 +- >>>> qemu-options.hx | 31 ++- >>>> tpm.c | 28 ++- >>>> 12 files changed, 1357 insertions(+), 19 deletions(-) >>>> create mode 100644 hw/tpm/tpm_libtpms.c >>>> create mode 100644 hw/tpm/tpm_nvram.c >>>> create mode 100644 hw/tpm/tpm_nvram.h >>>> >>>> >>> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM 2013-11-20 22:01 ` Stefan Berger @ 2013-11-21 1:15 ` Anthony Liguori 0 siblings, 0 replies; 6+ messages in thread From: Anthony Liguori @ 2013-11-21 1:15 UTC (permalink / raw) To: Stefan Berger; +Cc: Corey Bryant, qemu-devel, Anthony Liguori On Wed, Nov 20, 2013 at 2:01 PM, Stefan Berger <stefanb@linux.vnet.ibm.com> wrote: > On 11/19/2013 06:03 PM, Anthony Liguori wrote: >> >> On Tue, Nov 19, 2013 at 1:32 PM, Corey Bryant <coreyb@linux.vnet.ibm.com> >> wrote: >>> >>> On 11/19/2013 02:50 PM, Anthony Liguori wrote: >>>> >>>> On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant <coreyb@linux.vnet.ibm.com> >>>> wrote: >>>>> >>>>> This patch series provides support for a software Trusted Platform >>>>> Module (otherwise known as a vTPM). This support is provided via a >>>>> new backend that works with the existing QEMU tpm-tis front end. >>>> >>>> >>>> We do device emulation within QEMU. This is fundamentally what QEMU >>>> does. >>>> >>>> Why should we link against an external library instead of providing >>>> TPM emulation within QEMU itself? What makes TPM so special here? >>> >>> >>> Because 70k+ LOC *definitely* doesn't have a chance of getting into QEMU, >>> so >>> it makes more sense to link against a library. >> >> That's not because we're terrible people who institute horribly >> bureaucratic procedures for getting code merged. >> >> It's because we have a high standard of quality and work hard to do >> things in a minimal yet robust fashion. >> >> That is a large blob of untested and untrustworthy code. That's >> nothing against the authors but that's simple a fact of life. > > > That this code is 'untested' is simply not true. As far as QEMU is concerned, it's untested. > There are 7 different function calls used in the patches that call into > libtpms. > > res = TPMLIB_GetTPMProperty(prop, &result); > res = TPMLIB_Process(&out, &resp_size, &out_len, in, in_len); > res = TPMLIB_Terminate(); > res = TPMLIB_MainInit(); > TPMLIB_RegisterCallbacks(&callbacks); > TPM_Realloc(&entry->buffer, length); > TPM_Free((unsigned char *)*entry); > > > The TPM library's most critical function call is TPMLIB_Process(). It takes > a byte array containing a TPM command and processes it and returns a byte > array with the command's response. Any kind of testing will concentrate on > this function call since this function implements the TPM's core > functionality. None of this matters. Let me put it in simple terms. If anyone wants TPM (or any device) emulation, the path forward is simple. Break it up into small reviewable chunks, submit on qemu-devel, address review feedback, and repeat. There are no back doors to merging large chunks of code. > Any implementation of a software TPM will need this. I can > now point you to the following: > > - the TSS test suite that exercises the TSS and with it it the TPM; the > tests will ultimately run TPM commands, thus exercising this function call > > - a test suite that is part of a package at sourceforge and will also > exercise this function call > http://sourceforge.net/projects/ibmswtpm/files/?source=navbar > > - there is a test suite for TCG members that can be used for testing > hardware TPMs and this software TPM; however, it's not open-source, but we > could probably get some feedback about how well this software TPM passes > this test suite > > So libtpms would be one of many (using ldd we counted more than 90) > libraries that QEMU links against already today. The vast majority are subdependencies of GTK or SDL most likely. But this is also irrelevant. None of those libraries are directly guest facing (spice being a notable exception). Regards, Anthony Liguori > > Regards, > Stefan > > > > >> >>>> I know the answer to these questions of course. There isn't a good >>>> reason but there exists vTPM as an external tool for historical >>>> reasons. I don't think that's a good justification for doing this. >>>> libtpms has had no review by anyone and does not have a community >>>> around it. Once we link against it, we are responsible for resolving >>> >>> >>> The source is now more readily available on github and while the >>> community >>> is small, there is a community. Besides, QEMU uses other libraries that >>> have very small communities doesn't it? >> >> The repo has 4 commits with 1 contributor. It's a code dump. There >> is no community. >> >> We are extremely careful in the dependencies we carry. >> >>>> any security issue around it and fixing any bug within it. >>> >>> >>> Is this really true? >> >> Yes. >> >>> Is QEMU responsible for fixing every bug in glibc? >> >> If a guest can trigger an exploit from QEMU, then during the embargo >> period you can bet on the fact that QEMU developers would be working >> to resolve it along with the glibc developers. >> >> glibc isn't guest facing. Neither is glib. libtpms is making it a >> massive security exposure surface. >> >> TPMs aren't that complex of a device compared to other things on the >> platform. There's no reason for it to be 70k of code other than it >> was someone's playground. >> >> If someone wrote a concise implementation of TPM within QEMU, I'd be >> more than eager to merge it. libtpms is not that. >> >> Regards, >> >> Anthony Liguori >> >>> -- >>> Regards, >>> Corey Bryant >>> >>> >>>> That's essentially asking us to merge 70k+ LOCS without any review or >>>> validation ahead of time. That's an unreasonable request. >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>>> >>>>> With this patch series, multiple guests can run with their own vTPM. >>>>> In comparison, the existing passthrough vTPM does not allow this >>>>> because the host TPM cannot be shared. >>>>> >>>>> Note: There is seabios code that is not yet upstream that is >>>>> required to run with this support. It provides support such as >>>>> initialization, ACPI table updates, and menu updates. If anyone >>>>> would like to run with that support, let me know and I can send you >>>>> a bios.bin. >>>>> >>>>> Following is a sample command line: >>>>> >>>>> qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K >>>>> >>>>> qemu-system-x86_64 ... \ >>>>> -drive >>>>> file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \ >>>>> -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \ >>>>> -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0 >>>>> >>>>> Corey Bryant (4): >>>>> tpm: Add TPM NVRAM implementation >>>>> tpm: Share tpm_write_fatal_error_response >>>>> tpm: QMP/HMP support for libtpms TPM backend >>>>> tpm: Provide libtpms software TPM backend >>>>> >>>>> configure | 24 ++ >>>>> hmp.c | 5 + >>>>> hw/tpm/Makefile.objs | 2 + >>>>> hw/tpm/tpm_libtpms.c | 885 >>>>> ++++++++++++++++++++++++++++++++++++++++++ >>>>> hw/tpm/tpm_nvram.c | 340 ++++++++++++++++ >>>>> hw/tpm/tpm_nvram.h | 25 ++ >>>>> hw/tpm/tpm_passthrough.c | 14 - >>>>> hw/tpm/tpm_tis.h | 1 + >>>>> include/sysemu/tpm_backend.h | 3 + >>>>> qapi-schema.json | 18 +- >>>>> qemu-options.hx | 31 ++- >>>>> tpm.c | 28 ++- >>>>> 12 files changed, 1357 insertions(+), 19 deletions(-) >>>>> create mode 100644 hw/tpm/tpm_libtpms.c >>>>> create mode 100644 hw/tpm/tpm_nvram.c >>>>> create mode 100644 hw/tpm/tpm_nvram.h >>>>> >>>>> >>>> > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-21 1:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-06 14:38 [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM Corey Bryant 2013-11-19 19:50 ` Anthony Liguori 2013-11-19 21:32 ` Corey Bryant 2013-11-19 23:03 ` Anthony Liguori 2013-11-20 22:01 ` Stefan Berger 2013-11-21 1:15 ` Anthony Liguori
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).