From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shuaijun Zhang Subject: Question about VTPM Implementation Date: Wed, 12 Mar 2014 12:32:24 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2233823502658245312==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============2233823502658245312== Content-Type: multipart/alternative; boundary=001a11c1fe5267f0c104f46807e6 --001a11c1fe5267f0c104f46807e6 Content-Type: text/plain; charset=ISO-8859-1 Hi There, In the document of VTPM (http://xenbits.xen.org/docs/unstable/misc/vtpm.txt ): The Linux dom0 kernel should not try accessing the TPM while the vTPM Manager domain is accessing it. Anyone knows the reason why the dom0 should not access the TPM while vTPM Mgr is accessing it? Thanks & Regards, Jason --001a11c1fe5267f0c104f46807e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi There,

In the document of= VTPM (http:= //xenbits.xen.org/docs/unstable/misc/vtpm.txt):=A0The Linux dom0 kernel should not try accessing the TPM w= hile the vTPM = Manager domain is accessing it.

Anyone knows th= e reason why the dom0 should not access the TPM while vTPM Mgr is accessing= it?

Thanks & Re= gards,
Jason


--001a11c1fe5267f0c104f46807e6-- --===============2233823502658245312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2233823502658245312==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Question about VTPM Implementation Date: Wed, 12 Mar 2014 09:51:46 -0400 Message-ID: <20140312135145.GD3245@phenom.dumpdata.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Shuaijun Zhang , dgdegra@tycho.nsa.gov Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: > Hi There, > > In the document of VTPM (http://xenbits.xen.org/docs/unstable/misc/vtpm.txt > ): The Linux dom0 kernel should not try accessing the TPM while the > vTPM Manager > domain is accessing it. > > Anyone knows the reason why the dom0 should not access the TPM while vTPM > Mgr is accessing it? Lets rope in the maintainer. Perhaps the doc should be updated to explain this. > > Thanks & Regards, > Jason > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Question about VTPM Implementation Date: Wed, 12 Mar 2014 14:35:57 +0000 Message-ID: <1394634957.21145.95.camel@kazak.uk.xensource.com> References: <20140312135145.GD3245@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140312135145.GD3245@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Shuaijun Zhang , dgdegra@tycho.nsa.gov, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Wed, 2014-03-12 at 09:51 -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: > > Hi There, > > > > In the document of VTPM (http://xenbits.xen.org/docs/unstable/misc/vtpm.txt > > ): The Linux dom0 kernel should not try accessing the TPM while the > > vTPM Manager > > domain is accessing it. > > > > Anyone knows the reason why the dom0 should not access the TPM while vTPM > > Mgr is accessing it? Surely this is just the classic two masters accessing a single resource issue. No good can come from having domains poking the same bit of hardware at the same time! > > Lets rope in the maintainer. Perhaps the doc should be updated to explain > this. > > > > > Thanks & Regards, > > Jason > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Wed, 12 Mar 2014 10:37:40 -0400 Message-ID: <53207134.5020009@tycho.nsa.gov> References: <20140312135145.GD3245@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140312135145.GD3245@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Shuaijun Zhang Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: >> Hi There, >> >> In the document of VTPM (http://xenbits.xen.org/docs/unstable/misc/vtpm.txt >> ): The Linux dom0 kernel should not try accessing the TPM while the >> vTPM Manager >> domain is accessing it. >> >> Anyone knows the reason why the dom0 should not access the TPM while vTPM >> Mgr is accessing it? > > Lets rope in the maintainer. Perhaps the doc should be updated to explain > this. > >> >> Thanks & Regards, >> Jason I agree; this docs patch explains the reasoning behind the original guidance and addresses use cases that cannot yet be handled by a virtual TPM. ----------------------------->8-------------------------------- Signed-off-by: Daniel De Graaf --- docs/misc/vtpm.txt | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt index df1dfae..d20b424 100644 --- a/docs/misc/vtpm.txt +++ b/docs/misc/vtpm.txt @@ -120,10 +120,24 @@ the stubdom tree. Compiling the LINUX dom0 kernel: -------------------------------- -The Linux dom0 kernel should not try accessing the TPM while the vTPM -Manager domain is accessing it; the simplest way to accomplish this is -to ensure the kernel is compiled without a driver for the TPM, or avoid -loading the driver by blacklisting the module. +Because the TPM manager uses direct access to the physical TPM, it may interfere +with access to the TPM by dom0. The simplest solution for this is to prevent +dom0 from accessing the physical TPM by compiling the kernel without a driver or +blacklisting the module. If dom0 needs a TPM but does not need to use it during +the boot process (i.e. it is not using IMA), a virtual TPM can be attached to +dom0 after the system is booted. + +Because the TPM manager does not yet accept requests for deep quotes, if a quote +or other request needs to be fulfilled by the physical TPM, dom0 will need to +access the physical TPM. In order to prevent interference, the TPM Manager and +dom0 should use different values for the TPM's locality; since Linux always uses +locality 0, using locality 2 for the TPM Manager is recommended. If both Linux +and the TPM Manager attempt to access the TPM at the same time, the TPM device +will return a busy status; some applications will consider this a fatal error +instead of retrying the command at a later time. If a vTPM gets an error when +loading its key, it will currently generate a fresh vTPM image (with a new EK, +SRK, and blank NVRAM). + Compiling the LINUX domU kernel: -------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shuaijun Zhang Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Wed, 12 Mar 2014 15:20:25 +0000 Message-ID: References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0784985408404027917==" Return-path: In-Reply-To: <53207134.5020009@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============0784985408404027917== Content-Type: multipart/alternative; boundary=20cf300512824328f704f46a60d2 --20cf300512824328f704f46a60d2 Content-Type: text/plain; charset=ISO-8859-1 Thank you for the answer. Is the docs patch already in the git repository, or where can I see this patch. Thank you, Jason On 12 March 2014 14:37, Daniel De Graaf wrote: > On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: > >> On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: >> >>> Hi There, >>> >>> In the document of VTPM (http://xenbits.xen.org/docs/ >>> unstable/misc/vtpm.txt >>> ): The Linux dom0 kernel should not try accessing the TPM while the >>> vTPM Manager >>> domain is accessing it. >>> >>> Anyone knows the reason why the dom0 should not access the TPM while vTPM >>> Mgr is accessing it? >>> >> >> Lets rope in the maintainer. Perhaps the doc should be updated to explain >> this. >> >> >>> Thanks & Regards, >>> Jason >>> >> > I agree; this docs patch explains the reasoning behind the original > guidance > and addresses use cases that cannot yet be handled by a virtual TPM. > > ----------------------------->8-------------------------------- > > Signed-off-by: Daniel De Graaf > --- > docs/misc/vtpm.txt | 22 ++++++++++++++++++---- > 1 file changed, 18 insertions(+), 4 deletions(-) > > diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt > index df1dfae..d20b424 100644 > --- a/docs/misc/vtpm.txt > +++ b/docs/misc/vtpm.txt > @@ -120,10 +120,24 @@ the stubdom tree. > Compiling the LINUX dom0 kernel: > -------------------------------- > -The Linux dom0 kernel should not try accessing the TPM while the vTPM > -Manager domain is accessing it; the simplest way to accomplish this is > -to ensure the kernel is compiled without a driver for the TPM, or avoid > -loading the driver by blacklisting the module. > +Because the TPM manager uses direct access to the physical TPM, it may > interfere > +with access to the TPM by dom0. The simplest solution for this is to > prevent > +dom0 from accessing the physical TPM by compiling the kernel without a > driver or > +blacklisting the module. If dom0 needs a TPM but does not need to use it > during > +the boot process (i.e. it is not using IMA), a virtual TPM can be > attached to > +dom0 after the system is booted. > + > +Because the TPM manager does not yet accept requests for deep quotes, if > a quote > +or other request needs to be fulfilled by the physical TPM, dom0 will > need to > +access the physical TPM. In order to prevent interference, the TPM > Manager and > +dom0 should use different values for the TPM's locality; since Linux > always uses > +locality 0, using locality 2 for the TPM Manager is recommended. If both > Linux > +and the TPM Manager attempt to access the TPM at the same time, the TPM > device > +will return a busy status; some applications will consider this a fatal > error > +instead of retrying the command at a later time. If a vTPM gets an error > when > +loading its key, it will currently generate a fresh vTPM image (with a > new EK, > +SRK, and blank NVRAM). > + > Compiling the LINUX domU kernel: > -------------------------------- > -- Shuaijun Zhang Research Engineer Software Research Institute, Athlone Institute of Technology, IE Tel: +353 90 646 8196 http://www.ait.ie/sri/ --20cf300512824328f704f46a60d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for the answer.
Is the docs patch already in= the git repository, or where can I see this patch.

Thank you,
Jason



On 12 March 2014 14:37, Daniel De Graaf = <dgdegra@tycho.nsa.gov> wrote:
On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote:
Hi There,

In the document of VTPM (http://xenbits.xen.org/docs/unstable/= misc/vtpm.txt
): The Linux dom0 kernel should not try accessing the TPM while the
vTPM Manager
domain is accessing it.

Anyone knows the reason why the dom0 should not access the TPM while vTPM Mgr is accessing it?

Lets rope in the maintainer. Perhaps the doc should be updated to explain this.


Thanks & Regards,
Jason

I agree; this docs patch explains the reasoning behind the original guidanc= e
and addresses use cases that cannot yet be handled by a virtual TPM.

----------------------------->8--------------------------------

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
=A0docs/misc/vtpm.txt | 22 ++++++++++++++++++----
=A01 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt
index df1dfae..d20b424 100644
--- a/docs/misc/vtpm.txt
+++ b/docs/misc/vtpm.txt
@@ -120,10 +120,24 @@ the stubdom tree.
=A0Compiling the LINUX dom0 kernel:
=A0--------------------------------
=A0-The Linux dom0 kernel should not try accessing the TPM while the vTPM -Manager domain is accessing it; the simplest way to accomplish this is
-to ensure the kernel is compiled without a driver for the TPM, or avoid -loading the driver by blacklisting the module.
+Because the TPM manager uses direct access to the physical TPM, it may int= erfere
+with access to the TPM by dom0. =A0The simplest solution for this is to pr= event
+dom0 from accessing the physical TPM by compiling the kernel without a dri= ver or
+blacklisting the module. =A0If dom0 needs a TPM but does not need to use i= t during
+the boot process (i.e. it is not using IMA), a virtual TPM can be attached= to
+dom0 after the system is booted.
+
+Because the TPM manager does not yet accept requests for deep quotes, if a= quote
+or other request needs to be fulfilled by the physical TPM, dom0 will need= to
+access the physical TPM. =A0In order to prevent interference, the TPM Mana= ger and
+dom0 should use different values for the TPM's locality; since Linux a= lways uses
+locality 0, using locality 2 for the TPM Manager is recommended. =A0If bot= h Linux
+and the TPM Manager attempt to access the TPM at the same time, the TPM de= vice
+will return a busy status; some applications will consider this a fatal er= ror
+instead of retrying the command at a later time. =A0If a vTPM gets an erro= r when
+loading its key, it will currently generate a fresh vTPM image (with a new= EK,
+SRK, and blank NVRAM).
+
=A0 Compiling the LINUX domU kernel:
=A0--------------------------------



--
Shuaijun Zha= ng
Research Engineer
Software Research Institute,
Athlone Institut= e of Technology, IE
Tel: +353 90 646 8196
http://www.ait.ie/sri/
--20cf300512824328f704f46a60d2-- --===============0784985408404027917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0784985408404027917==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shuaijun Zhang Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Wed, 12 Mar 2014 16:36:01 +0000 Message-ID: References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3006212408310686666==" Return-path: In-Reply-To: <53207134.5020009@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============3006212408310686666== Content-Type: multipart/alternative; boundary=089e012297669acbbf04f46b6e45 --089e012297669acbbf04f46b6e45 Content-Type: text/plain; charset=ISO-8859-1 That explains the reason. But If the dom0 can't access the TPM, you will not be able to verify the dom0 system & the boot process. Is it not a security risk? Is there any solution that allows me to use vTPM and also be able to verify the dom0 system(host system)? Regards, Jason On 12 March 2014 14:37, Daniel De Graaf wrote: > On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: > >> On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: >> >>> Hi There, >>> >>> In the document of VTPM (http://xenbits.xen.org/docs/ >>> unstable/misc/vtpm.txt >>> ): The Linux dom0 kernel should not try accessing the TPM while the >>> vTPM Manager >>> domain is accessing it. >>> >>> Anyone knows the reason why the dom0 should not access the TPM while vTPM >>> Mgr is accessing it? >>> >> >> Lets rope in the maintainer. Perhaps the doc should be updated to explain >> this. >> >> >>> Thanks & Regards, >>> Jason >>> >> > I agree; this docs patch explains the reasoning behind the original > guidance > and addresses use cases that cannot yet be handled by a virtual TPM. > > ----------------------------->8-------------------------------- > > Signed-off-by: Daniel De Graaf > --- > docs/misc/vtpm.txt | 22 ++++++++++++++++++---- > 1 file changed, 18 insertions(+), 4 deletions(-) > > diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt > index df1dfae..d20b424 100644 > --- a/docs/misc/vtpm.txt > +++ b/docs/misc/vtpm.txt > @@ -120,10 +120,24 @@ the stubdom tree. > Compiling the LINUX dom0 kernel: > -------------------------------- > -The Linux dom0 kernel should not try accessing the TPM while the vTPM > -Manager domain is accessing it; the simplest way to accomplish this is > -to ensure the kernel is compiled without a driver for the TPM, or avoid > -loading the driver by blacklisting the module. > +Because the TPM manager uses direct access to the physical TPM, it may > interfere > +with access to the TPM by dom0. The simplest solution for this is to > prevent > +dom0 from accessing the physical TPM by compiling the kernel without a > driver or > +blacklisting the module. If dom0 needs a TPM but does not need to use it > during > +the boot process (i.e. it is not using IMA), a virtual TPM can be > attached to > +dom0 after the system is booted. > + > +Because the TPM manager does not yet accept requests for deep quotes, if > a quote > +or other request needs to be fulfilled by the physical TPM, dom0 will > need to > +access the physical TPM. In order to prevent interference, the TPM > Manager and > +dom0 should use different values for the TPM's locality; since Linux > always uses > +locality 0, using locality 2 for the TPM Manager is recommended. If both > Linux > +and the TPM Manager attempt to access the TPM at the same time, the TPM > device > +will return a busy status; some applications will consider this a fatal > error > +instead of retrying the command at a later time. If a vTPM gets an error > when > +loading its key, it will currently generate a fresh vTPM image (with a > new EK, > +SRK, and blank NVRAM). > + > Compiling the LINUX domU kernel: > -------------------------------- > -- Shuaijun Zhang Research Engineer Software Research Institute, Athlone Institute of Technology, IE Tel: +353 90 646 8196 http://www.ait.ie/sri/ --089e012297669acbbf04f46b6e45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That explains the reason.=A0
But If the dom= 0 can't access the TPM, you will not be able to verify the dom0 system = & the boot process. Is it not a security risk?
Is there any s= olution that allows me to use vTPM and also be able to verify the dom0 syst= em(host system)?

Regards,
Jason


On 12 March 2014 14:37, Daniel D= e Graaf <dgdegra@tycho.nsa.gov> wrote:
On 03/12/2014 09:51 AM, Konrad Rzeszutek Wil= k wrote:
On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote:
Hi There,

In the document of VTPM (http://xenbits.xen.org/docs/unstable/= misc/vtpm.txt
): The Linux dom0 kernel should not try accessing the TPM while the
vTPM Manager
domain is accessing it.

Anyone knows the reason why the dom0 should not access the TPM while vTPM Mgr is accessing it?

Lets rope in the maintainer. Perhaps the doc should be updated to explain this.


Thanks & Regards,
Jason

I agree; this docs patch explains the reasoning behind the original guidanc= e
and addresses use cases that cannot yet be handled by a virtual TPM.

----------------------------->8--------------------------------

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
=A0docs/misc/vtpm.txt | 22 ++++++++++++++++++----
=A01 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt
index df1dfae..d20b424 100644
--- a/docs/misc/vtpm.txt
+++ b/docs/misc/vtpm.txt
@@ -120,10 +120,24 @@ the stubdom tree.
=A0Compiling the LINUX dom0 kernel:
=A0--------------------------------
=A0-The Linux dom0 kernel should not try accessing the TPM while the vTPM -Manager domain is accessing it; the simplest way to accomplish this is
-to ensure the kernel is compiled without a driver for the TPM, or avoid -loading the driver by blacklisting the module.
+Because the TPM manager uses direct access to the physical TPM, it may int= erfere
+with access to the TPM by dom0. =A0The simplest solution for this is to pr= event
+dom0 from accessing the physical TPM by compiling the kernel without a dri= ver or
+blacklisting the module. =A0If dom0 needs a TPM but does not need to use i= t during
+the boot process (i.e. it is not using IMA), a virtual TPM can be attached= to
+dom0 after the system is booted.
+
+Because the TPM manager does not yet accept requests for deep quotes, if a= quote
+or other request needs to be fulfilled by the physical TPM, dom0 will need= to
+access the physical TPM. =A0In order to prevent interference, the TPM Mana= ger and
+dom0 should use different values for the TPM's locality; since Linux a= lways uses
+locality 0, using locality 2 for the TPM Manager is recommended. =A0If bot= h Linux
+and the TPM Manager attempt to access the TPM at the same time, the TPM de= vice
+will return a busy status; some applications will consider this a fatal er= ror
+instead of retrying the command at a later time. =A0If a vTPM gets an erro= r when
+loading its key, it will currently generate a fresh vTPM image (with a new= EK,
+SRK, and blank NVRAM).
+
=A0 Compiling the LINUX domU kernel:
=A0--------------------------------



--
Shuaijun Zha= ng
Research Engineer
Software Research Institute,
Athlone Institut= e of Technology, IE
Tel: +353 90 646 8196
http://www.ait.ie/sri/
--089e012297669acbbf04f46b6e45-- --===============3006212408310686666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3006212408310686666==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Wed, 12 Mar 2014 14:39:06 -0400 Message-ID: <5320A9CA.8050305@tycho.nsa.gov> References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Shuaijun Zhang Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/12/2014 12:36 PM, Shuaijun Zhang wrote: > That explains the reason. > But If the dom0 can't access the TPM, you will not be able to verify the > dom0 system & the boot process. Is it not a security risk? > Is there any solution that allows me to use vTPM and also be able to verify > the dom0 system(host system)? > > Regards, > Jason At the moment, you need to give dom0 access to the physical TPM to verify the boot process/hypervisor. I have an updated TPM Manager and vTPM domain for Xen 4.5 that supports a "deep quote" operation, using the hardware TPM to produce a quote of pTPM and vTPM PCR values; I plan to post this later today. > > On 12 March 2014 14:37, Daniel De Graaf wrote: > >> On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: >> >>> On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: >>> >>>> Hi There, >>>> >>>> In the document of VTPM (http://xenbits.xen.org/docs/ >>>> unstable/misc/vtpm.txt >>>> ): The Linux dom0 kernel should not try accessing the TPM while the >>>> vTPM Manager >>>> domain is accessing it. >>>> >>>> Anyone knows the reason why the dom0 should not access the TPM while vTPM >>>> Mgr is accessing it? >>>> >>> >>> Lets rope in the maintainer. Perhaps the doc should be updated to explain >>> this. >>> >>> >>>> Thanks & Regards, >>>> Jason >>>> >>> >> I agree; this docs patch explains the reasoning behind the original >> guidance >> and addresses use cases that cannot yet be handled by a virtual TPM. >> >> ----------------------------->8-------------------------------- >> >> Signed-off-by: Daniel De Graaf >> --- >> docs/misc/vtpm.txt | 22 ++++++++++++++++++---- >> 1 file changed, 18 insertions(+), 4 deletions(-) >> >> diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt >> index df1dfae..d20b424 100644 >> --- a/docs/misc/vtpm.txt >> +++ b/docs/misc/vtpm.txt >> @@ -120,10 +120,24 @@ the stubdom tree. >> Compiling the LINUX dom0 kernel: >> -------------------------------- >> -The Linux dom0 kernel should not try accessing the TPM while the vTPM >> -Manager domain is accessing it; the simplest way to accomplish this is >> -to ensure the kernel is compiled without a driver for the TPM, or avoid >> -loading the driver by blacklisting the module. >> +Because the TPM manager uses direct access to the physical TPM, it may >> interfere >> +with access to the TPM by dom0. The simplest solution for this is to >> prevent >> +dom0 from accessing the physical TPM by compiling the kernel without a >> driver or >> +blacklisting the module. If dom0 needs a TPM but does not need to use it >> during >> +the boot process (i.e. it is not using IMA), a virtual TPM can be >> attached to >> +dom0 after the system is booted. >> + >> +Because the TPM manager does not yet accept requests for deep quotes, if >> a quote >> +or other request needs to be fulfilled by the physical TPM, dom0 will >> need to >> +access the physical TPM. In order to prevent interference, the TPM >> Manager and >> +dom0 should use different values for the TPM's locality; since Linux >> always uses >> +locality 0, using locality 2 for the TPM Manager is recommended. If both >> Linux >> +and the TPM Manager attempt to access the TPM at the same time, the TPM >> device >> +will return a busy status; some applications will consider this a fatal >> error >> +instead of retrying the command at a later time. If a vTPM gets an error >> when >> +loading its key, it will currently generate a fresh vTPM image (with a >> new EK, >> +SRK, and blank NVRAM). >> + >> Compiling the LINUX domU kernel: >> -------------------------------- >> > > > -- Daniel De Graaf National Security Agency From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shuaijun Zhang Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Wed, 12 Mar 2014 23:04:48 +0000 Message-ID: References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> <5320A9CA.8050305@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9204041386126888519==" Return-path: In-Reply-To: <5320A9CA.8050305@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============9204041386126888519== Content-Type: multipart/alternative; boundary=001a11c1fe520c595c04f470ddb5 --001a11c1fe520c595c04f470ddb5 Content-Type: text/plain; charset=ISO-8859-1 Thank you so much for the new patches. It is great to see the new patches of vTPM allow to attest both of the dom0 and VMs. I found the commit message of the patches here: http://www.gossamer-threads.com/lists/xen/devel/320297. But I can't find the repository. Can you please point me out where is the source code repository Thank you On 12 March 2014 18:39, Daniel De Graaf wrote: > On 03/12/2014 12:36 PM, Shuaijun Zhang wrote: > >> That explains the reason. >> But If the dom0 can't access the TPM, you will not be able to verify the >> dom0 system & the boot process. Is it not a security risk? >> Is there any solution that allows me to use vTPM and also be able to >> verify >> the dom0 system(host system)? >> >> Regards, >> Jason >> > > At the moment, you need to give dom0 access to the physical TPM to verify > the boot process/hypervisor. I have an updated TPM Manager and vTPM domain > for Xen 4.5 that supports a "deep quote" operation, using the hardware TPM > to produce a quote of pTPM and vTPM PCR values; I plan to post this later > today. > > > >> On 12 March 2014 14:37, Daniel De Graaf wrote: >> >> On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: >>> >>> On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: >>>> >>>> Hi There, >>>>> >>>>> In the document of VTPM (http://xenbits.xen.org/docs/ >>>>> unstable/misc/vtpm.txt >>>>> ): The Linux dom0 kernel should not try accessing the TPM while the >>>>> vTPM Manager >>>>> domain is accessing it. >>>>> >>>>> Anyone knows the reason why the dom0 should not access the TPM while >>>>> vTPM >>>>> Mgr is accessing it? >>>>> >>>>> >>>> Lets rope in the maintainer. Perhaps the doc should be updated to >>>> explain >>>> this. >>>> >>>> >>>> Thanks & Regards, >>>>> Jason >>>>> >>>>> >>>> I agree; this docs patch explains the reasoning behind the original >>> guidance >>> and addresses use cases that cannot yet be handled by a virtual TPM. >>> >>> ----------------------------->8-------------------------------- >>> >>> Signed-off-by: Daniel De Graaf >>> --- >>> docs/misc/vtpm.txt | 22 ++++++++++++++++++---- >>> 1 file changed, 18 insertions(+), 4 deletions(-) >>> >>> diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt >>> index df1dfae..d20b424 100644 >>> --- a/docs/misc/vtpm.txt >>> +++ b/docs/misc/vtpm.txt >>> @@ -120,10 +120,24 @@ the stubdom tree. >>> Compiling the LINUX dom0 kernel: >>> -------------------------------- >>> -The Linux dom0 kernel should not try accessing the TPM while the vTPM >>> -Manager domain is accessing it; the simplest way to accomplish this is >>> -to ensure the kernel is compiled without a driver for the TPM, or avoid >>> -loading the driver by blacklisting the module. >>> +Because the TPM manager uses direct access to the physical TPM, it may >>> interfere >>> +with access to the TPM by dom0. The simplest solution for this is to >>> prevent >>> +dom0 from accessing the physical TPM by compiling the kernel without a >>> driver or >>> +blacklisting the module. If dom0 needs a TPM but does not need to use >>> it >>> during >>> +the boot process (i.e. it is not using IMA), a virtual TPM can be >>> attached to >>> +dom0 after the system is booted. >>> + >>> +Because the TPM manager does not yet accept requests for deep quotes, if >>> a quote >>> +or other request needs to be fulfilled by the physical TPM, dom0 will >>> need to >>> +access the physical TPM. In order to prevent interference, the TPM >>> Manager and >>> +dom0 should use different values for the TPM's locality; since Linux >>> always uses >>> +locality 0, using locality 2 for the TPM Manager is recommended. If >>> both >>> Linux >>> +and the TPM Manager attempt to access the TPM at the same time, the TPM >>> device >>> +will return a busy status; some applications will consider this a fatal >>> error >>> +instead of retrying the command at a later time. If a vTPM gets an >>> error >>> when >>> +loading its key, it will currently generate a fresh vTPM image (with a >>> new EK, >>> +SRK, and blank NVRAM). >>> + >>> Compiling the LINUX domU kernel: >>> -------------------------------- >>> >>> >> >> >> > > -- > Daniel De Graaf > National Security Agency > -- Shuaijun Zhang Research Engineer Software Research Institute, Athlone Institute of Technology, IE Tel: +353 90 646 8196 http://www.ait.ie/sri/ --001a11c1fe520c595c04f470ddb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you so much for the new patches. It is great to see = the new patches of vTPM allow to attest both of the dom0 and VMs.
I fou= nd the commit message of the patches here:=A0http://www.gossamer-threads.com/lists/= xen/devel/320297. But I can't find the repository. Can you please p= oint me out where is the source code repository

Thank you



On 12 March 2014 18:39, Daniel D= e Graaf <dgdegra@tycho.nsa.gov> wrote:
On 03/12/2014 12:36 PM, Shua= ijun Zhang wrote:
That explains the reason.
But If the dom0 can't access the TPM, you will not be able to verify th= e
dom0 system & the boot process. Is it not a security risk?
Is there any solution that allows me to use vTPM and also be able to verify=
the dom0 system(host system)?

Regards,
Jason

At the moment, you need to give dom0 access to the physical TPM to verify the boot process/hypervisor. =A0I have an updated TPM Manager and vTPM doma= in
for Xen 4.5 that supports a "deep quote" operation, using the har= dware TPM
to produce a quote of pTPM and vTPM PCR values; I plan to post this later today.



On 12 March 2014 14:37, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:

On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote:

Hi There,

In the document of VTPM (http://xenbits.xen.org/docs/
unstable/misc/vtpm.txt
): The Linux dom0 kernel should not try accessing the TPM while the
vTPM Manager
domain is accessing it.

Anyone knows the reason why the dom0 should not access the TPM while vTPM Mgr is accessing it?


Lets rope in the maintainer. Perhaps the doc should be updated to explain this.


Thanks & Regards,
Jason


I agree; this docs patch explains the reasoning behind the original
guidance
and addresses use cases that cannot yet be handled by a virtual TPM.

----------------------------->8--------------------------------

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
=A0 docs/misc/vtpm.txt | 22 ++++++++++++++++++----
=A0 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt
index df1dfae..d20b424 100644
--- a/docs/misc/vtpm.txt
+++ b/docs/misc/vtpm.txt
@@ -120,10 +120,24 @@ the stubdom tree.
=A0 Compiling the LINUX dom0 kernel:
=A0 --------------------------------
=A0 -The Linux dom0 kernel should not try accessing the TPM while the vTPM<= br> -Manager domain is accessing it; the simplest way to accomplish this is
-to ensure the kernel is compiled without a driver for the TPM, or avoid -loading the driver by blacklisting the module.
+Because the TPM manager uses direct access to the physical TPM, it may
interfere
+with access to the TPM by dom0. =A0The simplest solution for this is to prevent
+dom0 from accessing the physical TPM by compiling the kernel without a
driver or
+blacklisting the module. =A0If dom0 needs a TPM but does not need to use i= t
during
+the boot process (i.e. it is not using IMA), a virtual TPM can be
attached to
+dom0 after the system is booted.
+
+Because the TPM manager does not yet accept requests for deep quotes, if a quote
+or other request needs to be fulfilled by the physical TPM, dom0 will
need to
+access the physical TPM. =A0In order to prevent interference, the TPM
Manager and
+dom0 should use different values for the TPM's locality; since Linux always uses
+locality 0, using locality 2 for the TPM Manager is recommended. =A0If bot= h
Linux
+and the TPM Manager attempt to access the TPM at the same time, the TPM device
+will return a busy status; some applications will consider this a fatal error
+instead of retrying the command at a later time. =A0If a vTPM gets an erro= r
when
+loading its key, it will currently generate a fresh vTPM image (with a
new EK,
+SRK, and blank NVRAM).
+
=A0 =A0Compiling the LINUX domU kernel:
=A0 --------------------------------






--
Daniel De Graaf
National Security Agency



-- Shuaijun Zhang
Research Engineer
Software Research Institute,
At= hlone Institute of Technology, IE
Tel: +353 90 646 8196
http://www.ait.ie/sri/
--001a11c1fe520c595c04f470ddb5-- --===============9204041386126888519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9204041386126888519==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Wed, 12 Mar 2014 19:41:48 -0400 Message-ID: <5320F0BC.8000108@tycho.nsa.gov> References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> <5320A9CA.8050305@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Shuaijun Zhang Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/12/2014 07:04 PM, Shuaijun Zhang wrote: > Thank you so much for the new patches. It is great to see the new patches > of vTPM allow to attest both of the dom0 and VMs. > I found the commit message of the patches here: > http://www.gossamer-threads.com/lists/xen/devel/320297. But I can't find > the repository. Can you please point me out where is the source code > repository > > Thank you There is no repository with these commits yet (other than the git repository on my computer where they were developed). You can import these patches into your repository using "git am" (or by manually applying the patches) to test. There will also be some follow-on patches adding support scripts to generate the administrative command messages and addressing certain instances where physical TPMs do not exactly conform to the specification. The scripts I have been using for testing are not really suitable for general use, so were not included in this series. > On 12 March 2014 18:39, Daniel De Graaf wrote: > >> On 03/12/2014 12:36 PM, Shuaijun Zhang wrote: >> >>> That explains the reason. >>> But If the dom0 can't access the TPM, you will not be able to verify the >>> dom0 system & the boot process. Is it not a security risk? >>> Is there any solution that allows me to use vTPM and also be able to >>> verify >>> the dom0 system(host system)? >>> >>> Regards, >>> Jason >>> >> >> At the moment, you need to give dom0 access to the physical TPM to verify >> the boot process/hypervisor. I have an updated TPM Manager and vTPM domain >> for Xen 4.5 that supports a "deep quote" operation, using the hardware TPM >> to produce a quote of pTPM and vTPM PCR values; I plan to post this later >> today. >> >> >> >>> On 12 March 2014 14:37, Daniel De Graaf wrote: >>> >>> On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: >>>> >>>> On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: >>>>> >>>>> Hi There, >>>>>> >>>>>> In the document of VTPM (http://xenbits.xen.org/docs/ >>>>>> unstable/misc/vtpm.txt >>>>>> ): The Linux dom0 kernel should not try accessing the TPM while the >>>>>> vTPM Manager >>>>>> domain is accessing it. >>>>>> >>>>>> Anyone knows the reason why the dom0 should not access the TPM while >>>>>> vTPM >>>>>> Mgr is accessing it? >>>>>> >>>>>> >>>>> Lets rope in the maintainer. Perhaps the doc should be updated to >>>>> explain >>>>> this. >>>>> >>>>> >>>>> Thanks & Regards, >>>>>> Jason >>>>>> >>>>>> >>>>> I agree; this docs patch explains the reasoning behind the original >>>> guidance >>>> and addresses use cases that cannot yet be handled by a virtual TPM. >>>> >>>> ----------------------------->8-------------------------------- >>>> >>>> Signed-off-by: Daniel De Graaf >>>> --- >>>> docs/misc/vtpm.txt | 22 ++++++++++++++++++---- >>>> 1 file changed, 18 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt >>>> index df1dfae..d20b424 100644 >>>> --- a/docs/misc/vtpm.txt >>>> +++ b/docs/misc/vtpm.txt >>>> @@ -120,10 +120,24 @@ the stubdom tree. >>>> Compiling the LINUX dom0 kernel: >>>> -------------------------------- >>>> -The Linux dom0 kernel should not try accessing the TPM while the vTPM >>>> -Manager domain is accessing it; the simplest way to accomplish this is >>>> -to ensure the kernel is compiled without a driver for the TPM, or avoid >>>> -loading the driver by blacklisting the module. >>>> +Because the TPM manager uses direct access to the physical TPM, it may >>>> interfere >>>> +with access to the TPM by dom0. The simplest solution for this is to >>>> prevent >>>> +dom0 from accessing the physical TPM by compiling the kernel without a >>>> driver or >>>> +blacklisting the module. If dom0 needs a TPM but does not need to use >>>> it >>>> during >>>> +the boot process (i.e. it is not using IMA), a virtual TPM can be >>>> attached to >>>> +dom0 after the system is booted. >>>> + >>>> +Because the TPM manager does not yet accept requests for deep quotes, if >>>> a quote >>>> +or other request needs to be fulfilled by the physical TPM, dom0 will >>>> need to >>>> +access the physical TPM. In order to prevent interference, the TPM >>>> Manager and >>>> +dom0 should use different values for the TPM's locality; since Linux >>>> always uses >>>> +locality 0, using locality 2 for the TPM Manager is recommended. If >>>> both >>>> Linux >>>> +and the TPM Manager attempt to access the TPM at the same time, the TPM >>>> device >>>> +will return a busy status; some applications will consider this a fatal >>>> error >>>> +instead of retrying the command at a later time. If a vTPM gets an >>>> error >>>> when >>>> +loading its key, it will currently generate a fresh vTPM image (with a >>>> new EK, >>>> +SRK, and blank NVRAM). >>>> + >>>> Compiling the LINUX domU kernel: >>>> -------------------------------- >>>> >>>> >>> >>> >>> >> >> -- >> Daniel De Graaf >> National Security Agency >> > > > -- Daniel De Graaf National Security Agency From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Thu, 13 Mar 2014 11:10:54 +0000 Message-ID: <1394709054.25873.47.camel@kazak.uk.xensource.com> References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53207134.5020009@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: Shuaijun Zhang , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Wed, 2014-03-12 at 10:37 -0400, Daniel De Graaf wrote: > On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: > > On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: > >> Hi There, > >> > >> In the document of VTPM (http://xenbits.xen.org/docs/unstable/misc/vtpm.txt > >> ): The Linux dom0 kernel should not try accessing the TPM while the > >> vTPM Manager > >> domain is accessing it. > >> > >> Anyone knows the reason why the dom0 should not access the TPM while vTPM > >> Mgr is accessing it? > > > > Lets rope in the maintainer. Perhaps the doc should be updated to explain > > this. > > > >> > >> Thanks & Regards, > >> Jason > > I agree; this docs patch explains the reasoning behind the original guidance > and addresses use cases that cannot yet be handled by a virtual TPM. > > ----------------------------->8-------------------------------- > > Signed-off-by: Daniel De Graaf Acked-by: Ian Campbell I tried to apply but it failed because the title lines (and the underlines) in the context are one space further indented than the copy in the tree. This happened with your previous patch to this file too (I fixed it up that time). Do you have another patch in your queue which does this reformatting or is something mangling things? > --- > docs/misc/vtpm.txt | 22 ++++++++++++++++++---- > 1 file changed, 18 insertions(+), 4 deletions(-) > > diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt > index df1dfae..d20b424 100644 > --- a/docs/misc/vtpm.txt > +++ b/docs/misc/vtpm.txt > @@ -120,10 +120,24 @@ the stubdom tree. > Compiling the LINUX dom0 kernel: > -------------------------------- > > -The Linux dom0 kernel should not try accessing the TPM while the vTPM > -Manager domain is accessing it; the simplest way to accomplish this is > -to ensure the kernel is compiled without a driver for the TPM, or avoid > -loading the driver by blacklisting the module. > +Because the TPM manager uses direct access to the physical TPM, it may interfere > +with access to the TPM by dom0. The simplest solution for this is to prevent > +dom0 from accessing the physical TPM by compiling the kernel without a driver or > +blacklisting the module. If dom0 needs a TPM but does not need to use it during > +the boot process (i.e. it is not using IMA), a virtual TPM can be attached to > +dom0 after the system is booted. > + > +Because the TPM manager does not yet accept requests for deep quotes, if a quote > +or other request needs to be fulfilled by the physical TPM, dom0 will need to > +access the physical TPM. In order to prevent interference, the TPM Manager and > +dom0 should use different values for the TPM's locality; since Linux always uses > +locality 0, using locality 2 for the TPM Manager is recommended. If both Linux > +and the TPM Manager attempt to access the TPM at the same time, the TPM device > +will return a busy status; some applications will consider this a fatal error > +instead of retrying the command at a later time. If a vTPM gets an error when > +loading its key, it will currently generate a fresh vTPM image (with a new EK, > +SRK, and blank NVRAM). > + > > Compiling the LINUX domU kernel: > -------------------------------- > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Thu, 13 Mar 2014 10:53:19 -0400 Message-ID: <5321C65F.6000400@tycho.nsa.gov> References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> <1394709054.25873.47.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1394709054.25873.47.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Shuaijun Zhang , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/13/2014 07:10 AM, Ian Campbell wrote: > On Wed, 2014-03-12 at 10:37 -0400, Daniel De Graaf wrote: >> On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote: >>> On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote: >>>> Hi There, >>>> >>>> In the document of VTPM (http://xenbits.xen.org/docs/unstable/misc/vtpm.txt >>>> ): The Linux dom0 kernel should not try accessing the TPM while the >>>> vTPM Manager >>>> domain is accessing it. >>>> >>>> Anyone knows the reason why the dom0 should not access the TPM while vTPM >>>> Mgr is accessing it? >>> >>> Lets rope in the maintainer. Perhaps the doc should be updated to explain >>> this. >>> >>>> >>>> Thanks & Regards, >>>> Jason >> >> I agree; this docs patch explains the reasoning behind the original guidance >> and addresses use cases that cannot yet be handled by a virtual TPM. >> >> ----------------------------->8-------------------------------- >> >> Signed-off-by: Daniel De Graaf > > Acked-by: Ian Campbell > > I tried to apply but it failed because the title lines (and the > underlines) in the context are one space further indented than the copy > in the tree. This happened with your previous patch to this file too (I > fixed it up that time). > > Do you have another patch in your queue which does this reformatting or > is something mangling things? I think Thunderbird is to blame here; I made sure to base this patch on top of xen/staging rather than my work branch, and copy/pasted directly from the patch output. I probably need to revert to using git-send-email as my mail client for sending these patches in the future. >> --- >> docs/misc/vtpm.txt | 22 ++++++++++++++++++---- >> 1 file changed, 18 insertions(+), 4 deletions(-) >> >> diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt >> index df1dfae..d20b424 100644 >> --- a/docs/misc/vtpm.txt >> +++ b/docs/misc/vtpm.txt >> @@ -120,10 +120,24 @@ the stubdom tree. >> Compiling the LINUX dom0 kernel: >> -------------------------------- >> >> -The Linux dom0 kernel should not try accessing the TPM while the vTPM >> -Manager domain is accessing it; the simplest way to accomplish this is >> -to ensure the kernel is compiled without a driver for the TPM, or avoid >> -loading the driver by blacklisting the module. >> +Because the TPM manager uses direct access to the physical TPM, it may interfere >> +with access to the TPM by dom0. The simplest solution for this is to prevent >> +dom0 from accessing the physical TPM by compiling the kernel without a driver or >> +blacklisting the module. If dom0 needs a TPM but does not need to use it during >> +the boot process (i.e. it is not using IMA), a virtual TPM can be attached to >> +dom0 after the system is booted. >> + >> +Because the TPM manager does not yet accept requests for deep quotes, if a quote >> +or other request needs to be fulfilled by the physical TPM, dom0 will need to >> +access the physical TPM. In order to prevent interference, the TPM Manager and >> +dom0 should use different values for the TPM's locality; since Linux always uses >> +locality 0, using locality 2 for the TPM Manager is recommended. If both Linux >> +and the TPM Manager attempt to access the TPM at the same time, the TPM device >> +will return a busy status; some applications will consider this a fatal error >> +instead of retrying the command at a later time. If a vTPM gets an error when >> +loading its key, it will currently generate a fresh vTPM image (with a new EK, >> +SRK, and blank NVRAM). >> + >> >> Compiling the LINUX domU kernel: >> -------------------------------- >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > -- Daniel De Graaf National Security Agency From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Thu, 13 Mar 2014 15:59:36 +0000 Message-ID: <1394726376.25873.127.camel@kazak.uk.xensource.com> References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> <1394709054.25873.47.camel@kazak.uk.xensource.com> <5321C65F.6000400@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5321C65F.6000400@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: Shuaijun Zhang , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, 2014-03-13 at 10:53 -0400, Daniel De Graaf wrote: > On 03/13/2014 07:10 AM, Ian Campbell wrote: > > Do you have another patch in your queue which does this reformatting or > > is something mangling things? > > I think Thunderbird is to blame here; Almost always ;-) > I made sure to base this patch on top > of xen/staging rather than my work branch, and copy/pasted directly from > the patch output. I probably need to revert to using git-send-email as my > mail client for sending these patches in the future. That would be good, thanks. I think I can fix this one up on commit though. Ian. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Date: Fri, 14 Mar 2014 11:01:11 +0000 Message-ID: <1394794871.6442.16.camel@kazak.uk.xensource.com> References: <20140312135145.GD3245@phenom.dumpdata.com> <53207134.5020009@tycho.nsa.gov> <1394709054.25873.47.camel@kazak.uk.xensource.com> <5321C65F.6000400@tycho.nsa.gov> <1394726376.25873.127.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1394726376.25873.127.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: Shuaijun Zhang , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, 2014-03-13 at 15:59 +0000, Ian Campbell wrote: > I think I can fix this one up on commit though. Done and applied, thanks. Ian.