Re: vtpmmgr bug: fails to start if locality!=0

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

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