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

[Shuaijun Zhang <szhang@research.ait.ie>]

[-- Attachment #1.1: Type: text/plain, Size: 3342 bytes --]

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 <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:
>  --------------------------------
>



-- 
Shuaijun Zhang
Research Engineer
Software Research Institute,
Athlone Institute of Technology, IE
Tel: +353 90 646 8196
http://www.ait.ie/sri/

[-- Attachment #1.2: Type: text/html, Size: 4476 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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