Closed liuqun closed 6 years ago
It seems that my hardware TPM refuses to execute the deprecated command and returns TPM_RC 0x0143 to me.
tpm2_encryptdecrypt won't work on my TPM. For example:
sudo tpm2_encryptdecrypt -k 0x81010001 -P abc123 -D NO -I a.txt -o b.txt
ERROR: EncryptDecrypt failed, error code: 0x143
/usr/local/sbin/tpm2_rc_decode 0x143
error layer
hex: 0x0
identifier: TSS2_TPM_ERROR_LEVEL
description: Error produced by the TPM
format 0 error code
hex: 0x43
name: TPM_RC_COMMAND_CODE
description: command code not supported
commandIndex 0x0164 is not available for this TPM2.0 chip:
sudo tpm2_dump_capability -c commands
TPMA_CC: 0x02000163
commandIndex: 0x163
reserved1: 0x0
nv: clear
extensive: clear
flushed: clear
cHandles: 0x1
rHandle: clear
V: clear
Res: 0x0
TPMA_CC: 0x00000165
commandIndex: 0x165
reserved1: 0x0
nv: clear
extensive: clear
flushed: clear
cHandles: 0x0
rHandle: clear
V: clear
Res: 0x0
TPM 2.0 Command Code TPM_CC_EncryptDecrypt2 should be 0x00000193 (TPM_CC_EncryptDecrypt is 0x00000164)
#define TPM_CC_EncryptDecrypt (TPM_CC)(0x00000164)
Queuing this one up for the next minor release ...
@tstruk @flihp Any luck on getting this done soon?
The way things are going I think this would be the only change that went into a minor release if we did one. It'll definitely be in the 2.0 release but that's still months away. I think the difference between these two commands is pretty small (one parameter moved) so this could be a small task but I'm hesitant to use that as an estimate till I've looked at it a bit.
What are you thinking @williamcroberts? Do you want to port the tools over to this new command and line up a release behind it? That's a good way to motivate the work.
It'll definitely be in the 2.0 release but that's still months away.
@flihp that means that we won't be able to do a new major release of the tpm2-tools for months either, since as I mentioned in the mailing list, tpm2-tools master fails to build with the tpm2-tss 1.x branch.
@williamcroberts what's your plan for that? Maybe we can cut a 3.x branch and do a fixup there to allow the tools to be built with the tpm2-tss 1.x branch?
Also, I believe we should do this change in tpm2-tools (if you agree I can do a formal PR proposal):
diff --git a/configure.ac b/configure.ac
index aa1f68d9ce45..f22cf571f4c3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -12,7 +12,7 @@ AS_IF(
[],
[AC_MSG_WARN([Required executable pandoc not found, man pages will not be built])])
AM_CONDITIONAL([HAVE_PANDOC],[test "x${PANDOC}" = "xyes"])
-PKG_CHECK_MODULES([SAPI],[sapi])
+PKG_CHECK_MODULES([SAPI],[sapi >= 2.0])
# disable libtcti-device selectively (enabled by default)
AC_ARG_WITH(
[tcti-device],
PKG_CHECK_MODULES([SAPI],[sapi >= 1.9])
">=1.9" should work for me now since the sapi-2.0 version is going to be released months later.
@martinezjavier Yes if we need to do that for 3.0 we can fork off master and edit to use an older version of tss. However, I need to hit all those next milestone features first.
@liuqun I understood @martinezjavier change to be suggested on master, which is being built against tss master, which is being built with: -DVERSION="2.0.0-dev"
@martinezjavier we should take that change to package config. If your at it, maybe add checks for all those missing dependencies in configure? https://github.com/01org/tpm2-tools/issues/450
@williamcroberts I see, I (mis)understood from our last conversation what we where near to a next release (IIRC you mentioned the end of October). There are 24 issues with a "next" milestone, so I guess it will take some time to finish those.
Are you planning to start wrapping up in preparation for the next release (i.e: not labeling any new issue for next until the release)? Otherwise I feel that we keep piling up stuff and getting a next release gets harder.
That's why I always prefer a time based release model instead of a feature based one, but that's a different conversation :smiley:
@martinezjavier Nothing new will be added to next without dropping something. Normally I would be all about time based, but since there is a lot of non-backwards compatible things, id like to get as many of those in as possible.
This ticket will likely need to be dropped as this is not supported in the TSS as of yet.
@williamcroberts yep, agreed. Ok, I'll help closing the pending issues then so we can finally do a new release.
Didn't want to make any promises about getting this in since I'm traveling this week but after hours I managed to get an implementation working. I'll start backporting this to the 1.x branch. Shouldn't take more than a few hours. Should be able to have it done by the end of the week.
@williamcroberts : If we can get the timing right we may want to switch the tools over to use this new function in the tpm2_encryptdecrypt
command. Thoughts?
@flihp agreed
Great. Imma start backporting this tonight.
What is the current status of this? Compiling tools-30-rc2 against TSS 1.3.0 still results in the following compilation errors:
tools/tpm2_encryptdecrypt.o: In function encrypt_decrypt': /home/ioliver/code/tpm2/tpm2-tools-3.0-rc2/tools/tpm2_encryptdecrypt.c:104: undefined reference to
Tss2_Sys_EncryptDecrypt2'
collect2: error: ld returned 1 exit status
Makefile:1592: recipe for target 'tools/tpm2_encryptdecrypt' failed
make: *** [tools/tpm2_encryptdecrypt] Error 1
@iolivergithub are you sure you are building against the correct tpm2-tss version?
Tss2_Sys_EncryptDecrypt2() is definitely implemented in tpm2-tss version 1.3.0.
Solution...
(nb: yes, I can see the function being defined in tpm2-tss 1.3.0)
This might be specific to Ubuntu 17.04 but despite the libraries being correctly installed, LD_LIBRARY_PATH set, the various paths in /etc/ld.conf.d compiling tools requires export LDFLAGS='-L/usr/local/lib' before running ./configure otherwise the above function is not found.
UPDATE: and after all that the TPM doesn't support encryptdecrypt ...
@iolivergithub what does the following command say for you?
$ pkg-config --modversion sapi
My guess is that you have two sapi.pc pkg-config files in pkg-config's search path and so the configure script gets confused and picks the wrong one. And that's why you have to explicitly set linker flags.
So I would check that and remove the files for the old tpm2-tss installation if that's the case.
BTW, why are you building 3.0-rc2 instead of the final release? There's a fix in tpm2-tools to check for sapi >= 1.3.0 sapi < 2.0.0
instead of just sapi < 2.0.0
. That would had caught your issue at configure instead of at linker time.
$pkg-config --modversion sapi
returns nothing
Have had conflicting advice about the versions hence using the release candidates. However see the update above. Encyrptdecrypt is not enabled on the TPM I have from Infineon/Lenovo thus making this little more than an academic exercise.
returns nothing
Interesting, empty is sapi < 2.0.0 so your configure script didn't fail. I wonder why is empty thought.
Encyrptdecrypt is not enabled on the TPM I have from Infineon/Lenovo thus making this little more
Encyrptdecrypt or Encyrptdecrypt2?
AFAIK the Infineon TPMs do not support EncryptDecrypt
(deprecated), only the newer EncryptDecrypt2
. This was the whole reason for implementing the newer command in this last release. Since the newer command is implemented in the latest release and this issue seems to be related to an installation error I'm going to close the issue and ask that a new one be opened specific to the installation issue being seen.
See: TPM Rev 2.0 Part 3: Commands https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-3-Commands-01.38.pdf
In Chapter 15, they say: