* Infineon vtpm problem
@ 2008-02-26 23:28 Erdem Bayer
2008-02-27 3:59 ` [Xense-devel] " Stefan Berger
0 siblings, 1 reply; 10+ messages in thread
From: Erdem Bayer @ 2008-02-26 23:28 UTC (permalink / raw)
To: xense-devel, xen-devel
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]
Hi
I have successfully applied the patch mentioned here
(http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html)
to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
After reboot, vtpm_managerd runs ok. (output is attched to the mail.)
I created a pv vm with the option vtpm = ['instance=1, backend=0'] The
vm boots fine.
I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on the vm.
I run tcsd -f on the vm. (output is attched to the mail.)
I checkout and run the trousers test suite. 10 tests passed with 230
failed. (Is this expected?)
When I try tpm_takeownership on the vm, the command runs fine. (Although
a strange warning appers on tcsd output which is attched).
But when I try tpm_sealdata < foo on the vm I get the following error.
Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
Authorization failed
But other tpm_version runs fine on vm.
tpm-test:~# tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.0.4
Spec Level: 2
Errata Revision: 94
TPM Vendor ID:
TPM Version: 01010000
Manufacturer Info: 4554485a
Also this quote is from Xen User's Guide:
"Similarly, the TPM frontend driver must be compiled for the kernel
trying to use TPM functionality. Its driver can be selected in the
kernel configuration section Device Driver / Character Devices / TPM
Devices. Along with that the TPM driver for the built-in TPM must be
selected."
According to my understanding driver for the built-in TPM must be
selected on the kernel where TPM frontend driver is used. Am I correct
about this assumption? (The problem is tpm_infineon driver can not be
selected on an unpriviledged kernel, it can only be selected on a
priviledged kernel)
Am I missing something here? Why do I get auth errors?
Thanks in advance.
Erdem Bayer
[-- Attachment #2: vtpm_managerd.out --]
[-- Type: text/plain, Size: 29874 bytes --]
demo ~ # vtpm_managerd
INFO[VTPM]: Starting VTPM.
INFO[TCS]: Constructing new TCS:
INFO[TCS]: Calling TCS_OpenContext:
INFO[VTSP]: OIAP.
ERROR[VTPM]: Failed to load service data with error = TPM_IOERROR
INFO[VTPM]: Failed to read manager file. Assuming first time initialization.
INFO[VTSP]: Reading Public EK.
INFO[VTSP]: Taking Ownership of TPM.
INFO[VTSP]: OSAP.
INFO[VTSP]: Creating new key of type 20.
INFO[VTSP]: Creating Binding Key...
INFO[VTSP]: OSAP.
INFO[VTSP]: Creating new key of type 20.
INFO[VTSP]: Creating Binding Key...
INFO[VTSP]: Loading Key only into memory.
INFO[VTSP]: Calling TPM_SaveState.
INFO[VTPM]: Finished initialized new VTPM manager (Status = 0).
INFO[VTSP]: Binding 16 bytes of data.
INFO[VTPM]: Saved 256 bytes of E(symkey) + 656 bytes of E(data)
INFO[VTPM]: Saved VTPM Manager state (status = 0, dmis = -1)
INFO[VTSP]: Loading Key into TPM.
INFO[VTPM]: Creating new DMI instance 0 attached.
INFO[TCS]: Calling TCS_OpenContext:
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
INFO[VTPM]: [VTPM Listener]: VTPM Listener waiting for messages.
INFO[VTPM]: [Hotplug Listener]: Hotplug Listener waiting for messages.
INFO[VTPM]: Creating new DMI instance 1 attached.
INFO[TCS]: Calling TCS_OpenContext:
INFO[VTPM]: Launching DMI on PID = 4245
INFO[VTSP]: Binding 16 bytes of data.
INFO[VTPM]: Saved 256 bytes of E(symkey) + 656 bytes of E(data)
INFO[VTPM]: Saved VTPM Manager state (status = 0, dmis = 1)
INFO[VTPM]: [Hotplug Listener]: Hotplug Listener waiting for messages.
TPMD[1]: tpmd.c:126: Info: Initializing tpm state: clear, type: pvm, id: 1
TPMD[1]: tpm/tpm_cmd_handler.c:4137: Debug: tpm_emulator_init()
TPMD[1]: tpm/tpm_startup.c:30: Info: TPM_Init()
TPMD[1]: tpm/tpm_testing.c:242: Info: TPM_SelfTestFull()
TPMD[1]: tpm/tpm_testing.c:42: Debug: tpm_test_prng()
TPMD[1]: tpm/tpm_testing.c:70: Debug: Monobit: 10062
TPMD[1]: tpm/tpm_testing.c:71: Debug: Poker: 14.8
TPMD[1]: tpm/tpm_testing.c:72: Debug: run_1: 2550, 2539
TPMD[1]: tpm/tpm_testing.c:73: Debug: run_2: 1207, 1200
TPMD[1]: tpm/tpm_testing.c:74: Debug: run_3: 646, 626
TPMD[1]: tpm/tpm_testing.c:75: Debug: run_4: 334, 333
TPMD[1]: tpm/tpm_testing.c:76: Debug: run_5: 145, 173
TPMD[1]: tpm/tpm_testing.c:77: Debug: run_6+: 140, 151
TPMD[1]: tpm/tpm_testing.c:78: Debug: run_34: 0
TPMD[1]: tpm/tpm_testing.c:112: Debug: tpm_test_sha1()
TPMD[1]: tpm/tpm_testing.c:156: Debug: tpm_test_hmac()
TPMD[1]: tpm/tpm_testing.c:183: Debug: tpm_test_rsa_EK()
TPMD[1]: tpm/tpm_testing.c:185: Debug: rsa_generate_key()
TPMD[1]: tpm/tpm_testing.c:190: Debug: testing endorsement key
TPMD[1]: tpm/tpm_testing.c:196: Debug: rsa_sign(RSA_SSA_PKCS1_SHA1)
TPMD[1]: tpm/tpm_testing.c:199: Debug: rsa_verify(RSA_SSA_PKCS1_SHA1)
TPMD[1]: tpm/tpm_testing.c:202: Debug: rsa_sign(RSA_SSA_PKCS1_DER)
TPMD[1]: tpm/tpm_testing.c:205: Debug: rsa_verify(RSA_SSA_PKCS1_DER)
TPMD[1]: tpm/tpm_testing.c:209: Debug: rsa_encrypt(RSA_ES_PKCSV15)
TPMD[1]: tpm/tpm_testing.c:213: Debug: rsa_decrypt(RSA_ES_PKCSV15)
TPMD[1]: tpm/tpm_testing.c:217: Debug: verify plain text
TPMD[1]: tpm/tpm_testing.c:220: Debug: rsa_encrypt(RSA_ES_OAEP_SHA1)
TPMD[1]: tpm/tpm_testing.c:224: Debug: rsa_decrypt(RSA_ES_OAEP_SHA1)
TPMD[1]: tpm/tpm_testing.c:228: Debug: verify plain text
TPMD[1]: tpm/tpm_testing.c:260: Info: Self-Test succeeded
TPMD[1]: tpm/tpm_startup.c:45: Info: TPM_Startup(1)
Loading NVM.
Sending LoadNVM command
ERROR[VTPM]: Failed to load NVM
.INFO[VTPM]: [VTPM Listener]: VTPM Listener waiting for messages.
Reading LoadNVM header
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[22]: 0x0 0 0 1 0 c1 0 0 0 12 0 0 0 65 0 0 0 1a 0 0 0 0
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:694: Debug: [TPM_CAP_VERSION_VAL]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
TPMD[1]: tpmd.c:227: Debug: Sent[33]: 0 0 0 1 0 c4 0 0 0 1d 0 0 0 0 0 0 0 f 0 30 1 2 0 4 0 2 5e 0 0 0 0 0 0
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 1 0 0 0 4 0 0 0 b4
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:614: Debug: [TPM_CAP_ORD]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[19]: 0 0 0 1 0 c4 0 0 0 f 0 0 0 0 0 0 0 1 1
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 1 0 0 0 4 0 0 0 b6
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:614: Debug: [TPM_CAP_ORD]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[19]: 0 0 0 1 0 c4 0 0 0 f 0 0 0 0 0 0 0 1 1
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 5 0 0 0 4 0 0 1 1
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:630: Debug: [TPM_CAP_PROPERTY]
TPMD[1]: tpm/tpm_capability.c:63: Debug: [TPM_CAP_PROP_PCR]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[22]: 0 0 0 1 0 c4 0 0 0 12 0 0 0 0 0 0 0 4 0 0 0 18
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 5 0 0 0 4 0 0 1 2
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:630: Debug: [TPM_CAP_PROPERTY]
TPMD[1]: tpm/tpm_capability.c:67: Debug: [TPM_CAP_PROP_DIR]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[22]: 0 0 0 1 0 c4 0 0 0 12 0 0 0 0 0 0 0 4 0 0 0 1
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 5 0 0 0 4 0 0 1 4
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:630: Debug: [TPM_CAP_PROPERTY]
TPMD[1]: tpm/tpm_capability.c:75: Debug: [TPM_CAP_PROP_KEYS]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[22]: 0 0 0 1 0 c4 0 0 0 12 0 0 0 0 0 0 0 4 0 0 0 a
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 5 0 0 0 4 0 0 1 3
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:630: Debug: [TPM_CAP_PROPERTY]
TPMD[1]: tpm/tpm_capability.c:71: Debug: [TPM_CAP_PROP_MANUFACTURER]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[22]: 0 0 0 1 0 c4 0 0 0 12 0 0 0 0 0 0 0 4 45 54 48 5a
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 5 0 0 0 4 0 0 1 d
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:630: Debug: [TPM_CAP_PROPERTY]
TPMD[1]: tpm/tpm_capability.c:103: Debug: [TPM_CAP_PROP_MAX_AUTHSESS]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[22]: 0 0 0 1 0 c4 0 0 0 12 0 0 0 0 0 0 0 4 0 0 0 3
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[22]: 0x0 0 0 1 0 c1 0 0 0 12 0 0 0 65 0 0 0 7 0 0 0 0
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:638: Debug: [TPM_CAP_KEY_HANDLE]
TPMD[1]: tpm/tpm_capability.c:273: Debug: [TPM_RT_KEY]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[20]: 0 0 0 1 0 c4 0 0 0 10 0 0 0 0 0 0 0 2 0 0
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[34]: 0x0 0 0 1 0 c1 0 0 0 1e 0 0 0 7c 88 de b0 9f 91 b3 dc 35 b3 6b dc 8b 71 69 e9 d6 cc 28 df 6c
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3803: Debug: [TPM_ORD_ReadPubek]
TPMD[1]: tpm/tpm_credentials.c:149: Info: TPM_ReadPubek()
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[318]: 0 0 0 1 0 c4 0 0 1 3a 0 0 0 0 0 0 0 1 0 3 0 1 0 0 0 c 0 0 1 0 0 0 0 2 0 0 0 0 0 0 1 0 f3 4a b8 91 eb ab ef c2 a9 43 97 83 8f 74 f7 c a9 d5 e9 90 1e 49 32 f 8d c6 20 41 6c 72 27 1b 82 c c9 68 a6 e8 7b b2 8c e5 77 d0 28 f0 69 9 b7 4b fb 8c 76 bb a4 67 e1 ba 84 59 53 a2 8d 0 1c b2 5e 43 11 d9 74 44 ce 22 b8 7 f4 a4 6e c1 d3 59 c7 b9 7d 81 73 1d 46 ee b2 bc 87 f8 42 66 2d 6c 55 af cf 8a e7 fc d5 cf 89 3c 3e 8d 13 5 1a 31 4f 66 32 85 89 ae 69 52 59 b6 51 44 e4 85 f3 5d 53 9a 83 54 e3 88 23 31 3e a7 fc 9e b6 b2 66 df 15 87 22 9 16 69 24 52 e7 4b d6 e6 8 e6 94 dc ac a5 68 88 1d 4d 3c 4a b4 eb 3c 6b 73 30 ef a6 2f e5 10 36 fa 53 85 9c 6a 68 da bd bf 97 eb 85 91 f6 f7 d0 5d 53 e4 37 53 ab 7d d4 32 79 c9 bd f1 e3 1d e0 42 a2 96 51 74 cd 8e d ea c6 9 7c c0 e3 59 39 24 65 66 fa a8 24 cb 95 76 a7 b9 cd d bc 8c 9 76 f1 3 8e 96 fd 87 99 6f e3 83 a 19 4 9f ae 21 e9 4c 2c 34 3d 26 97 db c6 a4 3f 3f fc
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[14]: 0x0 0 0 1 0 c1 0 0 0 a 0 0 0 a
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3863: Debug: [TPM_ORD_OIAP]
TPMD[1]: tpm/tpm_authorization.c:182: Info: TPM_OIAP()
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[38]: 0 0 0 1 0 c4 0 0 0 22 0 0 0 0 2 0 0 0 9a 94 d3 2b 38 56 cd 90 e8 c1 f da 1f 25 f7 e4 4 c 7e 22
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[628]: 0x0 0 0 1 0 c2 0 0 2 70 0 0 0 d 0 5 0 0 1 0 70 42 48 65 86 1 49 de d9 22 5a 66 fe 6e ef 20 6b a6 5a fe a 88 1 2a 70 9 ac d0 1d a9 de 6f c9 97 9c f3 a0 30 47 26 aa cc 35 55 26 39 6e 86 ca c7 1c e6 2e 35 2f 4b 5f f2 74 51 8d a4 9f 27 7a b2 c9 c3 a 5d ec 5 89 ef 2d dd c5 18 12 e9 54 0 d2 90 a7 81 f9 27 d0 61 ed 38 36 2d 9e b1 66 f 71 73 66 2c e9 a f4 59 b9 de 8a 14 50 72 3a 66 10 a2 a4 fc 90 3 56 20 4d b4 70 56 9c 18 3 20 e ba cf f ab ad 36 53 5c a9 da fc f7 af ea f6 ac 42 b7 7e 35 44 a 11 c4 7e f1 bb 71 6c 55 6b e2 2b dc 19 ee a3 29 b 20 b4 8e 9f 58 3d 22 b1 19 9 69 45 5e aa e5 aa 96 e5 1 32 60 c7 69 34 1b e1 58 fd 54 e9 a6 f2 e5 5c 2c 49 a7 d8 7e 80 a0 48 c1 c6 bd 1b 2a d1 39 90 90 2f 54 a4 ff e4 58 66 36 9 39 25 d1 2 18 be 89 60 b4 e6 5c 5f 3c 14 f8 ec 1a c9 5c f6 6c 6a d7 54 fe 4c 0 0 1 0 25 6c 6d 41 fc 52 1b f 3e dc 78 9a 83 2b bc ae 82 9c 1a 1f f3 2f 5a 1 aa 7a 86 39 b8 a6 7a 79 4a d9 fa f8 35 b8 f3 ec 5c 87 df b3 12 5f f1 d3 45 2f 37 d7 17 63 29 51 b3 53 33 9c 42 3a 39 f4 dc 33 bd 87 b4 10 fd 83 94 39 c0 8a 7e 40 ed eb bd 1a 4d cf 52 b9 d1 28 b1 11 c3 8e 2b b4 d1 1f 17 c0 3e 7e 21 5d 79 6c da 2f c1 9b ba 10 2 38 7c 10 8b 2e 77 28 c 6c 46 33 9d 9e 51 8 c5 fd e4 20 ad 28 3e 85 7a 34 c3 5f c2 55 55 f8 3 43 4b 50 3f 1f d0 19 27 59 90 1 23 8a 77 98 1c 54 67 60 cf 47 d3 45 95 c9 39 e7 f1 e1 b9 29 3e bd c0 2d ff d0 ab 77 e4 7a d4 42 ab 7d 4e 60 1d c5 f3 a5 49 17 ee 7f 6b ea 7 cd b2 7 db 98 71 e6 12 4e 8f 9e 23 e8 33 d a1 88 22 a2 d 3d cc 3 7a 24 79 52 2b 13 9f 7d 60 c3 56 c2 f5 f0 c1 71 8 c3 39 df 39 18 e1 a8 b0 42 51 b 65 aa 58 34 1 1 0 0 0 11 0 0 0 0 1 0 0 0 1 0 3 0 1 0 0 0 c 0 0 8 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 19 b5 5 62 f7 e9 1d 3d ab 4b 7e 88 a4 8 c4 80 a0 20 62 19 0 85 b2 56 6a d0 95 8 55 8a b3 35 e8 5d f3 cb 2c 41 a2 72 1b
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3460: Debug: [TPM_TAG_RQU_AUTH1_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3550: Debug: [TPM_ORD_TakeOwnership]
TPMD[1]: tpm/tpm_owner.c:114: Info: TPM_TakeOwnership()
TPMD[1]: tpm/tpm_authorization.c:289: Info: tpm_verify_auth()
TPMD[1]: tpm/tpm_authorization.c:290: Debug: [ handle=02000000 ]
TPMD[1]: tpm/tpm_authorization.c:297: Debug: [TPM_ST_OIAP]
TPMD[1]: tpm/tpm_owner.c:152: Debug: [ srk->authDataUsage=01 ]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
TPMD[1]: tpm/tpm_eviction.c:56: Info: TPM_FlushSpecific()
TPMD[1]: tpm/tpm_eviction.c:57: Debug: [ handle=02000000 resourceType=00000002 ]
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[358]: 0 0 0 1 0 c5 0 0 1 62 0 0 0 0 1 1 0 0 0 11 0 0 0 0 1 0 0 0 1 0 3 0 1 0 0 0 c 0 0 8 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 1 0 d2 4b e1 86 58 23 b7 fb cc 1b b2 99 3 ea 69 fe 2d eb e1 3d 34 75 bb e4 19 bb 32 f3 45 69 e3 d6 ed 97 f9 31 5f da f9 1a f4 de 57 c2 9e 87 55 48 ca 74 e7 8e 81 a2 16 2f cc b4 d0 b4 4 54 f3 b7 10 52 ba cc 79 4b 9c fd d6 c 5f c5 24 74 1c e2 6b 25 6b 62 49 f7 3b 8a db 8f b8 37 d3 85 ae 39 80 90 6 b5 11 8f ed e0 1b c5 39 10 61 6b e9 37 f8 8d 4f 2f ac c2 3a b3 71 b6 8b c2 57 2 f0 68 d7 87 58 41 57 fb e2 d9 ff e5 7c 7d bc 8b b 23 99 cf 92 a4 f2 de 42 46 db b3 fb e5 f6 39 e8 4d 3c 74 eb b6 cc c6 89 85 89 9e c6 5b f3 87 60 ee 37 72 2f 8f 2f b5 db c4 67 cd 40 25 e0 7a 2e ca 3b eb 8a 21 d7 b7 99 cd 67 68 f8 d3 4f 6c 8 4a c8 6c 4b f9 1a 5a 11 66 58 78 b 4e d8 ba 5 2b ed 7d 50 8f 57 93 a2 93 6 d0 b1 7b 56 84 d1 8 ad f5 9a 25 3a ea 53 b3 7a 6a 2 fe 9a 48 fd ff 0 0 0 0 61 7e b8 9a 80 d7 c5 d8 e6 2b 93 15 c0 8a 63 c1 30 e e2 19 0 ae bc 71 95 b7 f0 4b 69 d7 22 f9 bc eb af a1 4e d9 60 8b 5a
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[18]: 0x0 0 0 1 0 c1 0 0 0 e 0 0 0 46 0 0 0 20
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3768: Debug: [TPM_ORD_GetRandom]
TPMD[1]: tpm/tpm_crypto.c:159: Info: TPM_GetRandom()
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[50]: 0 0 0 1 0 c4 0 0 0 2e 0 0 0 0 0 0 0 20 53 eb f4 a1 ce f1 80 37 91 6b 3b 97 8e 61 ab 41 5e 13 8 95 27 4c c7 13 ce 1d cd 1d 93 a9 2b 46
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[40]: 0x0 0 0 1 0 c1 0 0 0 24 0 0 0 b 0 1 40 0 0 0 e7 ab a8 73 1e e2 30 f7 24 fa bf e0 78 4b a8 60 5 21 5 5f
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3868: Debug: [TPM_ORD_OSAP]
TPMD[1]: tpm/tpm_authorization.c:200: Info: TPM_OSAP()
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[58]: 0 0 0 1 0 c4 0 0 0 36 0 0 0 0 2 0 0 0 f4 ae 95 8b d6 59 a7 ea 59 4d ee c6 44 52 3b 25 67 b9 bb 8a 1a 66 c9 ae c0 c ea f6 17 4e aa df dd fb ce 37 64 ab 3a d5
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[150]: 0x0 0 0 1 0 c2 0 0 0 92 0 0 0 1f 40 0 0 0 fe a5 5c d 54 62 79 dd 37 f7 bb f2 ae b1 dc a9 fe 67 6e d4 e5 32 c9 cb b7 56 46 ac 2e de 7 17 f8 e5 6d e4 cd f0 40 f4 1 1 0 0 0 11 0 0 0 4 1 0 0 0 1 0 3 0 1 0 0 0 c 0 0 8 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 7f 2b 99 59 a2 e6 1e 5f a8 58 1b 57 13 86 6e 7f f8 ea 7a fe 0 c0 1e da 1a c c8 9b a6 2 ad 27 62 1f e 7 9f 1e 5a 86 12
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3460: Debug: [TPM_TAG_RQU_AUTH1_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3643: Debug: [TPM_ORD_CreateWrapKey]
TPMD[1]: tpm/tpm_storage.c:414: Info: TPM_CreateWrapKey()
TPMD[1]: tpm/tpm_authorization.c:289: Info: tpm_verify_auth()
TPMD[1]: tpm/tpm_authorization.c:290: Debug: [ handle=02000000 ]
TPMD[1]: tpm/tpm_authorization.c:302: Debug: [TPM_ST_OSAP]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
TPMD[1]: tpm/tpm_eviction.c:56: Info: TPM_FlushSpecific()
TPMD[1]: tpm/tpm_eviction.c:57: Debug: [ handle=02000000 resourceType=00000002 ]
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[614]: 0 0 0 1 0 c5 0 0 2 62 0 0 0 0 1 1 0 0 0 11 0 0 0 4 1 0 0 0 1 0 3 0 1 0 0 0 c 0 0 8 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 1 0 cf 97 32 3 64 aa 64 77 95 74 f9 e1 b6 8e 42 34 c3 b8 b7 b2 7 d7 cf 46 13 c0 10 3f 9f b8 8d d 1c c1 62 b2 78 31 9d e0 22 ac fa b8 ce 25 11 9a 34 ba 1 5c c1 78 1f bb 74 a2 cc 88 97 1b 91 ea 7b 65 77 f4 dd 54 fa 2e 86 a7 d7 9a bd 67 40 54 7d a 78 a 1 e7 c1 e2 41 bd d 43 55 78 b1 d2 9b 42 64 1 54 ee f9 31 a9 c 9c 2d 8f 17 6f 63 a3 40 78 89 94 a6 b2 49 4d 53 5d b3 75 b8 bc d9 47 83 ef de a9 fd 78 de 59 7e d9 b ad d8 c9 46 18 3c e8 d8 16 20 1a fc 2d 66 de d2 7c cd d5 33 e ee 7f 3c 89 41 3c 8 63 a2 5b b9 86 86 fe 30 2 f 9b 92 c7 cf 70 cb 32 a8 87 62 a9 83 32 9f fa 83 ac f2 79 41 41 92 f4 f6 6c f8 c9 de 29 6e 2f b8 f6 2f 20 3a c1 4f 6 85 f 88 69 e1 4a 59 13 6d 1d 71 70 53 6b db 89 dc ea b 1c 49 bd c0 28 41 9b a2 2c f 37 cf 9a aa 3c b9 7c 82 27 75 0 0 1 0 37 87 8b 54 2f c1 20 64 57 f3 12 75 3a ed a9 58 65 78 1d b3 d9 a f4 4e 55 f5 39 5 a5 a1 b7 fe 26 7b eb 8f 12 69 ed 9c 55 2d ad e8 63 c2 1a 4f 0 2f 7e 1a f5 5 d0 2f b9 37 d2 4c 8a bc 68 41 fe af be 8e eb 92 22 87 df 4 35 e2 d2 8e 52 e3 a3 88 db f 85 4f b 31 8 fb 34 67 35 41 d2 59 b8 5b 5f 43 f3 e3 ad 13 3 9b 51 68 b6 91 85 ed 9d b3 6 61 1a 2f 81 22 49 d9 f3 ca 56 ef bd 17 ec e d0 82 49 9b f8 d8 dd 7a f8 7 ee 69 27 13 33 20 59 31 1a ec c6 55 56 aa 92 79 f7 97 d2 b0 b5 ec 13 6e ff ed 4d 73 df ce 48 98 ae 41 b9 12 7c 63 62 5e 82 3c 1 99 86 1c c5 6e a3 d1 c2 7 77 ca 73 83 c5 6b d3 81 1 17 78 e9 c6 29 99 4 e 45 a8 e4 c8 bc 48 e5 64 63 5b 68 97 3b 10 fc 34 4d 8e 5d 2 10 69 b2 39 f 8a 6 46 47 a8 bb 18 63 90 12 55 d2 59 69 9c 6c 36 ca 64 82 ed d c2 52 50 1 12 83 45 77 7 e7 88 95 4f 94 90 b9 cb 30 b9 66 0 60 80 4f 2c 3e ae 12 d9 c4 bc 4e 45 3a 7a c7 12 f4 bf 2a e3
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[14]: 0x0 0 0 1 0 c1 0 0 0 a 0 0 0 a
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3863: Debug: [TPM_ORD_OIAP]
TPMD[1]: tpm/tpm_authorization.c:182: Info: TPM_OIAP()
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[38]: 0 0 0 1 0 c4 0 0 0 22 0 0 0 0 2 0 0 0 1f a 4a 8d 7e bc 77 49 ba 12 ed aa 74 60 de 2a 8a 1c 9c fd
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[46]: 0x0 0 0 1 0 c1 0 0 0 2a 0 0 0 65 0 0 0 8 0 0 0 18 0 0 0 1 0 3 0 1 0 0 0 c 0 0 8 0 0 0 0 2 0 0 0 0
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:643: Debug: [TPM_CAP_CHECK_LOADED]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[19]: 0 0 0 1 0 c4 0 0 0 f 0 0 0 0 0 0 0 1 1
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[622]: 0x0 0 0 1 0 c2 0 0 2 6a 0 0 0 41 40 0 0 0 1 1 0 0 0 11 0 0 0 4 1 0 0 0 1 0 3 0 1 0 0 0 c 0 0 8 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 1 0 cf 97 32 3 64 aa 64 77 95 74 f9 e1 b6 8e 42 34 c3 b8 b7 b2 7 d7 cf 46 13 c0 10 3f 9f b8 8d d 1c c1 62 b2 78 31 9d e0 22 ac fa b8 ce 25 11 9a 34 ba 1 5c c1 78 1f bb 74 a2 cc 88 97 1b 91 ea 7b 65 77 f4 dd 54 fa 2e 86 a7 d7 9a bd 67 40 54 7d a 78 a 1 e7 c1 e2 41 bd d 43 55 78 b1 d2 9b 42 64 1 54 ee f9 31 a9 c 9c 2d 8f 17 6f 63 a3 40 78 89 94 a6 b2 49 4d 53 5d b3 75 b8 bc d9 47 83 ef de a9 fd 78 de 59 7e d9 b ad d8 c9 46 18 3c e8 d8 16 20 1a fc 2d 66 de d2 7c cd d5 33 e ee 7f 3c 89 41 3c 8 63 a2 5b b9 86 86 fe 30 2 f 9b 92 c7 cf 70 cb 32 a8 87 62 a9 83 32 9f fa 83 ac f2 79 41 41 92 f4 f6 6c f8 c9 de 29 6e 2f b8 f6 2f 20 3a c1 4f 6 85 f 88 69 e1 4a 59 13 6d 1d 71 70 53 6b db 89 dc ea b 1c 49 bd c0 28 41 9b a2 2c f 37 cf 9a aa 3c b9 7c 82 27 75 0 0 1 0 37 87 8b 54 2f c1 20 64 57 f3 12 75 3a ed a9 58 65 78 1d b3 d9 a f4 4e 55 f5 39 5 a5 a1 b7 fe 26 7b eb 8f 12 69 ed 9c 55 2d ad e8 63 c2 1a 4f 0 2f 7e 1a f5 5 d0 2f b9 37 d2 4c 8a bc 68 41 fe af be 8e eb 92 22 87 df 4 35 e2 d2 8e 52 e3 a3 88 db f 85 4f b 31 8 fb 34 67 35 41 d2 59 b8 5b 5f 43 f3 e3 ad 13 3 9b 51 68 b6 91 85 ed 9d b3 6 61 1a 2f 81 22 49 d9 f3 ca 56 ef bd 17 ec e d0 82 49 9b f8 d8 dd 7a f8 7 ee 69 27 13 33 20 59 31 1a ec c6 55 56 aa 92 79 f7 97 d2 b0 b5 ec 13 6e ff ed 4d 73 df ce 48 98 ae 41 b9 12 7c 63 62 5e 82 3c 1 99 86 1c c5 6e a3 d1 c2 7 77 ca 73 83 c5 6b d3 81 1 17 78 e9 c6 29 99 4 e 45 a8 e4 c8 bc 48 e5 64 63 5b 68 97 3b 10 fc 34 4d 8e 5d 2 10 69 b2 39 f 8a 6 46 47 a8 bb 18 63 90 12 55 d2 59 69 9c 6c 36 ca 64 82 ed d 2 0 0 0 12 f4 d0 71 e8 41 c1 2b 97 8b 5d f4 a2 97 12 76 59 60 aa b 0 46 ce d6 d2 5d a3 b4 cd 5b ea 93 69 d3 39 70 d 46 11 bb bb
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3460: Debug: [TPM_TAG_RQU_AUTH1_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3653: Debug: [TPM_ORD_LoadKey2]
TPMD[1]: tpm/tpm_storage.c:616: Info: TPM_LoadKey2() is currently emulated by TPM_LoadKey()
TPMD[1]: tpm/tpm_storage.c:526: Info: TPM_LoadKey()
TPMD[1]: tpm/tpm_storage.c:528: Debug: [ parentHandle=40000000 ]
TPMD[1]: tpm/tpm_storage.c:534: Debug: [ authDataUsage=01 ]
TPMD[1]: tpm/tpm_authorization.c:289: Info: tpm_verify_auth()
TPMD[1]: tpm/tpm_authorization.c:290: Debug: [ handle=02000000 ]
TPMD[1]: tpm/tpm_authorization.c:297: Debug: [TPM_ST_OIAP]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
TPMD[1]: tpm/tpm_eviction.c:56: Info: TPM_FlushSpecific()
TPMD[1]: tpm/tpm_eviction.c:57: Debug: [ handle=02000000 resourceType=00000002 ]
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[59]: 0 0 0 1 0 c5 0 0 0 37 0 0 0 0 1 0 0 0 39 96 7e 1e f 42 c 3b 67 fc de 85 5f 8a c be 1c c0 99 ff 0 7c 24 46 16 f7 fc 1b 14 cb bf 25 9a e0 db c5 7a 31 67 aa a3
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[22]: 0x0 0 0 1 0 c1 0 0 0 12 0 0 0 ba 1 0 0 0 0 0 0 1
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3958: Debug: [TPM_ORD_FlushSpecific]
TPMD[1]: tpm/tpm_eviction.c:56: Info: TPM_FlushSpecific()
TPMD[1]: tpm/tpm_eviction.c:57: Debug: [ handle=01000000 resourceType=00000001 ]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[14]: 0 0 0 1 0 c4 0 0 0 a 0 0 0 0
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[22]: 0x0 0 0 1 0 c1 0 0 0 12 0 0 0 65 0 0 0 1a 0 0 0 0
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:694: Debug: [TPM_CAP_VERSION_VAL]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[33]: 0 0 0 1 0 c4 0 0 0 1d 0 0 0 0 0 0 0 f 0 30 1 2 0 4 0 2 5e 0 0 0 0 0 0
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[22]: 0x0 0 0 1 0 c1 0 0 0 12 0 0 0 65 0 0 0 6 0 0 0 0
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:634: Debug: [TPM_CAP_VERSION]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[22]: 0 0 0 1 0 c4 0 0 0 12 0 0 0 0 0 0 0 4 1 1 0 0
INFO[VTPM]: [Backend Listener]: Forwarding command to DMI.
TPMD[1]: tpmd.c:183: Debug: Recv[26]: 0x0 0 0 1 0 c1 0 0 0 16 0 0 0 65 0 0 0 5 0 0 0 4 0 0 1 3
TPMD[1]: tpm/tpm_cmd_handler.c:4156: Debug: tpm_handle_command()
TPMD[1]: tpm/tpm_cmd_handler.c:3467: Debug: [TPM_TAG_RQU_COMMAND]
TPMD[1]: tpm/tpm_cmd_handler.c:3583: Debug: [TPM_ORD_GetCapability]
TPMD[1]: tpm/tpm_capability.c:610: Info: TPM_GetCapability() (not fully implemented yet)
TPMD[1]: tpm/tpm_capability.c:630: Debug: [TPM_CAP_PROPERTY]
TPMD[1]: tpm/tpm_capability.c:71: Debug: [TPM_CAP_PROP_MANUFACTURER]
TPMD[1]: tpm/tpm_cmd_handler.c:4111: Info: TPM command succeeded
INFO[VTPM]: [Backend Listener]: Sending DMI's response to guest.
INFO[VTPM]: [Backend Listener]: Backend Listener waiting for messages.
TPMD[1]: tpmd.c:227: Debug: Sent[22]: 0 0 0 1 0 c4 0 0 0 12 0 0 0 0 0 0 0 4 45 54 48 5a
[-- Attachment #3: tcsd.out --]
[-- Type: text/plain, Size: 211 bytes --]
tpm-test:~# tcsd -f
TCSD TDDL ioctl: (25) Inappropriate ioctl for device
TCSD TDDL Falling back to Read/Write device support.
TCSD trousers 0.3.1: TCSD up and running.
TCSD TCS Unloading a public key of size 0!
[-- Attachment #4: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-26 23:28 Infineon vtpm problem Erdem Bayer
@ 2008-02-27 3:59 ` Stefan Berger
2008-02-27 21:02 ` Erdem Bayer
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Berger @ 2008-02-27 3:59 UTC (permalink / raw)
To: Erdem Bayer; +Cc: xen-devel, xense-devel
[-- Attachment #1.1: Type: text/plain, Size: 3392 bytes --]
xense-devel-bounces@lists.xensource.com wrote on 02/26/2008 06:28:01 PM:
> Hi
>
> I have successfully applied the patch mentioned here
>
(http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html)
> to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
>
> I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
>
> After reboot, vtpm_managerd runs ok. (output is attched to the mail.)
>
> I created a pv vm with the option vtpm = ['instance=1, backend=0'] The
> vm boots fine.
>
> I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on the vm.
>
> I run tcsd -f on the vm. (output is attched to the mail.)
>
> I checkout and run the trousers test suite. 10 tests passed with 230
> failed. (Is this expected?)
It is likely that this (v)TPM implementation has quite a few bugs, but I
would not expect that many errors.
>
> When I try tpm_takeownership on the vm, the command runs fine. (Although
> a strange warning appers on tcsd output which is attched).
This error may be related to older versions of the TPM device driver
having used an ioctl interface for sending/receiving commands to/from the
TPM and the TSS still tries this interface first. This should not be a
reason for the errors you are seeing.
>
> But when I try tpm_sealdata < foo on the vm I get the following error.
>
> Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> Authorization failed
>
> But other tpm_version runs fine on vm.
>
> tpm-test:~# tpm_version
> TPM 1.2 Version Info:
> Chip Version: 1.2.0.4
> Spec Level: 2
> Errata Revision: 94
> TPM Vendor ID:
> TPM Version: 01010000
> Manufacturer Info: 4554485a
>
> Also this quote is from Xen User's Guide:
>
> "Similarly, the TPM frontend driver must be compiled for the kernel
> trying to use TPM functionality. Its driver can be selected in the
> kernel configuration section Device Driver / Character Devices / TPM
> Devices. Along with that the TPM driver for the built-in TPM must be
> selected."
>
> According to my understanding driver for the built-in TPM must be
> selected on the kernel where TPM frontend driver is used. Am I correct
> about this assumption? (The problem is tpm_infineon driver can not be
The driver for the built-in Infineon TPM must be built into Domain-0, the
TPM frontend driver in the guest domain and the backend driver also into
Domain-0. This has probably been done correctly since otherwise the vTPM
would not work at all.
> selected on an unpriviledged kernel, it can only be selected on a
> priviledged kernel)
>
> Am I missing something here? Why do I get auth errors?
Did you try to run the same sequence of comands (tpm commands, test suite
etc.) on a plain Linux kernel with the TSS stack against the built-in
Infineone TPM? From what I remember, the test suite for the TSS stack
either tries to set a specific TPM owner password or it must previously
have been set to it by the user, otherwise many authentication errors will
occur.
Stefan
>
> Thanks in advance.
>
> Erdem Bayer
> [attachment "vtpm_managerd.out" deleted by Stefan Berger/Watson/IBM]
> [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@lists.xensource.com
> http://lists.xensource.com/xense-devel
[-- Attachment #1.2: Type: text/html, Size: 4359 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-27 3:59 ` [Xense-devel] " Stefan Berger
@ 2008-02-27 21:02 ` Erdem Bayer
2008-02-28 2:47 ` Stefan Berger
0 siblings, 1 reply; 10+ messages in thread
From: Erdem Bayer @ 2008-02-27 21:02 UTC (permalink / raw)
Cc: xen-devel, xense-devel
Hi
I have checked out the 0.3.2cvs version of trousers and finally get the
tsstest working with very few differences from when it is run under
non-xen host. My previous attempts was on 0.3.1 (stable).
However when run tpm_sealdata, I still get
Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
Authorization failed.
This reminds me that maybe I am using vtpm wrong way. Is there a
document about how to use vtpm?
Here is what I do from sratch:
1. Clear and reactivate TPM from bios.
2. Run vtpm_managerd in dom0 and let it continue running on console.
3. Boot domU with vif statement in config file.
4. Run tcsd -f on domU and let it continue running on console.
From now on every tpm operation I run on domU returns an error.
Operations tried on domU
1. I tried tpm_takeownership with success (although I see an error on
tcsd -f output, I assume it is normal because I see exact same error
when I run takeownership from non-xen host and actually prove ownership
taken by using sealdata successfully) but when I try tpm_sealdata I get
above error.
2. After starting from scratch, I tried tpm_sealdata without first try
to take ownership. This time there is a different output:
Enter SRK password:
Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003 (3), Bad
Parameter
I think I am not able to use vtpm because probably I am not doing the
right sequence of actions on domU. So if there is a document about vtpm
usage, please point me to it.
And here is another question:
I never run tpm_takeownership on dom0. Whenever I start from scratch I
let the vtpm_managerd to take ownership of tpm. However, I do not know
the owner or srk password it uses. When I use vtpm on domU and asked for
the srk pasword, which password should I enter? Also, should I take
ownership of vtpm on domU every time I booted it? How do I save state of
the vtpm for a domain across boots?
Thanks for time.
Erdem Bayer
Stefan Berger wrote On 27-02-2008 05:59:
>
> xense-devel-bounces@lists.xensource.com wrote on 02/26/2008 06:28:01 PM:
>
> > Hi
> >
> > I have successfully applied the patch mentioned here
> >
> (http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html)
>
> > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> >
> > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> >
> > After reboot, vtpm_managerd runs ok. (output is attched to the mail.)
> >
> > I created a pv vm with the option vtpm = ['instance=1, backend=0'] The
> > vm boots fine.
> >
> > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on the vm.
> >
> > I run tcsd -f on the vm. (output is attched to the mail.)
> >
> > I checkout and run the trousers test suite. 10 tests passed with 230
> > failed. (Is this expected?)
>
>
> It is likely that this (v)TPM implementation has quite a few bugs, but
> I would not expect that many errors.
>
> >
> > When I try tpm_takeownership on the vm, the command runs fine.
> (Although
> > a strange warning appers on tcsd output which is attched).
>
> This error may be related to older versions of the TPM device driver
> having used an ioctl interface for sending/receiving commands to/from
> the TPM and the TSS still tries this interface first. This should not
> be a reason for the errors you are seeing.
>
> >
> > But when I try tpm_sealdata < foo on the vm I get the following error.
> >
> > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > Authorization failed
> >
> > But other tpm_version runs fine on vm.
> >
> > tpm-test:~# tpm_version
> > TPM 1.2 Version Info:
> > Chip Version: 1.2.0.4
> > Spec Level: 2
> > Errata Revision: 94
> > TPM Vendor ID:
> > TPM Version: 01010000
> > Manufacturer Info: 4554485a
> >
> > Also this quote is from Xen User's Guide:
> >
> > "Similarly, the TPM frontend driver must be compiled for the kernel
> > trying to use TPM functionality. Its driver can be selected in the
> > kernel configuration section Device Driver / Character Devices / TPM
> > Devices. Along with that the TPM driver for the built-in TPM must be
> > selected."
> >
> > According to my understanding driver for the built-in TPM must be
> > selected on the kernel where TPM frontend driver is used. Am I correct
> > about this assumption? (The problem is tpm_infineon driver can not be
>
> The driver for the built-in Infineon TPM must be built into Domain-0,
> the TPM frontend driver in the guest domain and the backend driver
> also into Domain-0. This has probably been done correctly since
> otherwise the vTPM would not work at all.
>
>
> > selected on an unpriviledged kernel, it can only be selected on a
> > priviledged kernel)
> >
> > Am I missing something here? Why do I get auth errors?
>
>
> Did you try to run the same sequence of comands (tpm commands, test
> suite etc.) on a plain Linux kernel with the TSS stack against the
> built-in Infineone TPM? From what I remember, the test suite for the
> TSS stack either tries to set a specific TPM owner password or it must
> previously have been set to it by the user, otherwise many
> authentication errors will occur.
>
> Stefan
>
> >
> > Thanks in advance.
> >
> > Erdem Bayer
> > [attachment "vtpm_managerd.out" deleted by Stefan Berger/Watson/IBM]
> > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > _______________________________________________
> > Xense-devel mailing list
> > Xense-devel@lists.xensource.com
> > http://lists.xensource.com/xense-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-27 21:02 ` Erdem Bayer
@ 2008-02-28 2:47 ` Stefan Berger
2008-02-28 8:42 ` Erdem Bayer
2008-02-28 12:28 ` Erdem Bayer
0 siblings, 2 replies; 10+ messages in thread
From: Stefan Berger @ 2008-02-28 2:47 UTC (permalink / raw)
To: Erdem Bayer; +Cc: xen-devel, xense-devel
[-- Attachment #1.1: Type: text/plain, Size: 6601 bytes --]
xense-devel-bounces@lists.xensource.com wrote on 02/27/2008 04:02:41 PM:
> Hi
>
> I have checked out the 0.3.2cvs version of trousers and finally get the
> tsstest working with very few differences from when it is run under
> non-xen host. My previous attempts was on 0.3.1 (stable).
>
> However when run tpm_sealdata, I still get
>
> Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> Authorization failed.
So, I just tried this and I ran into the same problem. I then used some
tools that let me control whether to use TPM_LoadKey() or TPM_LoadKey2().
Loading a key with TPM_LoadKey2() failed due to HMAC authorization
failing, TPM_LoadKey() worked. From what I saw is that the TSS is using
TPM_LoadKey2() and the TPM implementation then states that TPM_LoadKey2()
is emulated using TPM_LoadKey(). Well, it seems to be a bug in the
TPM_LoadKey2() implementation.
>
> This reminds me that maybe I am using vtpm wrong way. Is there a
> document about how to use vtpm?
>
No, you are using it correctly.
Stefan
> Here is what I do from sratch:
>
> 1. Clear and reactivate TPM from bios.
> 2. Run vtpm_managerd in dom0 and let it continue running on console.
> 3. Boot domU with vif statement in config file.
> 4. Run tcsd -f on domU and let it continue running on console.
>
> From now on every tpm operation I run on domU returns an error.
>
> Operations tried on domU
>
> 1. I tried tpm_takeownership with success (although I see an error on
> tcsd -f output, I assume it is normal because I see exact same error
> when I run takeownership from non-xen host and actually prove ownership
> taken by using sealdata successfully) but when I try tpm_sealdata I get
> above error.
>
> 2. After starting from scratch, I tried tpm_sealdata without first try
> to take ownership. This time there is a different output:
>
> Enter SRK password:
> Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003 (3), Bad
> Parameter
>
> I think I am not able to use vtpm because probably I am not doing the
> right sequence of actions on domU. So if there is a document about vtpm
> usage, please point me to it.
>
> And here is another question:
>
> I never run tpm_takeownership on dom0. Whenever I start from scratch I
> let the vtpm_managerd to take ownership of tpm. However, I do not know
> the owner or srk password it uses. When I use vtpm on domU and asked for
> the srk pasword, which password should I enter? Also, should I take
> ownership of vtpm on domU every time I booted it? How do I save state of
> the vtpm for a domain across boots?
>
> Thanks for time.
> Erdem Bayer
>
>
> Stefan Berger wrote On 27-02-2008 05:59:
> >
> > xense-devel-bounces@lists.xensource.com wrote on 02/26/2008 06:28:01
PM:
> >
> > > Hi
> > >
> > > I have successfully applied the patch mentioned here
> > >
> >
(http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html
> )
> >
> > > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> > >
> > > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> > >
> > > After reboot, vtpm_managerd runs ok. (output is attched to the
mail.)
> > >
> > > I created a pv vm with the option vtpm = ['instance=1, backend=0']
The
> > > vm boots fine.
> > >
> > > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on the
vm.
> > >
> > > I run tcsd -f on the vm. (output is attched to the mail.)
> > >
> > > I checkout and run the trousers test suite. 10 tests passed with 230
> > > failed. (Is this expected?)
> >
> >
> > It is likely that this (v)TPM implementation has quite a few bugs, but
> > I would not expect that many errors.
> >
> > >
> > > When I try tpm_takeownership on the vm, the command runs fine.
> > (Although
> > > a strange warning appers on tcsd output which is attched).
> >
> > This error may be related to older versions of the TPM device driver
> > having used an ioctl interface for sending/receiving commands to/from
> > the TPM and the TSS still tries this interface first. This should not
> > be a reason for the errors you are seeing.
> >
> > >
> > > But when I try tpm_sealdata < foo on the vm I get the following
error.
> > >
> > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > > Authorization failed
> > >
> > > But other tpm_version runs fine on vm.
> > >
> > > tpm-test:~# tpm_version
> > > TPM 1.2 Version Info:
> > > Chip Version: 1.2.0.4
> > > Spec Level: 2
> > > Errata Revision: 94
> > > TPM Vendor ID:
> > > TPM Version: 01010000
> > > Manufacturer Info: 4554485a
> > >
> > > Also this quote is from Xen User's Guide:
> > >
> > > "Similarly, the TPM frontend driver must be compiled for the kernel
> > > trying to use TPM functionality. Its driver can be selected in the
> > > kernel configuration section Device Driver / Character Devices / TPM
> > > Devices. Along with that the TPM driver for the built-in TPM must be
> > > selected."
> > >
> > > According to my understanding driver for the built-in TPM must be
> > > selected on the kernel where TPM frontend driver is used. Am I
correct
> > > about this assumption? (The problem is tpm_infineon driver can not
be
> >
> > The driver for the built-in Infineon TPM must be built into Domain-0,
> > the TPM frontend driver in the guest domain and the backend driver
> > also into Domain-0. This has probably been done correctly since
> > otherwise the vTPM would not work at all.
> >
> >
> > > selected on an unpriviledged kernel, it can only be selected on a
> > > priviledged kernel)
> > >
> > > Am I missing something here? Why do I get auth errors?
> >
> >
> > Did you try to run the same sequence of comands (tpm commands, test
> > suite etc.) on a plain Linux kernel with the TSS stack against the
> > built-in Infineone TPM? From what I remember, the test suite for the
> > TSS stack either tries to set a specific TPM owner password or it must
> > previously have been set to it by the user, otherwise many
> > authentication errors will occur.
> >
> > Stefan
> >
> > >
> > > Thanks in advance.
> > >
> > > Erdem Bayer
> > > [attachment "vtpm_managerd.out" deleted by Stefan Berger/Watson/IBM]
> > > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > > _______________________________________________
> > > Xense-devel mailing list
> > > Xense-devel@lists.xensource.com
> > > http://lists.xensource.com/xense-devel
>
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@lists.xensource.com
> http://lists.xensource.com/xense-devel
[-- Attachment #1.2: Type: text/html, Size: 8625 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-28 2:47 ` Stefan Berger
@ 2008-02-28 8:42 ` Erdem Bayer
2008-02-28 20:02 ` Stefan Berger
2008-02-28 12:28 ` Erdem Bayer
1 sibling, 1 reply; 10+ messages in thread
From: Erdem Bayer @ 2008-02-28 8:42 UTC (permalink / raw)
To: Stefan Berger; +Cc: xen-devel, xense-devel
Hi
I have looked through some source code and have the following questions:
1)
in tools/vtpm/vtpm/tpm/tpm_storage.c
TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE parentHandle, TPM_KEY *inKey,
TPM_AUTH *auth1, TPM_KEY_HANDLE *inkeyHandle)
{
info("TPM_LoadKey2() is currently emulated by TPM_LoadKey()");
return TPM_LoadKey(parentHandle, inKey, auth1, inkeyHandle);
}
So TPM_LoadKey2 is actually a wrapper around TPM_LoadKey() with exactly
same parameters. My question is if they are using same parameters why
one fails while the other succeeds?
And why is it necessary to wrap the TPM_LoadKey function with exactly
same call? Any pointers would be highly appreciated.
2)
in tools/vtpm/vtpm/tpm/tpm_commands.h
* Description: ([TPM_Part3], Section 10.5)
What is this TPM_Part3 document mentioned here and where can I locate
it? Is this the document named "TPM Main Part3 IBM Commands" written by
Ken Goldman and you? If that is correct, I have Revision 10 of this
document dated 25 April 2005 and that document does not have Section
10.5. Is there a more recent version that I am not aware of?
3) Is this problem specific to TPM hardware (ie only infinion tpm) or
xen version?
4) You said you used some tools to trace and alter tss behaviour. What
is this tool and how can I obtain it?
Thanks for your time
Erdem Bayer
Stefan Berger wrote On 28-02-2008 04:47:
>
> xense-devel-bounces@lists.xensource.com wrote on 02/27/2008 04:02:41 PM:
>
> > Hi
> >
> > I have checked out the 0.3.2cvs version of trousers and finally get the
> > tsstest working with very few differences from when it is run under
> > non-xen host. My previous attempts was on 0.3.1 (stable).
> >
> > However when run tpm_sealdata, I still get
> >
> > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > Authorization failed.
>
> So, I just tried this and I ran into the same problem. I then used
> some tools that let me control whether to use TPM_LoadKey() or
> TPM_LoadKey2(). Loading a key with TPM_LoadKey2() failed due to HMAC
> authorization failing, TPM_LoadKey() worked. From what I saw is that
> the TSS is using TPM_LoadKey2() and the TPM implementation then states
> that TPM_LoadKey2() is emulated using TPM_LoadKey(). Well, it seems to
> be a bug in the TPM_LoadKey2() implementation.
>
> >
> > This reminds me that maybe I am using vtpm wrong way. Is there a
> > document about how to use vtpm?
> >
> No, you are using it correctly.
>
> Stefan
>
>
>
> > Here is what I do from sratch:
> >
> > 1. Clear and reactivate TPM from bios.
> > 2. Run vtpm_managerd in dom0 and let it continue running on console.
> > 3. Boot domU with vif statement in config file.
> > 4. Run tcsd -f on domU and let it continue running on console.
> >
> > From now on every tpm operation I run on domU returns an error.
> >
> > Operations tried on domU
> >
> > 1. I tried tpm_takeownership with success (although I see an error on
> > tcsd -f output, I assume it is normal because I see exact same error
> > when I run takeownership from non-xen host and actually prove ownership
> > taken by using sealdata successfully) but when I try tpm_sealdata I get
> > above error.
> >
> > 2. After starting from scratch, I tried tpm_sealdata without first try
> > to take ownership. This time there is a different output:
> >
> > Enter SRK password:
> > Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003 (3), Bad
> > Parameter
> >
> > I think I am not able to use vtpm because probably I am not doing the
> > right sequence of actions on domU. So if there is a document about vtpm
> > usage, please point me to it.
> >
> > And here is another question:
> >
> > I never run tpm_takeownership on dom0. Whenever I start from scratch I
> > let the vtpm_managerd to take ownership of tpm. However, I do not know
> > the owner or srk password it uses. When I use vtpm on domU and asked
> for
> > the srk pasword, which password should I enter? Also, should I take
> > ownership of vtpm on domU every time I booted it? How do I save
> state of
> > the vtpm for a domain across boots?
> >
> > Thanks for time.
> > Erdem Bayer
> >
> >
> > Stefan Berger wrote On 27-02-2008 05:59:
> > >
> > > xense-devel-bounces@lists.xensource.com wrote on 02/26/2008
> 06:28:01 PM:
> > >
> > > > Hi
> > > >
> > > > I have successfully applied the patch mentioned here
> > > >
> > >
> (http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html
> > )
> > >
> > > > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> > > >
> > > > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> > > >
> > > > After reboot, vtpm_managerd runs ok. (output is attched to the
> mail.)
> > > >
> > > > I created a pv vm with the option vtpm = ['instance=1,
> backend=0'] The
> > > > vm boots fine.
> > > >
> > > > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on
> the vm.
> > > >
> > > > I run tcsd -f on the vm. (output is attched to the mail.)
> > > >
> > > > I checkout and run the trousers test suite. 10 tests passed with 230
> > > > failed. (Is this expected?)
> > >
> > >
> > > It is likely that this (v)TPM implementation has quite a few bugs,
> but
> > > I would not expect that many errors.
> > >
> > > >
> > > > When I try tpm_takeownership on the vm, the command runs fine.
> > > (Although
> > > > a strange warning appers on tcsd output which is attched).
> > >
> > > This error may be related to older versions of the TPM device driver
> > > having used an ioctl interface for sending/receiving commands to/from
> > > the TPM and the TSS still tries this interface first. This should not
> > > be a reason for the errors you are seeing.
> > >
> > > >
> > > > But when I try tpm_sealdata < foo on the vm I get the following
> error.
> > > >
> > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > > > Authorization failed
> > > >
> > > > But other tpm_version runs fine on vm.
> > > >
> > > > tpm-test:~# tpm_version
> > > > TPM 1.2 Version Info:
> > > > Chip Version: 1.2.0.4
> > > > Spec Level: 2
> > > > Errata Revision: 94
> > > > TPM Vendor ID:
> > > > TPM Version: 01010000
> > > > Manufacturer Info: 4554485a
> > > >
> > > > Also this quote is from Xen User's Guide:
> > > >
> > > > "Similarly, the TPM frontend driver must be compiled for the kernel
> > > > trying to use TPM functionality. Its driver can be selected in the
> > > > kernel configuration section Device Driver / Character Devices / TPM
> > > > Devices. Along with that the TPM driver for the built-in TPM must be
> > > > selected."
> > > >
> > > > According to my understanding driver for the built-in TPM must be
> > > > selected on the kernel where TPM frontend driver is used. Am I
> correct
> > > > about this assumption? (The problem is tpm_infineon driver can
> not be
> > >
> > > The driver for the built-in Infineon TPM must be built into Domain-0,
> > > the TPM frontend driver in the guest domain and the backend driver
> > > also into Domain-0. This has probably been done correctly since
> > > otherwise the vTPM would not work at all.
> > >
> > >
> > > > selected on an unpriviledged kernel, it can only be selected on a
> > > > priviledged kernel)
> > > >
> > > > Am I missing something here? Why do I get auth errors?
> > >
> > >
> > > Did you try to run the same sequence of comands (tpm commands, test
> > > suite etc.) on a plain Linux kernel with the TSS stack against the
> > > built-in Infineone TPM? From what I remember, the test suite for the
> > > TSS stack either tries to set a specific TPM owner password or it
> must
> > > previously have been set to it by the user, otherwise many
> > > authentication errors will occur.
> > >
> > > Stefan
> > >
> > > >
> > > > Thanks in advance.
> > > >
> > > > Erdem Bayer
> > > > [attachment "vtpm_managerd.out" deleted by Stefan Berger/Watson/IBM]
> > > > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > > > _______________________________________________
> > > > Xense-devel mailing list
> > > > Xense-devel@lists.xensource.com
> > > > http://lists.xensource.com/xense-devel
> >
> > _______________________________________________
> > Xense-devel mailing list
> > Xense-devel@lists.xensource.com
> > http://lists.xensource.com/xense-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-28 2:47 ` Stefan Berger
2008-02-28 8:42 ` Erdem Bayer
@ 2008-02-28 12:28 ` Erdem Bayer
2008-02-28 19:55 ` Stefan Berger
1 sibling, 1 reply; 10+ messages in thread
From: Erdem Bayer @ 2008-02-28 12:28 UTC (permalink / raw)
To: Stefan Berger; +Cc: xen-devel, xense-devel
Hi
I have searched a little deeper and find out that tpm_emulator used in
vtpm implementation is a little outdated. I have searched the recent
changes from tpm-emulator and the last significant diff involving
TPM_LoadKey() was the below one.
I want to know if applying this diff will inprove my situation.
Thanks in advance
Erdem Bayer
ebayer@erdem-d tpm $ svn diff -r 201:179 tpm_storage.c
Index: tpm_storage.c
===================================================================
--- tpm_storage.c (revision 201)
+++ tpm_storage.c (revision 179)
@@ -521,13 +521,15 @@
parent = tpm_get_key(parentHandle);
if (parent == NULL) return TPM_INVALID_KEYHANDLE;
/* verify authorization */
- if (auth1->authHandle != TPM_INVALID_HANDLE) {
- debug("[ authDataUsage=%.2x ]", parent->authDataUsage);
- res = tpm_verify_auth(auth1, parent->usageAuth, parentHandle);
- if (res != TPM_SUCCESS) return res;
- } else if (parent->authDataUsage != TPM_AUTH_NEVER) {
- debug("TPM_LoadKey(): parent key requires authorization.");
- return TPM_AUTHFAIL;
+ if (parent->authDataUsage != TPM_AUTH_NEVER) {
+ if (auth1->authHandle != TPM_INVALID_HANDLE) {
+ debug("[ authDataUsage=%.2x ]", parent->authDataUsage);
+ res = tpm_verify_auth(auth1, parent->usageAuth, parentHandle);
+ if (res != TPM_SUCCESS) return res;
+ } else {
+ debug("TPM_LoadKey(): parent key requires authorization.");
+ return TPM_AUTHFAIL;
+ }
}
if (parent->keyUsage != TPM_KEY_STORAGE) return TPM_INVALID_KEYUSAGE;
/* verify key properties */
Stefan Berger wrote On 28-02-2008 04:47:
>
> xense-devel-bounces@lists.xensource.com wrote on 02/27/2008 04:02:41 PM:
>
> > Hi
> >
> > I have checked out the 0.3.2cvs version of trousers and finally get the
> > tsstest working with very few differences from when it is run under
> > non-xen host. My previous attempts was on 0.3.1 (stable).
> >
> > However when run tpm_sealdata, I still get
> >
> > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > Authorization failed.
>
> So, I just tried this and I ran into the same problem. I then used
> some tools that let me control whether to use TPM_LoadKey() or
> TPM_LoadKey2(). Loading a key with TPM_LoadKey2() failed due to HMAC
> authorization failing, TPM_LoadKey() worked. From what I saw is that
> the TSS is using TPM_LoadKey2() and the TPM implementation then states
> that TPM_LoadKey2() is emulated using TPM_LoadKey(). Well, it seems to
> be a bug in the TPM_LoadKey2() implementation.
>
> >
> > This reminds me that maybe I am using vtpm wrong way. Is there a
> > document about how to use vtpm?
> >
> No, you are using it correctly.
>
> Stefan
>
>
>
> > Here is what I do from sratch:
> >
> > 1. Clear and reactivate TPM from bios.
> > 2. Run vtpm_managerd in dom0 and let it continue running on console.
> > 3. Boot domU with vif statement in config file.
> > 4. Run tcsd -f on domU and let it continue running on console.
> >
> > From now on every tpm operation I run on domU returns an error.
> >
> > Operations tried on domU
> >
> > 1. I tried tpm_takeownership with success (although I see an error on
> > tcsd -f output, I assume it is normal because I see exact same error
> > when I run takeownership from non-xen host and actually prove ownership
> > taken by using sealdata successfully) but when I try tpm_sealdata I get
> > above error.
> >
> > 2. After starting from scratch, I tried tpm_sealdata without first try
> > to take ownership. This time there is a different output:
> >
> > Enter SRK password:
> > Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003 (3), Bad
> > Parameter
> >
> > I think I am not able to use vtpm because probably I am not doing the
> > right sequence of actions on domU. So if there is a document about vtpm
> > usage, please point me to it.
> >
> > And here is another question:
> >
> > I never run tpm_takeownership on dom0. Whenever I start from scratch I
> > let the vtpm_managerd to take ownership of tpm. However, I do not know
> > the owner or srk password it uses. When I use vtpm on domU and asked
> for
> > the srk pasword, which password should I enter? Also, should I take
> > ownership of vtpm on domU every time I booted it? How do I save
> state of
> > the vtpm for a domain across boots?
> >
> > Thanks for time.
> > Erdem Bayer
> >
> >
> > Stefan Berger wrote On 27-02-2008 05:59:
> > >
> > > xense-devel-bounces@lists.xensource.com wrote on 02/26/2008
> 06:28:01 PM:
> > >
> > > > Hi
> > > >
> > > > I have successfully applied the patch mentioned here
> > > >
> > >
> (http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html
> > )
> > >
> > > > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> > > >
> > > > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> > > >
> > > > After reboot, vtpm_managerd runs ok. (output is attched to the
> mail.)
> > > >
> > > > I created a pv vm with the option vtpm = ['instance=1,
> backend=0'] The
> > > > vm boots fine.
> > > >
> > > > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on
> the vm.
> > > >
> > > > I run tcsd -f on the vm. (output is attched to the mail.)
> > > >
> > > > I checkout and run the trousers test suite. 10 tests passed with 230
> > > > failed. (Is this expected?)
> > >
> > >
> > > It is likely that this (v)TPM implementation has quite a few bugs,
> but
> > > I would not expect that many errors.
> > >
> > > >
> > > > When I try tpm_takeownership on the vm, the command runs fine.
> > > (Although
> > > > a strange warning appers on tcsd output which is attched).
> > >
> > > This error may be related to older versions of the TPM device driver
> > > having used an ioctl interface for sending/receiving commands to/from
> > > the TPM and the TSS still tries this interface first. This should not
> > > be a reason for the errors you are seeing.
> > >
> > > >
> > > > But when I try tpm_sealdata < foo on the vm I get the following
> error.
> > > >
> > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > > > Authorization failed
> > > >
> > > > But other tpm_version runs fine on vm.
> > > >
> > > > tpm-test:~# tpm_version
> > > > TPM 1.2 Version Info:
> > > > Chip Version: 1.2.0.4
> > > > Spec Level: 2
> > > > Errata Revision: 94
> > > > TPM Vendor ID:
> > > > TPM Version: 01010000
> > > > Manufacturer Info: 4554485a
> > > >
> > > > Also this quote is from Xen User's Guide:
> > > >
> > > > "Similarly, the TPM frontend driver must be compiled for the kernel
> > > > trying to use TPM functionality. Its driver can be selected in the
> > > > kernel configuration section Device Driver / Character Devices / TPM
> > > > Devices. Along with that the TPM driver for the built-in TPM must be
> > > > selected."
> > > >
> > > > According to my understanding driver for the built-in TPM must be
> > > > selected on the kernel where TPM frontend driver is used. Am I
> correct
> > > > about this assumption? (The problem is tpm_infineon driver can
> not be
> > >
> > > The driver for the built-in Infineon TPM must be built into Domain-0,
> > > the TPM frontend driver in the guest domain and the backend driver
> > > also into Domain-0. This has probably been done correctly since
> > > otherwise the vTPM would not work at all.
> > >
> > >
> > > > selected on an unpriviledged kernel, it can only be selected on a
> > > > priviledged kernel)
> > > >
> > > > Am I missing something here? Why do I get auth errors?
> > >
> > >
> > > Did you try to run the same sequence of comands (tpm commands, test
> > > suite etc.) on a plain Linux kernel with the TSS stack against the
> > > built-in Infineone TPM? From what I remember, the test suite for the
> > > TSS stack either tries to set a specific TPM owner password or it
> must
> > > previously have been set to it by the user, otherwise many
> > > authentication errors will occur.
> > >
> > > Stefan
> > >
> > > >
> > > > Thanks in advance.
> > > >
> > > > Erdem Bayer
> > > > [attachment "vtpm_managerd.out" deleted by Stefan Berger/Watson/IBM]
> > > > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > > > _______________________________________________
> > > > Xense-devel mailing list
> > > > Xense-devel@lists.xensource.com
> > > > http://lists.xensource.com/xense-devel
> >
> > _______________________________________________
> > Xense-devel mailing list
> > Xense-devel@lists.xensource.com
> > http://lists.xensource.com/xense-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-28 12:28 ` Erdem Bayer
@ 2008-02-28 19:55 ` Stefan Berger
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Berger @ 2008-02-28 19:55 UTC (permalink / raw)
To: Erdem Bayer; +Cc: xen-devel, xense-devel
[-- Attachment #1.1: Type: text/plain, Size: 9243 bytes --]
Erdem Bayer <ebayer@bayer.gen.tr> wrote on 02/28/2008 07:28:14 AM:
> Hi
>
> I have searched a little deeper and find out that tpm_emulator used in
> vtpm implementation is a little outdated. I have searched the recent
> changes from tpm-emulator and the last significant diff involving
> TPM_LoadKey() was the below one.
>
> I want to know if applying this diff will inprove my situation.
This is already part of the tpm emulator version 0.4 that is automatically
downloaded by the Xen build process.
Stefan
>
> Thanks in advance
> Erdem Bayer
>
> ebayer@erdem-d tpm $ svn diff -r 201:179 tpm_storage.c
> Index: tpm_storage.c
> ===================================================================
> --- tpm_storage.c (revision 201)
> +++ tpm_storage.c (revision 179)
> @@ -521,13 +521,15 @@
> parent = tpm_get_key(parentHandle);
> if (parent == NULL) return TPM_INVALID_KEYHANDLE;
> /* verify authorization */
> - if (auth1->authHandle != TPM_INVALID_HANDLE) {
> - debug("[ authDataUsage=%.2x ]", parent->authDataUsage);
> - res = tpm_verify_auth(auth1, parent->usageAuth, parentHandle);
> - if (res != TPM_SUCCESS) return res;
> - } else if (parent->authDataUsage != TPM_AUTH_NEVER) {
> - debug("TPM_LoadKey(): parent key requires authorization.");
> - return TPM_AUTHFAIL;
> + if (parent->authDataUsage != TPM_AUTH_NEVER) {
> + if (auth1->authHandle != TPM_INVALID_HANDLE) {
> + debug("[ authDataUsage=%.2x ]", parent->authDataUsage);
> + res = tpm_verify_auth(auth1, parent->usageAuth, parentHandle);
> + if (res != TPM_SUCCESS) return res;
> + } else {
> + debug("TPM_LoadKey(): parent key requires authorization.");
> + return TPM_AUTHFAIL;
> + }
> }
> if (parent->keyUsage != TPM_KEY_STORAGE) return TPM_INVALID_KEYUSAGE;
> /* verify key properties */
>
>
> Stefan Berger wrote On 28-02-2008 04:47:
> >
> > xense-devel-bounces@lists.xensource.com wrote on 02/27/2008 04:02:41
PM:
> >
> > > Hi
> > >
> > > I have checked out the 0.3.2cvs version of trousers and finally get
the
> > > tsstest working with very few differences from when it is run under
> > > non-xen host. My previous attempts was on 0.3.1 (stable).
> > >
> > > However when run tpm_sealdata, I still get
> > >
> > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > > Authorization failed.
> >
> > So, I just tried this and I ran into the same problem. I then used
> > some tools that let me control whether to use TPM_LoadKey() or
> > TPM_LoadKey2(). Loading a key with TPM_LoadKey2() failed due to HMAC
> > authorization failing, TPM_LoadKey() worked. From what I saw is that
> > the TSS is using TPM_LoadKey2() and the TPM implementation then states
> > that TPM_LoadKey2() is emulated using TPM_LoadKey(). Well, it seems to
> > be a bug in the TPM_LoadKey2() implementation.
> >
> > >
> > > This reminds me that maybe I am using vtpm wrong way. Is there a
> > > document about how to use vtpm?
> > >
> > No, you are using it correctly.
> >
> > Stefan
> >
> >
> >
> > > Here is what I do from sratch:
> > >
> > > 1. Clear and reactivate TPM from bios.
> > > 2. Run vtpm_managerd in dom0 and let it continue running on console.
> > > 3. Boot domU with vif statement in config file.
> > > 4. Run tcsd -f on domU and let it continue running on console.
> > >
> > > From now on every tpm operation I run on domU returns an error.
> > >
> > > Operations tried on domU
> > >
> > > 1. I tried tpm_takeownership with success (although I see an error
on
> > > tcsd -f output, I assume it is normal because I see exact same error
> > > when I run takeownership from non-xen host and actually prove
ownership
> > > taken by using sealdata successfully) but when I try tpm_sealdata I
get
> > > above error.
> > >
> > > 2. After starting from scratch, I tried tpm_sealdata without first
try
> > > to take ownership. This time there is a different output:
> > >
> > > Enter SRK password:
> > > Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003 (3),
Bad
> > > Parameter
> > >
> > > I think I am not able to use vtpm because probably I am not doing
the
> > > right sequence of actions on domU. So if there is a document about
vtpm
> > > usage, please point me to it.
> > >
> > > And here is another question:
> > >
> > > I never run tpm_takeownership on dom0. Whenever I start from scratch
I
> > > let the vtpm_managerd to take ownership of tpm. However, I do not
know
> > > the owner or srk password it uses. When I use vtpm on domU and asked
> > for
> > > the srk pasword, which password should I enter? Also, should I take
> > > ownership of vtpm on domU every time I booted it? How do I save
> > state of
> > > the vtpm for a domain across boots?
> > >
> > > Thanks for time.
> > > Erdem Bayer
> > >
> > >
> > > Stefan Berger wrote On 27-02-2008 05:59:
> > > >
> > > > xense-devel-bounces@lists.xensource.com wrote on 02/26/2008
> > 06:28:01 PM:
> > > >
> > > > > Hi
> > > > >
> > > > > I have successfully applied the patch mentioned here
> > > > >
> > > >
> >
(http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html
> > > )
> > > >
> > > > > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> > > > >
> > > > > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> > > > >
> > > > > After reboot, vtpm_managerd runs ok. (output is attched to the
> > mail.)
> > > > >
> > > > > I created a pv vm with the option vtpm = ['instance=1,
> > backend=0'] The
> > > > > vm boots fine.
> > > > >
> > > > > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on
> > the vm.
> > > > >
> > > > > I run tcsd -f on the vm. (output is attched to the mail.)
> > > > >
> > > > > I checkout and run the trousers test suite. 10 tests passed with
230
> > > > > failed. (Is this expected?)
> > > >
> > > >
> > > > It is likely that this (v)TPM implementation has quite a few bugs,
> > but
> > > > I would not expect that many errors.
> > > >
> > > > >
> > > > > When I try tpm_takeownership on the vm, the command runs fine.
> > > > (Although
> > > > > a strange warning appers on tcsd output which is attched).
> > > >
> > > > This error may be related to older versions of the TPM device
driver
> > > > having used an ioctl interface for sending/receiving commands
to/from
> > > > the TPM and the TSS still tries this interface first. This should
not
> > > > be a reason for the errors you are seeing.
> > > >
> > > > >
> > > > > But when I try tpm_sealdata < foo on the vm I get the following
> > error.
> > > > >
> > > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113
(275),
> > > > > Authorization failed
> > > > >
> > > > > But other tpm_version runs fine on vm.
> > > > >
> > > > > tpm-test:~# tpm_version
> > > > > TPM 1.2 Version Info:
> > > > > Chip Version: 1.2.0.4
> > > > > Spec Level: 2
> > > > > Errata Revision: 94
> > > > > TPM Vendor ID:
> > > > > TPM Version: 01010000
> > > > > Manufacturer Info: 4554485a
> > > > >
> > > > > Also this quote is from Xen User's Guide:
> > > > >
> > > > > "Similarly, the TPM frontend driver must be compiled for the
kernel
> > > > > trying to use TPM functionality. Its driver can be selected in
the
> > > > > kernel configuration section Device Driver / Character Devices /
TPM
> > > > > Devices. Along with that the TPM driver for the built-in TPM
must be
> > > > > selected."
> > > > >
> > > > > According to my understanding driver for the built-in TPM must
be
> > > > > selected on the kernel where TPM frontend driver is used. Am I
> > correct
> > > > > about this assumption? (The problem is tpm_infineon driver can
> > not be
> > > >
> > > > The driver for the built-in Infineon TPM must be built into
Domain-0,
> > > > the TPM frontend driver in the guest domain and the backend driver
> > > > also into Domain-0. This has probably been done correctly since
> > > > otherwise the vTPM would not work at all.
> > > >
> > > >
> > > > > selected on an unpriviledged kernel, it can only be selected on
a
> > > > > priviledged kernel)
> > > > >
> > > > > Am I missing something here? Why do I get auth errors?
> > > >
> > > >
> > > > Did you try to run the same sequence of comands (tpm commands,
test
> > > > suite etc.) on a plain Linux kernel with the TSS stack against the
> > > > built-in Infineone TPM? From what I remember, the test suite for
the
> > > > TSS stack either tries to set a specific TPM owner password or it
> > must
> > > > previously have been set to it by the user, otherwise many
> > > > authentication errors will occur.
> > > >
> > > > Stefan
> > > >
> > > > >
> > > > > Thanks in advance.
> > > > >
> > > > > Erdem Bayer
> > > > > [attachment "vtpm_managerd.out" deleted by Stefan
Berger/Watson/IBM]
> > > > > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > > > > _______________________________________________
> > > > > Xense-devel mailing list
> > > > > Xense-devel@lists.xensource.com
> > > > > http://lists.xensource.com/xense-devel
> > >
> > > _______________________________________________
> > > Xense-devel mailing list
> > > Xense-devel@lists.xensource.com
> > > http://lists.xensource.com/xense-devel
[-- Attachment #1.2: Type: text/html, Size: 13064 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: [Xense-devel] Infineon vtpm problem
2008-02-28 8:42 ` Erdem Bayer
@ 2008-02-28 20:02 ` Stefan Berger
2008-02-29 11:04 ` Erdem Bayer
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Berger @ 2008-02-28 20:02 UTC (permalink / raw)
To: Erdem Bayer; +Cc: xen-devel, xense-devel
[-- Attachment #1.1: Type: text/plain, Size: 10724 bytes --]
xen-devel-bounces@lists.xensource.com wrote on 02/28/2008 03:42:07 AM:
> Hi
>
> I have looked through some source code and have the following questions:
>
> 1)
> in tools/vtpm/vtpm/tpm/tpm_storage.c
>
> TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE parentHandle, TPM_KEY *inKey,
> TPM_AUTH *auth1, TPM_KEY_HANDLE *inkeyHandle)
> {
> info("TPM_LoadKey2() is currently emulated by TPM_LoadKey()");
> return TPM_LoadKey(parentHandle, inKey, auth1, inkeyHandle);
> }
>
> So TPM_LoadKey2 is actually a wrapper around TPM_LoadKey() with exactly
> same parameters. My question is if they are using same parameters why
> one fails while the other succeeds?
It's (for example) the return path that's different. TPM_LoadKey2() does
NOT calculate the HMAC over the key's handle. And that's actually the
source of the bug.
>
> And why is it necessary to wrap the TPM_LoadKey function with exactly
> same call? Any pointers would be highly appreciated.
Here's a link to a fairly recent version of the specification.
https://www.trustedcomputinggroup.org/specs/TPM/mainP3Commandsrev103.zip
>
> 2)
> in tools/vtpm/vtpm/tpm/tpm_commands.h
>
> * Description: ([TPM_Part3], Section 10.5)
>
> What is this TPM_Part3 document mentioned here and where can I locate
> it? Is this the document named "TPM Main Part3 IBM Commands" written by
> Ken Goldman and you? If that is correct, I have Revision 10 of this
> document dated 25 April 2005 and that document does not have Section
> 10.5. Is there a more recent version that I am not aware of?
No, this is not referring to that document. It's referring to the one link
above.
>
> 3) Is this problem specific to TPM hardware (ie only infinion tpm) or
> xen version?
It's a bug in the TPM emulator.
This patch here does the trick. When I have some time I'll try to prepare
a patch for the patch that the Xen build process applies on top of the tpm
emulator code. I'll also send it to the maintainer(s) of the tpm emualtor.
--- ./tpm_emulator/tpm/tpm_cmd_handler.c 2008-02-27
16:35:41.000000000 -0500
+++ vtpm/tpm/tpm_cmd_handler.c 2008-02-28 14:43:28.000000000 -0500
@@ -94,12 +94,18 @@ void tpm_compute_out_param_digest(TPM_CO
sha1_ctx_t sha1;
UINT32 res = CPU_TO_BE32(rsp->result);
UINT32 ord = CPU_TO_BE32(ordinal);
+ UINT32 offset = 0;
/* compute SHA1 hash */
sha1_init(&sha1);
sha1_update(&sha1, (BYTE*)&res, 4);
sha1_update(&sha1, (BYTE*)&ord, 4);
- sha1_update(&sha1, rsp->param, rsp->paramSize);
+ if (ordinal == TPM_ORD_LoadKey2) {
+ offset = 4;
+ }
+ if (rsp->paramSize - offset > 0) {
+ sha1_update(&sha1, rsp->param + offset, rsp->paramSize - offset);
+ }
sha1_final(&sha1, rsp->auth1->digest);
if (rsp->auth2 != NULL) memcpy(rsp->auth2->digest,
rsp->auth1->digest, sizeof(rsp->auth1->digest));
Please try it.
>
> 4) You said you used some tools to trace and alter tss behaviour. What
> is this tool and how can I obtain it?
It's not a publicly available tool. It's basically forming the TPM
commands directly and writes them to /dev/tpm0 and so circumvents the TSS
stack.
Stefan
>
> Thanks for your time
> Erdem Bayer
>
> Stefan Berger wrote On 28-02-2008 04:47:
> >
> > xense-devel-bounces@lists.xensource.com wrote on 02/27/2008 04:02:41
PM:
> >
> > > Hi
> > >
> > > I have checked out the 0.3.2cvs version of trousers and finally get
the
> > > tsstest working with very few differences from when it is run under
> > > non-xen host. My previous attempts was on 0.3.1 (stable).
> > >
> > > However when run tpm_sealdata, I still get
> > >
> > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > > Authorization failed.
> >
> > So, I just tried this and I ran into the same problem. I then used
> > some tools that let me control whether to use TPM_LoadKey() or
> > TPM_LoadKey2(). Loading a key with TPM_LoadKey2() failed due to HMAC
> > authorization failing, TPM_LoadKey() worked. From what I saw is that
> > the TSS is using TPM_LoadKey2() and the TPM implementation then states
> > that TPM_LoadKey2() is emulated using TPM_LoadKey(). Well, it seems to
> > be a bug in the TPM_LoadKey2() implementation.
> >
> > >
> > > This reminds me that maybe I am using vtpm wrong way. Is there a
> > > document about how to use vtpm?
> > >
> > No, you are using it correctly.
> >
> > Stefan
> >
> >
> >
> > > Here is what I do from sratch:
> > >
> > > 1. Clear and reactivate TPM from bios.
> > > 2. Run vtpm_managerd in dom0 and let it continue running on console.
> > > 3. Boot domU with vif statement in config file.
> > > 4. Run tcsd -f on domU and let it continue running on console.
> > >
> > > From now on every tpm operation I run on domU returns an error.
> > >
> > > Operations tried on domU
> > >
> > > 1. I tried tpm_takeownership with success (although I see an error
on
> > > tcsd -f output, I assume it is normal because I see exact same error
> > > when I run takeownership from non-xen host and actually prove
ownership
> > > taken by using sealdata successfully) but when I try tpm_sealdata I
get
> > > above error.
> > >
> > > 2. After starting from scratch, I tried tpm_sealdata without first
try
> > > to take ownership. This time there is a different output:
> > >
> > > Enter SRK password:
> > > Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003 (3),
Bad
> > > Parameter
> > >
> > > I think I am not able to use vtpm because probably I am not doing
the
> > > right sequence of actions on domU. So if there is a document about
vtpm
> > > usage, please point me to it.
> > >
> > > And here is another question:
> > >
> > > I never run tpm_takeownership on dom0. Whenever I start from scratch
I
> > > let the vtpm_managerd to take ownership of tpm. However, I do not
know
> > > the owner or srk password it uses. When I use vtpm on domU and asked
> > for
> > > the srk pasword, which password should I enter? Also, should I take
> > > ownership of vtpm on domU every time I booted it? How do I save
> > state of
> > > the vtpm for a domain across boots?
> > >
> > > Thanks for time.
> > > Erdem Bayer
> > >
> > >
> > > Stefan Berger wrote On 27-02-2008 05:59:
> > > >
> > > > xense-devel-bounces@lists.xensource.com wrote on 02/26/2008
> > 06:28:01 PM:
> > > >
> > > > > Hi
> > > > >
> > > > > I have successfully applied the patch mentioned here
> > > > >
> > > >
> >
(http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html
> > > )
> > > >
> > > > > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> > > > >
> > > > > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> > > > >
> > > > > After reboot, vtpm_managerd runs ok. (output is attched to the
> > mail.)
> > > > >
> > > > > I created a pv vm with the option vtpm = ['instance=1,
> > backend=0'] The
> > > > > vm boots fine.
> > > > >
> > > > > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on
> > the vm.
> > > > >
> > > > > I run tcsd -f on the vm. (output is attched to the mail.)
> > > > >
> > > > > I checkout and run the trousers test suite. 10 tests passed with
230
> > > > > failed. (Is this expected?)
> > > >
> > > >
> > > > It is likely that this (v)TPM implementation has quite a few bugs,
> > but
> > > > I would not expect that many errors.
> > > >
> > > > >
> > > > > When I try tpm_takeownership on the vm, the command runs fine.
> > > > (Although
> > > > > a strange warning appers on tcsd output which is attched).
> > > >
> > > > This error may be related to older versions of the TPM device
driver
> > > > having used an ioctl interface for sending/receiving commands
to/from
> > > > the TPM and the TSS still tries this interface first. This should
not
> > > > be a reason for the errors you are seeing.
> > > >
> > > > >
> > > > > But when I try tpm_sealdata < foo on the vm I get the following
> > error.
> > > > >
> > > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113
(275),
> > > > > Authorization failed
> > > > >
> > > > > But other tpm_version runs fine on vm.
> > > > >
> > > > > tpm-test:~# tpm_version
> > > > > TPM 1.2 Version Info:
> > > > > Chip Version: 1.2.0.4
> > > > > Spec Level: 2
> > > > > Errata Revision: 94
> > > > > TPM Vendor ID:
> > > > > TPM Version: 01010000
> > > > > Manufacturer Info: 4554485a
> > > > >
> > > > > Also this quote is from Xen User's Guide:
> > > > >
> > > > > "Similarly, the TPM frontend driver must be compiled for the
kernel
> > > > > trying to use TPM functionality. Its driver can be selected in
the
> > > > > kernel configuration section Device Driver / Character Devices /
TPM
> > > > > Devices. Along with that the TPM driver for the built-in TPM
must be
> > > > > selected."
> > > > >
> > > > > According to my understanding driver for the built-in TPM must
be
> > > > > selected on the kernel where TPM frontend driver is used. Am I
> > correct
> > > > > about this assumption? (The problem is tpm_infineon driver can
> > not be
> > > >
> > > > The driver for the built-in Infineon TPM must be built into
Domain-0,
> > > > the TPM frontend driver in the guest domain and the backend driver
> > > > also into Domain-0. This has probably been done correctly since
> > > > otherwise the vTPM would not work at all.
> > > >
> > > >
> > > > > selected on an unpriviledged kernel, it can only be selected on
a
> > > > > priviledged kernel)
> > > > >
> > > > > Am I missing something here? Why do I get auth errors?
> > > >
> > > >
> > > > Did you try to run the same sequence of comands (tpm commands,
test
> > > > suite etc.) on a plain Linux kernel with the TSS stack against the
> > > > built-in Infineone TPM? From what I remember, the test suite for
the
> > > > TSS stack either tries to set a specific TPM owner password or it
> > must
> > > > previously have been set to it by the user, otherwise many
> > > > authentication errors will occur.
> > > >
> > > > Stefan
> > > >
> > > > >
> > > > > Thanks in advance.
> > > > >
> > > > > Erdem Bayer
> > > > > [attachment "vtpm_managerd.out" deleted by Stefan
Berger/Watson/IBM]
> > > > > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > > > > _______________________________________________
> > > > > Xense-devel mailing list
> > > > > Xense-devel@lists.xensource.com
> > > > > http://lists.xensource.com/xense-devel
> > >
> > > _______________________________________________
> > > Xense-devel mailing list
> > > Xense-devel@lists.xensource.com
> > > http://lists.xensource.com/xense-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 15758 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-28 20:02 ` Stefan Berger
@ 2008-02-29 11:04 ` Erdem Bayer
2008-02-29 14:44 ` Stefan Berger
0 siblings, 1 reply; 10+ messages in thread
From: Erdem Bayer @ 2008-02-29 11:04 UTC (permalink / raw)
To: Stefan Berger; +Cc: xen-devel, xense-devel
Hi
For the record, the patch you sent to the xen-devel list
(http://lists.xensource.com/archives/html/xen-devel/2008-02/msg01092.html)
eliminated the problem. Thank you very much for your time and effort.
Erdem Bayer
Stefan Berger wrote On 28-02-2008 22:02:
>
> xen-devel-bounces@lists.xensource.com wrote on 02/28/2008 03:42:07 AM:
>
> > Hi
> >
> > I have looked through some source code and have the following questions:
> >
> > 1)
> > in tools/vtpm/vtpm/tpm/tpm_storage.c
> >
> > TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE parentHandle, TPM_KEY *inKey,
> > TPM_AUTH *auth1, TPM_KEY_HANDLE *inkeyHandle)
> > {
> > info("TPM_LoadKey2() is currently emulated by TPM_LoadKey()");
> > return TPM_LoadKey(parentHandle, inKey, auth1, inkeyHandle);
> > }
> >
> > So TPM_LoadKey2 is actually a wrapper around TPM_LoadKey() with exactly
> > same parameters. My question is if they are using same parameters why
> > one fails while the other succeeds?
>
> It's (for example) the return path that's different. TPM_LoadKey2()
> does NOT calculate the HMAC over the key's handle. And that's actually
> the source of the bug.
>
> >
> > And why is it necessary to wrap the TPM_LoadKey function with exactly
> > same call? Any pointers would be highly appreciated.
>
>
> Here's a link to a fairly recent version of the specification.
>
> https://www.trustedcomputinggroup.org/specs/TPM/mainP3Commandsrev103.zip
>
> >
> > 2)
> > in tools/vtpm/vtpm/tpm/tpm_commands.h
> >
> > * Description: ([TPM_Part3], Section 10.5)
> >
> > What is this TPM_Part3 document mentioned here and where can I locate
> > it? Is this the document named "TPM Main Part3 IBM Commands" written by
> > Ken Goldman and you? If that is correct, I have Revision 10 of this
> > document dated 25 April 2005 and that document does not have Section
> > 10.5. Is there a more recent version that I am not aware of?
>
> No, this is not referring to that document. It's referring to the one
> link above.
>
> >
> > 3) Is this problem specific to TPM hardware (ie only infinion tpm) or
> > xen version?
>
> It's a bug in the TPM emulator.
>
> This patch here does the trick. When I have some time I'll try to
> prepare a patch for the patch that the Xen build process applies on
> top of the tpm emulator code. I'll also send it to the maintainer(s)
> of the tpm emualtor.
>
> --- ./tpm_emulator/tpm/tpm_cmd_handler.c 2008-02-27
> 16:35:41.000000000 -0500
> +++ vtpm/tpm/tpm_cmd_handler.c 2008-02-28 14:43:28.000000000 -0500
> @@ -94,12 +94,18 @@ void tpm_compute_out_param_digest(TPM_CO
> sha1_ctx_t sha1;
> UINT32 res = CPU_TO_BE32(rsp->result);
> UINT32 ord = CPU_TO_BE32(ordinal);
> + UINT32 offset = 0;
>
> /* compute SHA1 hash */
> sha1_init(&sha1);
> sha1_update(&sha1, (BYTE*)&res, 4);
> sha1_update(&sha1, (BYTE*)&ord, 4);
> - sha1_update(&sha1, rsp->param, rsp->paramSize);
> + if (ordinal == TPM_ORD_LoadKey2) {
> + offset = 4;
> + }
> + if (rsp->paramSize - offset > 0) {
> + sha1_update(&sha1, rsp->param + offset, rsp->paramSize - offset);
> + }
> sha1_final(&sha1, rsp->auth1->digest);
> if (rsp->auth2 != NULL) memcpy(rsp->auth2->digest,
> rsp->auth1->digest, sizeof(rsp->auth1->digest));
>
> Please try it.
>
>
> >
> > 4) You said you used some tools to trace and alter tss behaviour. What
> > is this tool and how can I obtain it?
>
> It's not a publicly available tool. It's basically forming the TPM
> commands directly and writes them to /dev/tpm0 and so circumvents the
> TSS stack.
>
> Stefan
>
>
> >
> > Thanks for your time
> > Erdem Bayer
> >
> > Stefan Berger wrote On 28-02-2008 04:47:
> > >
> > > xense-devel-bounces@lists.xensource.com wrote on 02/27/2008
> 04:02:41 PM:
> > >
> > > > Hi
> > > >
> > > > I have checked out the 0.3.2cvs version of trousers and finally
> get the
> > > > tsstest working with very few differences from when it is run under
> > > > non-xen host. My previous attempts was on 0.3.1 (stable).
> > > >
> > > > However when run tpm_sealdata, I still get
> > > >
> > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113 (275),
> > > > Authorization failed.
> > >
> > > So, I just tried this and I ran into the same problem. I then used
> > > some tools that let me control whether to use TPM_LoadKey() or
> > > TPM_LoadKey2(). Loading a key with TPM_LoadKey2() failed due to HMAC
> > > authorization failing, TPM_LoadKey() worked. From what I saw is that
> > > the TSS is using TPM_LoadKey2() and the TPM implementation then
> states
> > > that TPM_LoadKey2() is emulated using TPM_LoadKey(). Well, it
> seems to
> > > be a bug in the TPM_LoadKey2() implementation.
> > >
> > > >
> > > > This reminds me that maybe I am using vtpm wrong way. Is there a
> > > > document about how to use vtpm?
> > > >
> > > No, you are using it correctly.
> > >
> > > Stefan
> > >
> > >
> > >
> > > > Here is what I do from sratch:
> > > >
> > > > 1. Clear and reactivate TPM from bios.
> > > > 2. Run vtpm_managerd in dom0 and let it continue running on console.
> > > > 3. Boot domU with vif statement in config file.
> > > > 4. Run tcsd -f on domU and let it continue running on console.
> > > >
> > > > From now on every tpm operation I run on domU returns an error.
> > > >
> > > > Operations tried on domU
> > > >
> > > > 1. I tried tpm_takeownership with success (although I see an
> error on
> > > > tcsd -f output, I assume it is normal because I see exact same error
> > > > when I run takeownership from non-xen host and actually prove
> ownership
> > > > taken by using sealdata successfully) but when I try
> tpm_sealdata I get
> > > > above error.
> > > >
> > > > 2. After starting from scratch, I tried tpm_sealdata without
> first try
> > > > to take ownership. This time there is a different output:
> > > >
> > > > Enter SRK password:
> > > > Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003
> (3), Bad
> > > > Parameter
> > > >
> > > > I think I am not able to use vtpm because probably I am not
> doing the
> > > > right sequence of actions on domU. So if there is a document
> about vtpm
> > > > usage, please point me to it.
> > > >
> > > > And here is another question:
> > > >
> > > > I never run tpm_takeownership on dom0. Whenever I start from
> scratch I
> > > > let the vtpm_managerd to take ownership of tpm. However, I do
> not know
> > > > the owner or srk password it uses. When I use vtpm on domU and
> asked
> > > for
> > > > the srk pasword, which password should I enter? Also, should I take
> > > > ownership of vtpm on domU every time I booted it? How do I save
> > > state of
> > > > the vtpm for a domain across boots?
> > > >
> > > > Thanks for time.
> > > > Erdem Bayer
> > > >
> > > >
> > > > Stefan Berger wrote On 27-02-2008 05:59:
> > > > >
> > > > > xense-devel-bounces@lists.xensource.com wrote on 02/26/2008
> > > 06:28:01 PM:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > I have successfully applied the patch mentioned here
> > > > > >
> > > > >
> > >
> (http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html
> > > > )
> > > > >
> > > > > > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> > > > > >
> > > > > > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> > > > > >
> > > > > > After reboot, vtpm_managerd runs ok. (output is attched to the
> > > mail.)
> > > > > >
> > > > > > I created a pv vm with the option vtpm = ['instance=1,
> > > backend=0'] The
> > > > > > vm boots fine.
> > > > > >
> > > > > > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources on
> > > the vm.
> > > > > >
> > > > > > I run tcsd -f on the vm. (output is attched to the mail.)
> > > > > >
> > > > > > I checkout and run the trousers test suite. 10 tests passed
> with 230
> > > > > > failed. (Is this expected?)
> > > > >
> > > > >
> > > > > It is likely that this (v)TPM implementation has quite a few
> bugs,
> > > but
> > > > > I would not expect that many errors.
> > > > >
> > > > > >
> > > > > > When I try tpm_takeownership on the vm, the command runs fine.
> > > > > (Although
> > > > > > a strange warning appers on tcsd output which is attched).
> > > > >
> > > > > This error may be related to older versions of the TPM device
> driver
> > > > > having used an ioctl interface for sending/receiving commands
> to/from
> > > > > the TPM and the TSS still tries this interface first. This
> should not
> > > > > be a reason for the errors you are seeing.
> > > > >
> > > > > >
> > > > > > But when I try tpm_sealdata < foo on the vm I get the following
> > > error.
> > > > > >
> > > > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113
> (275),
> > > > > > Authorization failed
> > > > > >
> > > > > > But other tpm_version runs fine on vm.
> > > > > >
> > > > > > tpm-test:~# tpm_version
> > > > > > TPM 1.2 Version Info:
> > > > > > Chip Version: 1.2.0.4
> > > > > > Spec Level: 2
> > > > > > Errata Revision: 94
> > > > > > TPM Vendor ID:
> > > > > > TPM Version: 01010000
> > > > > > Manufacturer Info: 4554485a
> > > > > >
> > > > > > Also this quote is from Xen User's Guide:
> > > > > >
> > > > > > "Similarly, the TPM frontend driver must be compiled for the
> kernel
> > > > > > trying to use TPM functionality. Its driver can be selected
> in the
> > > > > > kernel configuration section Device Driver / Character
> Devices / TPM
> > > > > > Devices. Along with that the TPM driver for the built-in TPM
> must be
> > > > > > selected."
> > > > > >
> > > > > > According to my understanding driver for the built-in TPM
> must be
> > > > > > selected on the kernel where TPM frontend driver is used. Am I
> > > correct
> > > > > > about this assumption? (The problem is tpm_infineon driver can
> > > not be
> > > > >
> > > > > The driver for the built-in Infineon TPM must be built into
> Domain-0,
> > > > > the TPM frontend driver in the guest domain and the backend driver
> > > > > also into Domain-0. This has probably been done correctly since
> > > > > otherwise the vTPM would not work at all.
> > > > >
> > > > >
> > > > > > selected on an unpriviledged kernel, it can only be selected
> on a
> > > > > > priviledged kernel)
> > > > > >
> > > > > > Am I missing something here? Why do I get auth errors?
> > > > >
> > > > >
> > > > > Did you try to run the same sequence of comands (tpm commands,
> test
> > > > > suite etc.) on a plain Linux kernel with the TSS stack against the
> > > > > built-in Infineone TPM? From what I remember, the test suite
> for the
> > > > > TSS stack either tries to set a specific TPM owner password or it
> > > must
> > > > > previously have been set to it by the user, otherwise many
> > > > > authentication errors will occur.
> > > > >
> > > > > Stefan
> > > > >
> > > > > >
> > > > > > Thanks in advance.
> > > > > >
> > > > > > Erdem Bayer
> > > > > > [attachment "vtpm_managerd.out" deleted by Stefan
> Berger/Watson/IBM]
> > > > > > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > > > > > _______________________________________________
> > > > > > Xense-devel mailing list
> > > > > > Xense-devel@lists.xensource.com
> > > > > > http://lists.xensource.com/xense-devel
> > > >
> > > > _______________________________________________
> > > > Xense-devel mailing list
> > > > Xense-devel@lists.xensource.com
> > > > http://lists.xensource.com/xense-devel
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xense-devel] Infineon vtpm problem
2008-02-29 11:04 ` Erdem Bayer
@ 2008-02-29 14:44 ` Stefan Berger
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Berger @ 2008-02-29 14:44 UTC (permalink / raw)
To: Erdem Bayer; +Cc: xen-devel, xense-devel
[-- Attachment #1.1: Type: text/plain, Size: 12845 bytes --]
Erdem Bayer <ebayer@bayer.gen.tr> wrote on 02/29/2008 06:04:56 AM:
> Hi
>
> For the record, the patch you sent to the xen-devel list
>
(http://lists.xensource.com/archives/html/xen-devel/2008-02/msg01092.html)
> eliminated the problem. Thank you very much for your time and effort.
What would really be needed is an upgrade of the tpm emulator that's being
downloaded by the build process. Version 0.4 is outdated and a more recent
version is 0.5.1. Actually Mario Strasser, the author of the tpm emulator,
said that that particular error had been fixed in version 0.4.1. The
problem with the newer version is that the Xen patch against the emulator
has almost all hunks rejected -- so forward-porting could become quite
involving...
Stefan
>
> Erdem Bayer
>
> Stefan Berger wrote On 28-02-2008 22:02:
> >
> > xen-devel-bounces@lists.xensource.com wrote on 02/28/2008 03:42:07 AM:
> >
> > > Hi
> > >
> > > I have looked through some source code and have the following
questions:
> > >
> > > 1)
> > > in tools/vtpm/vtpm/tpm/tpm_storage.c
> > >
> > > TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE parentHandle, TPM_KEY *inKey,
> > > TPM_AUTH *auth1, TPM_KEY_HANDLE
*inkeyHandle)
> > > {
> > > info("TPM_LoadKey2() is currently emulated by TPM_LoadKey()");
> > > return TPM_LoadKey(parentHandle, inKey, auth1, inkeyHandle);
> > > }
> > >
> > > So TPM_LoadKey2 is actually a wrapper around TPM_LoadKey() with
exactly
> > > same parameters. My question is if they are using same parameters
why
> > > one fails while the other succeeds?
> >
> > It's (for example) the return path that's different. TPM_LoadKey2()
> > does NOT calculate the HMAC over the key's handle. And that's actually
> > the source of the bug.
> >
> > >
> > > And why is it necessary to wrap the TPM_LoadKey function with
exactly
> > > same call? Any pointers would be highly appreciated.
> >
> >
> > Here's a link to a fairly recent version of the specification.
> >
> >
https://www.trustedcomputinggroup.org/specs/TPM/mainP3Commandsrev103.zip
> >
> > >
> > > 2)
> > > in tools/vtpm/vtpm/tpm/tpm_commands.h
> > >
> > > * Description: ([TPM_Part3], Section 10.5)
> > >
> > > What is this TPM_Part3 document mentioned here and where can I
locate
> > > it? Is this the document named "TPM Main Part3 IBM Commands" written
by
> > > Ken Goldman and you? If that is correct, I have Revision 10 of this
> > > document dated 25 April 2005 and that document does not have Section
> > > 10.5. Is there a more recent version that I am not aware of?
> >
> > No, this is not referring to that document. It's referring to the one
> > link above.
> >
> > >
> > > 3) Is this problem specific to TPM hardware (ie only infinion tpm)
or
> > > xen version?
> >
> > It's a bug in the TPM emulator.
> >
> > This patch here does the trick. When I have some time I'll try to
> > prepare a patch for the patch that the Xen build process applies on
> > top of the tpm emulator code. I'll also send it to the maintainer(s)
> > of the tpm emualtor.
> >
> > --- ./tpm_emulator/tpm/tpm_cmd_handler.c 2008-02-27
> > 16:35:41.000000000 -0500
> > +++ vtpm/tpm/tpm_cmd_handler.c 2008-02-28 14:43:28.000000000
-0500
> > @@ -94,12 +94,18 @@ void tpm_compute_out_param_digest(TPM_CO
> > sha1_ctx_t sha1;
> > UINT32 res = CPU_TO_BE32(rsp->result);
> > UINT32 ord = CPU_TO_BE32(ordinal);
> > + UINT32 offset = 0;
> >
> > /* compute SHA1 hash */
> > sha1_init(&sha1);
> > sha1_update(&sha1, (BYTE*)&res, 4);
> > sha1_update(&sha1, (BYTE*)&ord, 4);
> > - sha1_update(&sha1, rsp->param, rsp->paramSize);
> > + if (ordinal == TPM_ORD_LoadKey2) {
> > + offset = 4;
> > + }
> > + if (rsp->paramSize - offset > 0) {
> > + sha1_update(&sha1, rsp->param + offset, rsp->paramSize -
offset);
> > + }
> > sha1_final(&sha1, rsp->auth1->digest);
> > if (rsp->auth2 != NULL) memcpy(rsp->auth2->digest,
> > rsp->auth1->digest, sizeof(rsp->auth1->digest));
> >
> > Please try it.
> >
> >
> > >
> > > 4) You said you used some tools to trace and alter tss behaviour.
What
> > > is this tool and how can I obtain it?
> >
> > It's not a publicly available tool. It's basically forming the TPM
> > commands directly and writes them to /dev/tpm0 and so circumvents the
> > TSS stack.
> >
> > Stefan
> >
> >
> > >
> > > Thanks for your time
> > > Erdem Bayer
> > >
> > > Stefan Berger wrote On 28-02-2008 04:47:
> > > >
> > > > xense-devel-bounces@lists.xensource.com wrote on 02/27/2008
> > 04:02:41 PM:
> > > >
> > > > > Hi
> > > > >
> > > > > I have checked out the 0.3.2cvs version of trousers and finally
> > get the
> > > > > tsstest working with very few differences from when it is run
under
> > > > > non-xen host. My previous attempts was on 0.3.1 (stable).
> > > > >
> > > > > However when run tpm_sealdata, I still get
> > > > >
> > > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113
(275),
> > > > > Authorization failed.
> > > >
> > > > So, I just tried this and I ran into the same problem. I then used
> > > > some tools that let me control whether to use TPM_LoadKey() or
> > > > TPM_LoadKey2(). Loading a key with TPM_LoadKey2() failed due to
HMAC
> > > > authorization failing, TPM_LoadKey() worked. From what I saw is
that
> > > > the TSS is using TPM_LoadKey2() and the TPM implementation then
> > states
> > > > that TPM_LoadKey2() is emulated using TPM_LoadKey(). Well, it
> > seems to
> > > > be a bug in the TPM_LoadKey2() implementation.
> > > >
> > > > >
> > > > > This reminds me that maybe I am using vtpm wrong way. Is there a
> > > > > document about how to use vtpm?
> > > > >
> > > > No, you are using it correctly.
> > > >
> > > > Stefan
> > > >
> > > >
> > > >
> > > > > Here is what I do from sratch:
> > > > >
> > > > > 1. Clear and reactivate TPM from bios.
> > > > > 2. Run vtpm_managerd in dom0 and let it continue running on
console.
> > > > > 3. Boot domU with vif statement in config file.
> > > > > 4. Run tcsd -f on domU and let it continue running on console.
> > > > >
> > > > > From now on every tpm operation I run on domU returns an error.
> > > > >
> > > > > Operations tried on domU
> > > > >
> > > > > 1. I tried tpm_takeownership with success (although I see an
> > error on
> > > > > tcsd -f output, I assume it is normal because I see exact same
error
> > > > > when I run takeownership from non-xen host and actually prove
> > ownership
> > > > > taken by using sealdata successfully) but when I try
> > tpm_sealdata I get
> > > > > above error.
> > > > >
> > > > > 2. After starting from scratch, I tried tpm_sealdata without
> > first try
> > > > > to take ownership. This time there is a different output:
> > > > >
> > > > > Enter SRK password:
> > > > > Tspi_Key_CreateKey failed: 0x00000003 - layer=tpm, code=0003
> > (3), Bad
> > > > > Parameter
> > > > >
> > > > > I think I am not able to use vtpm because probably I am not
> > doing the
> > > > > right sequence of actions on domU. So if there is a document
> > about vtpm
> > > > > usage, please point me to it.
> > > > >
> > > > > And here is another question:
> > > > >
> > > > > I never run tpm_takeownership on dom0. Whenever I start from
> > scratch I
> > > > > let the vtpm_managerd to take ownership of tpm. However, I do
> > not know
> > > > > the owner or srk password it uses. When I use vtpm on domU and
> > asked
> > > > for
> > > > > the srk pasword, which password should I enter? Also, should I
take
> > > > > ownership of vtpm on domU every time I booted it? How do I save
> > > > state of
> > > > > the vtpm for a domain across boots?
> > > > >
> > > > > Thanks for time.
> > > > > Erdem Bayer
> > > > >
> > > > >
> > > > > Stefan Berger wrote On 27-02-2008 05:59:
> > > > > >
> > > > > > xense-devel-bounces@lists.xensource.com wrote on 02/26/2008
> > > > 06:28:01 PM:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > I have successfully applied the patch mentioned here
> > > > > > >
> > > > > >
> > > >
> >
(http://lists.xensource.com/archives/html/xense-devel/2007-04/msg00005.html
> > > > > )
> > > > > >
> > > > > > > to the xen v. 3.1.3 on an HP nx8325 with Infineon TPM.
> > > > > > >
> > > > > > > I cleared the tpm, deleted /var/vtpm/VTPM file and rebooted.
> > > > > > >
> > > > > > > After reboot, vtpm_managerd runs ok. (output is attched to
the
> > > > mail.)
> > > > > > >
> > > > > > > I created a pv vm with the option vtpm = ['instance=1,
> > > > backend=0'] The
> > > > > > > vm boots fine.
> > > > > > >
> > > > > > > I installed trousers-0.3.1 and tpm-tools-1.3.1 from sources
on
> > > > the vm.
> > > > > > >
> > > > > > > I run tcsd -f on the vm. (output is attched to the mail.)
> > > > > > >
> > > > > > > I checkout and run the trousers test suite. 10 tests passed
> > with 230
> > > > > > > failed. (Is this expected?)
> > > > > >
> > > > > >
> > > > > > It is likely that this (v)TPM implementation has quite a few
> > bugs,
> > > > but
> > > > > > I would not expect that many errors.
> > > > > >
> > > > > > >
> > > > > > > When I try tpm_takeownership on the vm, the command runs
fine.
> > > > > > (Although
> > > > > > > a strange warning appers on tcsd output which is attched).
> > > > > >
> > > > > > This error may be related to older versions of the TPM device
> > driver
> > > > > > having used an ioctl interface for sending/receiving commands
> > to/from
> > > > > > the TPM and the TSS still tries this interface first. This
> > should not
> > > > > > be a reason for the errors you are seeing.
> > > > > >
> > > > > > >
> > > > > > > But when I try tpm_sealdata < foo on the vm I get the
following
> > > > error.
> > > > > > >
> > > > > > > Tspi_Key_LoadKey failed: 0x00003113 - layer=tsp, code=0113
> > (275),
> > > > > > > Authorization failed
> > > > > > >
> > > > > > > But other tpm_version runs fine on vm.
> > > > > > >
> > > > > > > tpm-test:~# tpm_version
> > > > > > > TPM 1.2 Version Info:
> > > > > > > Chip Version: 1.2.0.4
> > > > > > > Spec Level: 2
> > > > > > > Errata Revision: 94
> > > > > > > TPM Vendor ID:
> > > > > > > TPM Version: 01010000
> > > > > > > Manufacturer Info: 4554485a
> > > > > > >
> > > > > > > Also this quote is from Xen User's Guide:
> > > > > > >
> > > > > > > "Similarly, the TPM frontend driver must be compiled for the
> > kernel
> > > > > > > trying to use TPM functionality. Its driver can be selected
> > in the
> > > > > > > kernel configuration section Device Driver / Character
> > Devices / TPM
> > > > > > > Devices. Along with that the TPM driver for the built-in TPM
> > must be
> > > > > > > selected."
> > > > > > >
> > > > > > > According to my understanding driver for the built-in TPM
> > must be
> > > > > > > selected on the kernel where TPM frontend driver is used. Am
I
> > > > correct
> > > > > > > about this assumption? (The problem is tpm_infineon driver
can
> > > > not be
> > > > > >
> > > > > > The driver for the built-in Infineon TPM must be built into
> > Domain-0,
> > > > > > the TPM frontend driver in the guest domain and the backend
driver
> > > > > > also into Domain-0. This has probably been done correctly
since
> > > > > > otherwise the vTPM would not work at all.
> > > > > >
> > > > > >
> > > > > > > selected on an unpriviledged kernel, it can only be selected
> > on a
> > > > > > > priviledged kernel)
> > > > > > >
> > > > > > > Am I missing something here? Why do I get auth errors?
> > > > > >
> > > > > >
> > > > > > Did you try to run the same sequence of comands (tpm commands,
> > test
> > > > > > suite etc.) on a plain Linux kernel with the TSS stack against
the
> > > > > > built-in Infineone TPM? From what I remember, the test suite
> > for the
> > > > > > TSS stack either tries to set a specific TPM owner password or
it
> > > > must
> > > > > > previously have been set to it by the user, otherwise many
> > > > > > authentication errors will occur.
> > > > > >
> > > > > > Stefan
> > > > > >
> > > > > > >
> > > > > > > Thanks in advance.
> > > > > > >
> > > > > > > Erdem Bayer
> > > > > > > [attachment "vtpm_managerd.out" deleted by Stefan
> > Berger/Watson/IBM]
> > > > > > > [attachment "tcsd.out" deleted by Stefan Berger/Watson/IBM]
> > > > > > > _______________________________________________
> > > > > > > Xense-devel mailing list
> > > > > > > Xense-devel@lists.xensource.com
> > > > > > > http://lists.xensource.com/xense-devel
> > > > >
> > > > > _______________________________________________
> > > > > Xense-devel mailing list
> > > > > Xense-devel@lists.xensource.com
> > > > > http://lists.xensource.com/xense-devel
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 19164 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-02-29 14:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-26 23:28 Infineon vtpm problem Erdem Bayer
2008-02-27 3:59 ` [Xense-devel] " Stefan Berger
2008-02-27 21:02 ` Erdem Bayer
2008-02-28 2:47 ` Stefan Berger
2008-02-28 8:42 ` Erdem Bayer
2008-02-28 20:02 ` Stefan Berger
2008-02-29 11:04 ` Erdem Bayer
2008-02-29 14:44 ` Stefan Berger
2008-02-28 12:28 ` Erdem Bayer
2008-02-28 19:55 ` Stefan Berger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.