Re: [Xen-devel] [PATCH] docs/vtpm: explain dom0 physical TPM access caveats

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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 <dgdegra@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
> > ---
> >   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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel