Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0

["Xu, Quan" <quan.xu@xxxxxxxxx>]

Okay, I will test it in next week. 

Thanks 
Quan Xu


From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxx] 
On Behalf Of Emil Condrea
Sent: Friday, November 07, 2014 6:42 PM
To: Xu, Quan
Cc: Daniel De Graaf; Ian Campbell; xen-devel@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0

Xu, my system does not support DRTM launch so if you can test it next week it 
would be great.
Thanks

On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan <quan.xu@xxxxxxxxx> wrote:


> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Daniel De Graaf
> Sent: Friday, November 07, 2014 5:55 AM
> To: Emil Condrea
> Cc: Ian Campbell; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
>
> On 11/05/2014 05:00 AM, Ian Campbell wrote:
> > CCing Daniel.
> >
> > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote:
> >>
> >> I am wondering if this is known issue that when I set locality!=0 to
> >> vtpmmgr it does not start. It is a bit strange that every call to
> >> tpm_tis_status returns 255 and device-id is also FFFF:
> >> 1.2 TPM (device-id=0xFFFF vendor-id = FFFF rev-id = FF).
> >> TPM interface capabilities (0xffffffff):
> >>
> >> I am configuring vtpmmgr using:
> >>
> >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
> >> memory=8
> >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
> >> name="vtpmmgr"
> >> iomem=["fed40,5"]
> >> extra="tpmlocality=2"
> >>
> >>
> >> I also tried using :
> >> iomem=["fed40,1"]
> >> extra="tpmlocality=0"//works well
> >>
> >> or
> >> iomem=["fed42,1"]
> >> extra="tpmlocality=2"
> >> It seems that everything that is not mapped at fed40-fed41 is
> >> FFFFFFFF.
> >>
> >> I have an Atmel TPM chipset.
> >>
> >> Could it be a chipset problem to not handle well different localities?
> >>
> >> When I use locality=0, the device driver info is correct and
> >> everything works fine:
> >> 1.2 TPM (device-id=0x3204 vendor-id = 1114 rev-id = 40) TPM interface
> >> capabilities (0xfd)
>
> This may be an issue with locality 2 being unavailable unless a DRTM launch
> (tboot) is performed. Returning all-ones is the normal response of the x86
> chipset when unmapped MMIO regions are accessed; disabled localities of
> the TPM may act like this.
>
> Does your system support the DRTM launch? If so, can you test it to see if
> this is the issue?

Emil,
tboot supports Intel and OEM systems that are Intel TXT-capable.
If your system does not support DRTM launch, I can test it in next week.


>
> In this case, to better support people who want to use the vTPM Manager
> without a DRTM launch, the features of the vTPM Manager that use the TPM
> 1.2 PCRs may need to be disabled or implemented in an alternate manner
> such as embedding the data in the quote instead of in PCRs. The current
> design was created with the assumption that systems using it would be
> performing a DRTM launch in order to fully secure the boot process.
>
> >> In linux kernel this information is obtained using locality 0 and
> >> after that other commands execute using specified locality.
> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
> >> tree/drivers/char/tpm/tpm_tis.c#n558
>
> Have you tested that other localities work for your TPM under Linux?
>
> >>
> >> Thanks,
> >>
> >> Emil
> >>
>
> --
> Daniel De Graaf
> National Security Agency
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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