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

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

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 <dgdegra@tycho.nsa.gov> 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 <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>
>>>> ---
>>>>    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