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.
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?
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 <dgde...@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 <dgde...@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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
