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