From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: vtpmmgr bug: fails to start if locality!=0 Date: Fri, 14 Nov 2014 13:01:52 -0500 Message-ID: <54664390.3000706@tycho.nsa.gov> References: <1415181601.11486.69.camel@citrix.com> <545BEE4F.3080305@tycho.nsa.gov> <545D564E.4000106@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Emil Condrea Cc: Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 11/14/2014 09:22 AM, Emil Condrea wrote: > I modified linux kernel tpm_tis driver to try to start with locality 2. I > did some logging and after taking a look with dmesg it seems that the IO > pages for other localities are full with 1. > in tpm_tis_init: > for(i=0;i<5;i++){ > release_locality(chip,i,1); > } > ... > wait_startup(chip,2); > request_locality(chip,2) > ... > TPM_RID(2);//FF > TPM_RID(0);//64 > Would this mean that Atmel disabled other localities after manufacturing? I > tried to define a NVRAM index at F200 but I have the same results. My best guess is that locality 2 is disabled until a DRTM launch is done. Since your system does not support a DRTM launch, this guess cannot easily be tested. > I see what you mean about changing the DeepQuote behaviour in order to > provide evidence of the VM launch but I am not sure that I understand what > is the type of extraInfoFlags and what should it contain. Will the UUIDs > and vTPM measurements be stored in extraInfoFlags? extraInfoFlags would be a bitmask defined in a specification, like: 1 - vTPM UUID present 2 - vTPM Group UUID present 4 - vTPM kernel measurement present 8 - vTPM command line argument measurement present 16 - Group configuration hash present 32 - Group master public key hash present ... This allows the later fields to be unambiguously decoded by a verifier without requiring the disclosure of fields that are not needed (for example, the UUIDs could be omitted for privacy reasons). > If we take this as a solution for systems that do not support DRTM lanch, > they will still be forced to use locality 0 if any other is disabled and > the TPM might return busy if other commands are currently running. > > Thanks. > Emil Condrea > > On Sat, Nov 8, 2014 at 1:31 AM, Daniel De Graaf > wrote: > >> On 11/07/2014 05:40 AM, Emil Condrea wrote: >> >>> My system does not support DRTM so I can not test this. I am interested in >>> contributing to vtpm and making this to work without DRTM, can you give me >>> more details about PCRs that need to be implemented using an alternate >>> manner? When someone wants to use other locality than 0 it will run all >>> commands with PCRs disabled? Since the vtpmmgr is tying domU to hardware >>> TPM, deactivating PCRs will result that all commands issued by domU will >>> not use PCRs anymore, right? >>> >> >> The PCRs seen by the domU are emulated by the vTPM, and the vTPM Manager >> has no information on any of their values or updates. Deep quotes may >> include a hash of the vTPM's PCR values, but the vTPM Manager is only >> asserting that the hash was given by the vTPM. >> >> Where should the new layer of PCR values stored? NVRAM ? >>> >> >> They will be stored in the vtpmmgr domain's RAM; in fact, they are already >> stored there (they just need to be used more directly). >> >> The PCRs in question are PCR 20-23, used by the vTPM Manager to store >> information about the vTPM making a deep quote request. In order to >> support more than one vTPM, the values of these PCRs need to be reset when >> a different client connects. However, the reset operation for PCR 20-22 is >> limited to locality 2. >> >> An alternative to this is to embed this information in the externData >> field that is signed by the quote operation. This requires a bit more work >> to provide the same flexibility that the PCRs provided, but it can be made >> equivalently secure. >> >> A deep quote request currently contains a PCR mask and a requestData value >> (20 bytes) from the vTPM. On a deep quote request, the vTPM Manager: >> 1. Reset PCR 20-23 >> 2. Extend information about the requesting vTPM to PCR 20-23 >> - Different information is extended into each PCR >> - Some clients want all information, some only want selected PCRs >> 3. Perform a Quote with externData=requestData on the requested PCRs >> 4. Return the result to the requesting vTPM >> >> The change I am suggesting requires: >> - Add a field to the request - extraInfoFlags >> - Compute externData = SHA1 ( >> requestData >> extraInfoFlags >> [UUIDs if requested] >> [vTPM measurements if requested] >> [vTPM group update policy if requested] >> ) >> - Perform deep quotes using the above externData value instead of the >> value provided by the vTPM. >> >> This change also has the benefit of increasing the flexibility of the >> request - it is simple to define additional flags and add data to the hash >> if needed. >> >> >> On Thu, Nov 6, 2014 at 11:55 PM, Daniel De Graaf >>> wrote: >>> >>> 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? >>>> >>>> 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 >>>> >>>> >>> >> >> -- >> Daniel De Graaf >> National Security Agency >> > -- Daniel De Graaf National Security Agency