Re: Install vTPM on Xen-4.2.2

[Bei Guan <gbtju85@gmail.com>]

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

No, there's no TPM hardware on my PC. If a TPM emulator is used. Does it
still need to map the TPM emulator using the line "iomem=["fed40,5"]" ?

Another question is: Does the vTPM in Xen-4.3-unstable support the
VM migration?

What's functionality of the TPM emulator in current version vtpm-stubdom? I
find there only two libraries crypto/libtpm_crypto.a and tpm/libtpm.a are
compiled in the TPM emulator directory.

Thank you very much.





2013/6/6 Daniel De Graaf <dgdegra@tycho.nsa.gov>

> On 06/05/2013 10:57 PM, Bei Guan wrote:
> [... cropping and moving the config below ...]
>
>
>>> I have applied your patch  tpmfront (v3) to the linux-kernel 3.9.1.
>>> When I create the vtpm_manager, there is an error as the following. (on
>>> Xen-4.3-unstable with TPM emulator)
>>> Does this error has something to do with the TPM emulator?
>>> (PS: I have not yet changed the vtpm manager and vtpm to fit for the
>>> emulator.)
>>>
>>> [root@localhost vtpm-conf]# xl create -c vtpmmgr-stubdom.cfg
>>> Parsing config from vtpmmgr-stubdom.cfg
>>> Daemon running with PID 6631
>>> Xen Minimal OS!
>>>    start_info: 0xa3000(VA)
>>>      nr_pages: 0x1000
>>>    shared_inf: 0xbbcaf000(MA)
>>>       pt_base: 0xa6000(VA)
>>> nr_pt_frames: 0x5
>>>      mfn_list: 0x9b000(VA)
>>>     mod_start: 0x0(VA)
>>>       mod_len: 0
>>>         flags: 0x0
>>>      cmd_line:
>>>    stack:      0x5a7a0-0x7a7a0
>>> MM: Init
>>>        _text: 0x0(VA)
>>>       _etext: 0x39854(VA)
>>>     _erodata: 0x46000(VA)
>>>       _edata: 0x48c00(VA)
>>> stack start: 0x5a7a0(VA)
>>>         _end: 0x9adc0(VA)
>>>    start_pfn: ae
>>>      max_pfn: 1000
>>> Mapping memory range 0x400000 - 0x1000000
>>> setting 0x0-0x46000 readonly
>>> skipped 0x1000
>>> MM: Initialise page allocator for b4000(b4000)-1000000(1000000)
>>> MM: done
>>> Demand map pfns at 1001000-2001001000.
>>> Heap resides at 2001002000-4001002000.
>>> Initialising timer interface
>>> Initialising console ... done.
>>> gnttab_table mapped at 0x1001000.
>>> Initialising scheduler
>>> Thread "Idle": pointer: 0x2001002050, stack: 0xd0000
>>> Thread "xenstore": pointer: 0x2001002800, stack: 0xe0000
>>> xenbus initialised on irq 1 mfn 0x1003e8
>>> Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000
>>> Dummy main: start_info=0x7a8a0
>>> Thread "main": pointer: 0x2001003760, stack: 0x100000
>>> "main"
>>>   Shutting down ()
>>> Shutdown requested: 3
>>> Thread "shutdown" exited.
>>> INFO[VTPM]: Starting vTPM manager domain
>>> INFO[VTPM]: Option: Using tpm_tis driver
>>> ******************* BLKFRONT for device/vbd/768 **********
>>>
>>>
>>> backend at /local/domain/0/backend/qdisk/**19/768
>>> Failed to read /local/domain/0/backend/qdisk/**19/768/feature-barrier.
>>> 32768 sectors of 512 bytes
>>> **************************
>>> blk_open(device/vbd/768) -> 3
>>> ============= Init TPM BACK ================
>>> Thread "tpmback-listener": pointer: 0x20010043f0, stack: 0xf0000
>>> ============= Init TPM TIS Driver ==============
>>> IOMEM Machine Base Address: FED40000
>>> Enabled Localities: 0
>>> Map 1 (fed40, ...) at 0x1006000 failed: -1.
>>>
>>
> This seems to be a failure to map the I/O memory for the physical TPM.
>
>
>  Do_exit called!
>>> base is 0x10fcb8 caller is 0x1f0ea
>>> base is 0x10fcd8 caller is 0x284e3
>>> base is 0x10fd88 caller is 0x285b8
>>> base is 0x10fde8 caller is 0x270cc
>>> base is 0x10fe28 caller is 0x270e4
>>> base is 0x10fe38 caller is 0x1bcc9
>>> base is 0x10fe78 caller is 0x6ffc
>>> base is 0x10ff38 caller is 0x3545
>>> base is 0x10ff68 caller is 0x1fc1c
>>> base is 0x10ffe8 caller is 0x343b
>>>
>>>
>>>
>>>
>>>
>  The config file for vTPM manager is
>>
>> kernel="/root/Xen/xen-4.3-**unstable/stubdom/mini-os-x86_**
>> 64-vtpmmgr/mini-os.gz"
>> memory=16
>> disk=["file:/var/vtpmmgr-**stubdom.img,hda,w"]
>> name="vtpmmgr"
>> iomem=["fed40,5"]
>>
>
> The iomem line here should allow the TPM to be mapped without this error.
> Is
> this on a system with a hardware TPM? If not, then that would explain the
> error.
>
>
>
>>>
>>>
>>>>
>>>>   2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>>
>>>>>
>>>>>   On 06/04/2013 05:03 AM, Bei Guan wrote:
>>>>>
>>>>>>
>>>>>>   2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>>>>
>>>>>>>
>>>>>>>    On 05/29/2013 07:23 AM, Bei Guan wrote:
>>>>>>>
>>>>>>>
>>>>>>>>    Thank you for all your reply. I'll try vTPM on Xen-4.3-unstable.
>>>>>>>>
>>>>>>>>
>>>>>>>>> However, I don't have a physical TPM on my PC. Can I use the TPM
>>>>>>>>> emulator
>>>>>>>>> in Xen-4.3-unstable now?
>>>>>>>>>
>>>>>>>>> Thank you very much,
>>>>>>>>> Bei Guan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    The current TPM Manager requires a physical TPM to be present.
>>>>>>>>> While
>>>>>>>>>
>>>>>>>>>  you could make things work without one, it would require patching
>>>>>>>> either the vTPM or vTPM Manager domains with an alternate sealing
>>>>>>>> mechanism for the long-term keys and source of random numbers.
>>>>>>>>
>>>>>>>>
>>>>>>>>   Hi Daniel,
>>>>>>>>
>>>>>>>
>>>>>>> I'm trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I
>>>>>>> run
>>>>>>> into problems.
>>>>>>> Everything in stubdom seems to be compiled successfully except for
>>>>>>> the
>>>>>>> TPM
>>>>>>> emulator.
>>>>>>>
>>>>>>>
>>>>>>>  I can't help if I don't know what the problems are. Some of the
>>>>>> dependencies
>>>>>> in stubdom may be broken if you got things half-compiled before they
>>>>>> broke,
>>>>>> so a clean tree could help. You also need cmake, but it sounds like
>>>>>> you've
>>>>>> gotten past that point.
>>>>>>
>>>>>>
>>>>>>    I'm not sure how to make the TPM emulator work in Xen-4.3. Can you
>>>>>> give me
>>>>>>
>>>>>>  more detailed instructions? Such as which part of the code need to be
>>>>>>> modified, if necessary. And, how much the coding work need to do to
>>>>>>> make
>>>>>>> the TPM emulator work?
>>>>>>>
>>>>>>>
>>>>>>>  The TPM emulator (vtpm-stubdom) depends on the TPM Manager
>>>>>> (vtpmmgr-stubdom)
>>>>>> to store its encryption keys securely. The TPM Manager uses a physical
>>>>>> TPM
>>>>>> to secure its own storage. Without a physical TPM, this is not
>>>>>> possible, so
>>>>>> possible workarounds include removing the requirement to have a TPM
>>>>>> manager
>>>>>> from the vTPM domain (remove tpmfront references), or to modify the
>>>>>> TPM
>>>>>> manager to not use the physical TPM.
>>>>>>
>>>>>> In either case, you will need to find another source for random
>>>>>> numbers,
>>>>>> which is one thing the physical TPM is used for. Changing the vTPM
>>>>>> would be
>>>>>> simpler than changing the TPM manager; the code you need to change is
>>>>>> ~1000
>>>>>> lines, but most of your changes will be removal of code.
>>>>>>
>>>>>>
>>>>>>    I found there is a code file tpm_tis.c in mini-os/ and
>>>>>> stubdom/ioemu/hw/
>>>>>>
>>>>>>  respectively. What's the difference between them? Is the code
>>>>>>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device?
>>>>>>> And, what's the difference between mini-os/tpm_tis.c and
>>>>>>> drivers/char/tpm/tpm_tis.c in linux kernel?
>>>>>>>
>>>>>>> Thank you very much.
>>>>>>>
>>>>>>>
>>>>>>>  The mini-os driver is derived from the one in the Linux kernel; they
>>>>>> both
>>>>>> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a
>>>>>> hardware
>>>>>> TPM based on qemu's access to a Linux /dev/tpm0 device driver. With
>>>>>> Linux
>>>>>> stub domains, this device can be backed by the tpmfront driver
>>>>>> connected to
>>>>>> the vtpm stubdom.
>>>>>>
>>>>>
>
>
> --
> Daniel De Graaf
> National Security Agency
>



-- 
Best Regards,
Bei Guan

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

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

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