Question about VTPM Implementation

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

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 9 lines · Shuaijun Zhang

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.

Quoted 8 lines

Thanks & Regards,
Jason

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 7 lines · Shuaijun Zhang

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.

Quoted 2 lines

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.

Quoted 3 lines

Thanks & Regards,
Jason

Quoted 10 lines · Konrad Rzeszutek Wilk

Quoted 8 lines · Shuaijun Zhang

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.

Quoted 12 lines

Quoted 3 lines

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.

Quoted 3 lines

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 <[email protected]>

---
 docs/misc/vtpm.txt | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

docs/misc/vtpm.txt +1 -3

index df1dfae..d20b424 100644
@@ -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

docs/misc/vtpm.txt +3 -0

+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,

docs/misc/vtpm.txt +2 -0

+SRK, and blank NVRAM).
+
  Compiling the LINUX domU kernel:
 --------------------------------

Quoted 10 lines · Konrad Rzeszutek Wilk

Quoted 8 lines · Shuaijun Zhang

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.

Quoted 12 lines

Quoted 3 lines

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.

Quoted 3 lines

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 <[email protected]>

---
 docs/misc/vtpm.txt | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

docs/misc/vtpm.txt +1 -3

index df1dfae..d20b424 100644
@@ -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

docs/misc/vtpm.txt +3 -0

+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,

docs/misc/vtpm.txt +2 -0

+SRK, and blank NVRAM).
+
  Compiling the LINUX domU kernel:
 --------------------------------

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

Quoted 82 lines · Konrad Rzeszutek Wilk

Quoted 11 lines · Shuaijun Zhang

Quoted 9 lines

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.

Quoted 12 lines

Quoted 3 lines

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.

Quoted 3 lines

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 <[email protected]>

---
  docs/misc/vtpm.txt | 22 ++++++++++++++++++----
  1 file changed, 18 insertions(+), 4 deletions(-)

docs/misc/vtpm.txt +1 -3

index df1dfae..d20b424 100644
@@ -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

docs/misc/vtpm.txt +3 -0

+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,

docs/misc/vtpm.txt +2 -0

+SRK, and blank NVRAM).
+
   Compiling the LINUX domU kernel:
  --------------------------------

Quoted 10 lines · Shuaijun Zhang

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.

Quoted 81 lines · Daniel De Graaf

Quoted 78 lines · Konrad Rzeszutek Wilk

Quoted 19 lines · Shuaijun Zhang

Hi There,

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

Thanks & Regards,

Quoted 3 lines

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 <[email protected]>

---
  docs/misc/vtpm.txt | 22 ++++++++++++++++++----
  1 file changed, 18 insertions(+), 4 deletions(-)

docs/misc/vtpm.txt +1 -3

index df1dfae..d20b424 100644
@@ -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

docs/misc/vtpm.txt +3 -0

+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

Quoted 11 lines

docs/misc/vtpm.txt the stubdom tree. · line 143

Quoted 8 lines

+loading its key, it will currently generate a fresh vTPM image (with a new EK,

docs/misc/vtpm.txt +2 -0

+SRK, and blank NVRAM).
+
   Compiling the LINUX domU kernel:
  --------------------------------

--
Daniel De Graaf
National Security Agency

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

Quoted 119 lines · Shuaijun Zhang

Quoted 11 lines

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.

Quoted 81 lines · Daniel De Graaf

Quoted 78 lines · Konrad Rzeszutek Wilk

Quoted 19 lines · Shuaijun Zhang

Hi There,

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

Thanks & Regards,

Quoted 3 lines

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 <[email protected]>

---
   docs/misc/vtpm.txt | 22 ++++++++++++++++++----
   1 file changed, 18 insertions(+), 4 deletions(-)

docs/misc/vtpm.txt +1 -3

index df1dfae..d20b424 100644
@@ -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

docs/misc/vtpm.txt +3 -0

+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

Quoted 11 lines

docs/misc/vtpm.txt the stubdom tree. · line 143

Quoted 8 lines

+loading its key, it will currently generate a fresh vTPM image (with a new EK,

docs/misc/vtpm.txt +2 -0

+SRK, and blank NVRAM).
+
    Compiling the LINUX domU kernel:
   --------------------------------

--
Daniel De Graaf
National Security Agency

Quoted 8 lines · Konrad Rzeszutek Wilk

Quoted 7 lines · Shuaijun Zhang

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.

Quoted 9 lines

Quoted 2 lines

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.

Quoted 3 lines

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 <[email protected]>

---
  docs/misc/vtpm.txt | 22 ++++++++++++++++++----
  1 file changed, 18 insertions(+), 4 deletions(-)

docs/misc/vtpm.txt +18 -4

index df1dfae..d20b424 100644
@@ -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
[email protected]
http://lists.xen.org/xen-devel

Quoted 19 lines · Daniel De Graaf

Quoted 8 lines · Konrad Rzeszutek Wilk

Quoted 7 lines · Shuaijun Zhang

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.

Quoted 9 lines

Quoted 2 lines

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.

Quoted 3 lines

Thanks & Regards,
Jason

Quoted 6 lines

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 <[email protected]>

Acked-by Ian Campbell <[email protected]>

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?

Quoted 42 lines

---
   docs/misc/vtpm.txt | 22 ++++++++++++++++++----
   1 file changed, 18 insertions(+), 4 deletions(-)

docs/misc/vtpm.txt +18 -4

index df1dfae..d20b424 100644
@@ -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
[email protected]
http://lists.xen.org/xen-devel

Quoted 2 lines · Ian Campbell

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.

I think I can fix this one up on commit though.