TPM deactivated on recent kernels > 4.2 tested

[xrayn]

Hi, I tested the TPM emulator on three different machines with kernel version.
Machine 1:
4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u1 (2017-06-18) x86_64 GNU/Linux

Here the proposed patch from #21 was used to successfully compile the code.
Here, the TPM gets deactivated during the startup of a virtual machine. Using:

qemu-system-x86_64 -smp 2 -m 1024 -hda image.qcow2 -net user,hostfwd=tcp::2223-:22 -net nic -enable-kvm -tpmdev passthrough,id=tpm,path=/dev/tpm,cancel-path=/dev/null -device tpm-tis,tpmdev=tpm

Version: QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6)

Here the debug log.

pmd.c:523: Info: starting TPM Emulator daemon (1.2.0.7-475)
tpmd.c:102: Info: parsing options
tpmd.c:109: Debug: debug mode enabled
tpmd.c:175: Debug: startup mode = 'clear'
tpmd.c:228: Info: installing signal handlers
tpmd.c:387: Info: staring main loop
tpmd.c:302: Info: initializing socket /var/run/tpm/tpmd_socket:0
tpmd.c:401: Debug: initializing TPM emulator
tpm_emulator_extern.c:101: Info: _tpm_extern_init()
tpm_emulator_extern.c:104: Debug: openening random device /dev/urandom
tpm_cmd_handler.c:4113: Debug: tpm_emulator_init(1, 0x00000000)
tpm_startup.c:29: Info: TPM_Init()
tpm_testing.c:243: Info: TPM_SelfTestFull()
tpm_testing.c:39: Debug: tpm_test_prng()
tpm_testing.c:69: Debug: Monobit: 10016
tpm_testing.c:70: Debug: Poker:   9.6
tpm_testing.c:71: Debug: run_1:   2483, 2426
tpm_testing.c:72: Debug: run_2:   1212, 1250
tpm_testing.c:73: Debug: run_3:   611, 622
tpm_testing.c:74: Debug: run_4:   305, 327
tpm_testing.c:75: Debug: run_5:   168, 163
tpm_testing.c:76: Debug: run_6+:  166, 157
tpm_testing.c:77: Debug: run_34:  0
tpm_testing.c:111: Debug: tpm_test_sha1()
tpm_testing.c:157: Debug: tpm_test_hmac()
tpm_testing.c:184: Debug: tpm_test_rsa_EK()
tpm_testing.c:186: Debug: tpm_rsa_generate_key()
tpm_testing.c:191: Debug: testing endorsement key
tpm_testing.c:197: Debug: tpm_rsa_sign(RSA_SSA_PKCS1_SHA1)
tpm_testing.c:200: Debug: tpm_rsa_verify(RSA_SSA_PKCS1_SHA1)
tpm_testing.c:203: Debug: tpm_rsa_sign(RSA_SSA_PKCS1_DER)
tpm_testing.c:206: Debug: tpm_rsa_verify(RSA_SSA_PKCS1_DER)
tpm_testing.c:210: Debug: tpm_rsa_encrypt(RSA_ES_PKCSV15)
tpm_testing.c:214: Debug: tpm_rsa_decrypt(RSA_ES_PKCSV15)
tpm_testing.c:218: Debug: verify plain text
tpm_testing.c:221: Debug: tpm_rsa_encrypt(RSA_ES_OAEP_SHA1)
tpm_testing.c:225: Debug: tpm_rsa_decrypt(RSA_ES_OAEP_SHA1)
tpm_testing.c:229: Debug: verify plain text
tpm_testing.c:261: Info: Self-Test succeeded
tpm_startup.c:43: Info: TPM_Startup(1)
tpmd.c:412: Debug: waiting for connections...
tpmd.c:452: Debug: waiting for commands...
tpmd.c:485: Debug: received 10 bytes
tpm_cmd_handler.c:4143: Debug: tpm_handle_command()
tpm_cmd_handler.c:3456: Info: The tag value sent to for a command (0x8001) is invalid
tpmd.c:491: Debug: sending 10 bytes
tpmd.c:452: Debug: waiting for commands...
tpmd.c:485: Debug: received 10 bytes
tpm_cmd_handler.c:4143: Debug: tpm_handle_command()
tpm_cmd_handler.c:3450: Debug: [TPM_TAG_RQU_COMMAND]
tpm_cmd_handler.c:3946: Debug: [TPM_ORD_GetTicks]
tpm_ticks.c:32: Info: TPM_GetTicks()
tpm_cmd_handler.c:4084: Info: TPM command succeeded
tpmd.c:491: Debug: sending 42 bytes
tpmd.c:452: Debug: waiting for commands...
tpmd.c:452: Debug: waiting for commands...
tpmd.c:485: Debug: received 12 bytes
tpm_cmd_handler.c:4143: Debug: tpm_handle_command()
tpm_cmd_handler.c:3450: Debug: [TPM_TAG_RQU_COMMAND]
tpm_cmd_handler.c:3473: Debug: [TPM_ORD_Startup]
tpm_startup.c:43: Info: TPM_Startup(1)
tpm_cmd_handler.c:4077: Info: TPM command failed: (0x26) The command was received in the wrong sequence relative to TPM_Init and a subsequent TPM_Startup.
tpmd.c:491: Debug: sending 10 bytes
tpmd.c:452: Debug: waiting for commands...
tpmd.c:485: Debug: received 10 bytes
tpm_cmd_handler.c:4143: Debug: tpm_handle_command()
tpm_cmd_handler.c:3450: Debug: [TPM_TAG_RQU_COMMAND]
tpm_cmd_handler.c:3523: Debug: [TPM_ORD_SetTempDeactivated]
tpm_owner.c:74: Info: TPM_SetTempDeactivated()

Machine 2:
The current code, was also tested on kernel 4.2.0-16-generic (build directly from master version https://github.com/PeterHuewe/tpm-emulator):
Version: QEMU emulator version 2.3.0 (Debian 1:2.3+dfsg-5ubuntu9.2)

tpmd.c:523: Info: starting TPM Emulator daemon (1.2.0.7-475)
tpmd.c:102: Info: parsing options
tpmd.c:228: Info: installing signal handlers
tpmd.c:387: Info: staring main loop
tpmd.c:302: Info: initializing socket /var/run/tpm/tpmd_socket:0
tpm_emulator_extern.c:101: Info: _tpm_extern_init()
tpm_startup.c:29: Info: TPM_Init()
tpm_testing.c:243: Info: TPM_SelfTestFull()
tpm_testing.c:261: Info: Self-Test succeeded
tpm_startup.c:43: Info: TPM_Startup(1)
tpm_cmd_handler.c:4147: Error: tpm_unmarshal_TPM_REQUEST() failed
tpmd.c:489: Error: tpm_handle_command() failed
tpm_cmd_handler.c:4147: Error: tpm_unmarshal_TPM_REQUEST() failed
tpmd.c:489: Error: tpm_handle_command() failed

Machine 3:
Same code base (current master) runs perfectly fine on QEMU emulator version 2.4.94 with kernel 3.13.0-76-generic #120-Ubuntu SMP

If more info is needed, let me know.

[PeterHuewe]

@xrayn Hi - sorry I don't get the question/problem
Can you elaborate a bit more on what you are trying to do and what fails?
Can you re-active / re-enable the TPM?

Peter

[xrayn]

@PeterHuewe Hi Peter, sure I can elaborate. I simply want to use the TPM emulator on a Debian 9.0 system and forward the TPM to a qemu instance. After overcoming the compilation issues, by applying the mentioned patch, for some reason the TPM is decativated during start of qemu.

tpm_cmd_handler.c:4077: Info: TPM command failed: (0x26) The command was received in the wrong sequence relative to TPM_Init and a subsequent TPM_Startup....

Basically there are now two possibilities, either the patch does not work on a functional level, meaning it messes up the messages sent and received via the kernel module (tpm_dev), or something else is broken.

At this moment, I think the problem is not related to the kernel module, but related to linking the tpmd code to a recent OpenSSL version(Debian 9 uses OpenSSL 1.1 with changed API.). This suspicion doe not come out of the blue. For instance, I experienced also problems with Stefan Bergers code which is indeed related to OpenSSL (stefanberger/libtpms#7 (comment)). However, I did not have the time to test it properly for your tpm-emu code.
In addition to that, I experienced during development that there is a general problem with an incompatibility between trousers and OpenSSL 1.1. When I linked my development code against a "trousers (openssl1.1 linked)" lib, certain functions simply returned wrong results (in particular I could not extract an RSA_Key from a Quote structure.). Still, linking my code code to a "trousers (openssl 1.0 linked)" lib, suddenly worked as expected. (It has to be mentioned, that I mad these tests with a hardware tpm, since I was not able to get any TPM emulation working on that system.)

I know this has all very little to do with your TPM-emulator, yet my educated guess is that due to OpenSSL's API changes, all code utilizing OpenSSL functions either directly or indirectly through trousers, is shows strange behavior as soon as OpenSSL 1.1 is used. If I have some time this week, I will try to link kernel 4.9 patched TPM-emu code against OpenSLL 1.0. In case the TPM forwarding to qemu then works, the chances are pretty high that the patch did indeed work properly and the problems are related to OpenSSL incompatibility. In case I do not succeed with this, the chances are high the 4.9 patch does not work as expected. Anyway, as soon as I have some results I will let you know here.

Andre

[PeterHuewe]

Hi
tpm_cmd_handler.c:4077: Info: TPM command failed: (0x26) The command was received in the wrong sequence relative to TPM_Init and a subsequent TPM_Startup....
means that the device already has received a startup (not that it's deactivated) - nothing I would worry about.
Can you re-active / re-enable the TPM?

Do you think you can tryout the "old" code on an "old kernel"?
Thanks,
Peter

[xrayn]

Hi, so I tried to re-activate/re-enable with the corresponding commands multiple times. So basically tpmd decativated / clear ... But it did not make any change.

Indeed, the TPM device is availabel inside the VM, however, only certain command can be executed. E.g. tpm_version works, but tpm_takeownership fails (says TPM is deactivated).

Now I'm a little confused. What do you mean with "old code" on an "old kernel"?
Machine 1 test was master (patched with #21) (error)
Machine 2 test was master (unpatched) on 4.2 kernel. (error)
Machine 3 test was master (unpatched) on old 3.19 kernel. (works)

I suppose if you can give me the 'code' and 'kernel' version combination you mean, I can do a test.

[PeterHuewe]

Interesting that there seems to be a difference between 4.2 and 3.19.
Can you perhaps also try 4.0 and 4.1?
Always same qemu version?

Thanks,
Peter

[xrayn]

So, I did some testing. As it turns out, neither the kernel nor OpenSSL caused the issue.

The problem which is causing that the tpm gets deactivated, is due to a qemu bios image update introduced in 2.6 release (https://github.com/qemu/qemu/tree/stable-2.6).
If qemu, no matter which version after 2.4, is launched with the stable-2.6 bios (https://github.com/qemu/qemu/blob/stable-2.6/pc-bios/bios.bin), the TPM will get deactivated. In turn, launching qemu with the stable-2.5 bios (https://github.com/qemu/qemu/blob/stable-2.5/pc-bios/bios.bin)
qemu-system-x86_64 -bios bios.bin
works for all tested versions.
(Tested versions are every stable-2.4 to stable-2.8 and current master-2.9 branch)

As a workaround to support the stable-2.6 qemu bios, I simply removed the function that causes the temporary deactivation (https://github.com/PeterHuewe/tpm-emulator/blob/master/tpm/tpm_cmd_handler.c). I could not detect any weird behavior inside the VM after doing this. The tpm worked as expected with nor errors.

diff --git a/tpm/tpm_cmd_handler.c b/tpm/tpm_cmd_handler.c
index 288d1ce..103c622 100644
--- a/tpm/tpm_cmd_handler.c
+++ b/tpm/tpm_cmd_handler.c
@@ -3521,7 +3521,7 @@ void tpm_execute_command(TPM_REQUEST *req, TPM_RESPONSE *rsp)

     case TPM_ORD_SetTempDeactivated:
       debug("[TPM_ORD_SetTempDeactivated]");
-      res = execute_TPM_SetTempDeactivated(req, rsp);
+      //res = execute_TPM_SetTempDeactivated(req, rsp);
     break;

     case TPM_ORD_SetOperatorAuth:

Pleas note, this change requires a build without -Werror in CmakeLists.txt

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f362298..85de6cf 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -40,7 +40,7 @@ set(TPM_STORAGE_NAME "/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MA
 set(TPM_DEVICE_NAME "/dev/tpm")
 endif()
 configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in ${CMAKE_CURRENT_BINARY_DIR}/config.h)
-add_definitions(-Wall -Werror -Wno-unused-parameter -Wpointer-arith -Wcast-align -Wwrite-strings)
+add_definitions(-Wall -Wno-unused-parameter -Wpointer-arith -Wcast-align -Wwrite-strings)
 if("${CMAKE_SYSTEM}" MATCHES "Linux")
     add_definitions(-Wextra)
 endif()

In conclusion this means that the patches introduced by #21 are indeed working as expected.
I tested with kernels:
4.2.0-16-generic #19-Ubuntu SMP
4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u1

Moreover, qemu-bios from stable-2.5 (https://github.com/qemu/qemu/blob/stable-2.5/pc-bios/bios.bin) can be used for qemu for stable-2.4 up to current master builds. qemu-bios from 2.6 ((https://github.com/qemu/qemu/blob/stable-2.6/pc-bios/bios.bin) was only supported after applying listed patches. I suppose supporting the 2.6 bios will need an update somewhere in the code.

@PeterHuewe I hope this helps. If you need more information, please let me know.

Andre

[PeterHuewe]

Thanks for digging into this.
Should we raise this with qemu?

[xrayn]

Not sure, I have also a system that forwards a hardware TPM to qemu. This works fine with the both qemu versions, i.e. stable-2.5 and stable-2.6. Unfortunately I could not find any indication what actually changed between both versions. Still, ignoring the error results in a working emulator, so maybe accepting the different initialization steps is also a viable option.

[PeterHuewe]

@xrayn Is there any update on this? Is this fixed with newer qemu versions?

[xrayn]

@PeterHuewe Actually I did not follow up on this matter. :) If I find some time, I will have a look though.