Do we know if the TSS library works with Intel fTPM running under Linux (in our case, 64-bit Debian Stretch)?
We are looking at using an Intel NUC5i3RYH or similar - primarily because we think it can't possibly be as slow as a discrete TPM, which we find can take up to a minute-an-a-half to do createprimary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It sounds like we'll just have to take the plunge and buy one to try it out.
Regarding /dev/tpmrm0, I don't see this. I just see /dev/tpm0. We are using Debian Stretch (i.e. current stable). Would this be because this kernel feature is too new to be included in that Debian version?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My notes say the resource manager was in the 4.12 kernel, released 2 July 2017. I don't have the mapping between kernels and Debian versions.
The design is very nice in that the interface is identical. You can debug single user with /dev/tpm0, and it should work multiuser with /dev/tpmrm0 with no code change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To answer my own original question, the answer is no. Or at least not with any of the kernels on any of the distributions I have tried, which includes Ubuntu 18.04.
To answer my own original question, the answer is no. Or at least not with
any of the kernels on any of the distributions I have tried, which
includes Ubuntu 18.04.
I still don't know any reason that the TSS should not work with the Intel
TPM. It did work in 2015, except the TPM seemed to be SHA-1 only. The
TSS uses the standard TPM device driver interface.
The problem is the Linux device driver not the TSS library.
The Linux driver (in all kernels known to me at the time of writing) works with physical TPMs - that is with TPMs that are a device separate to the CPU chip, e.g. soldered onto the motherboard.
The problem comes with Intel's firmware TPM implementation, which does not use a separate physical TPM, but is a software implemention in a part of the CPU chip, isolated from what the OS can see, except via its "BIOS" interface.
The problem seems to be that the interface breaks Intel's own rules for mapping I/O into the address space, and this is what breaks the driver. More than that, I don't know (or understand). That's what I gathered from reading that long thread. There is a driver patch avaliable, but I haven't tried it myself (yet).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do we know if the TSS library works with Intel fTPM running under Linux (in our case, 64-bit Debian Stretch)?
We are looking at using an Intel NUC5i3RYH or similar - primarily because we think it can't possibly be as slow as a discrete TPM, which we find can take up to a minute-an-a-half to do createprimary.
The intent is that it should work. The TSS connects over the standard interface to /dev/tpm0 or /dev/tpmrm0, and I haven't heard of any problems.
If the Intel part uses a different, non-standard interface, I'm willing to add support if you have documentation and are willing to test it.
It sounds like we'll just have to take the plunge and buy one to try it out.
Regarding /dev/tpmrm0, I don't see this. I just see /dev/tpm0. We are using Debian Stretch (i.e. current stable). Would this be because this kernel feature is too new to be included in that Debian version?
My notes say the resource manager was in the 4.12 kernel, released 2 July 2017. I don't have the mapping between kernels and Debian versions.
The design is very nice in that the interface is identical. You can debug single user with /dev/tpm0, and it should work multiuser with /dev/tpmrm0 with no code change.
Debian Stretch says it's a 4.9 kernel
Then you don't get the kernel resource manager. /dev/tpm0 is one open() at a time. Can you use that for development and then hopefully upgrade?
To answer my own original question, the answer is no. Or at least not with any of the kernels on any of the distributions I have tried, which includes Ubuntu 18.04.
The reason is thrown about here: https://sourceforge.net/p/tpmdd/mailman/tpmdd-devel/thread/CB2C93A3-6F29-4511-8FDD-B29D98FA235C@gmail.com/
A patch people seem to think fixes the problem is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=422eac3f7deae34dbaffd08e03e27f37a5394a56
I don't know if this has made it into the mainline kernel.
--
Ken Goldman kgoldman@us.ibm.com
914-945-2415 (862-2415)
From: "Nigel Hathaway" nhathaway@users.sourceforge.net
To: "[ibmtpm20tss:discussion] "
general@discussion.ibmtpm20tss.p.re.sourceforge.net
Date: 04/27/2018 10:44 AM
Subject: [ibmtpm20tss:discussion] Intel fTPM and IBM TPM 2.0 TSS
To answer my own original question, the answer is no. Or at least not with
any of the kernels on any of the distributions I have tried, which
includes Ubuntu 18.04.
The reason is thrown about here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_tpmdd_mailman_tpmdd-2Ddevel_thread_CB2C93A3-2D6F29-2D4511-2D8FDD-2DB29D98FA235C-40gmail.com_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=8DmPKX1pHRXnfgjycaSqJOA78tNZZCnr18zE6_1nK9Q&s=y-tipw0JmMZTO2XzMl-bNMRmgDE2HzqX3PFSppE9Qsw&e=
This is a really long thread, and I don't know what you're referring to.
Can you be more specific?
A patch people seem to think fixes the problem is here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_commit_-3Fid-3D422eac3f7deae34dbaffd08e03e27f37a5394a56&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=8DmPKX1pHRXnfgjycaSqJOA78tNZZCnr18zE6_1nK9Q&s=JJiSiHS8bvTke7HkTggE6ozEo1h0n1LWOE0hv8hbxdY&e=
I don't know if this has made it into the mainline kernel.
Remember that I support 100's of users, and I don't have the context for
your specific issue.
Intel fTPM and IBM TPM 2.0 TSS
I still don't know any reason that the TSS should not work with the Intel
TPM. It did work in 2015, except the TPM seemed to be SHA-1 only. The
TSS uses the standard TPM device driver interface.
Sent from sourceforge.net because you indicated interest in <
https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_ibmtpm20tss_discussion_general_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=8DmPKX1pHRXnfgjycaSqJOA78tNZZCnr18zE6_1nK9Q&s=qfzCAk3UnAixbrAsW0uhBXjta993W4eO06s79uCXo_g&e=
To unsubscribe from further messages, please visit <
https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_auth_subscriptions_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=8DmPKX1pHRXnfgjycaSqJOA78tNZZCnr18zE6_1nK9Q&s=R1195fYHriPR0eFxNlBS0mKnJjEaFJ-8KslRd5RMzT4&e=
The problem is the Linux device driver not the TSS library.
The Linux driver (in all kernels known to me at the time of writing) works with physical TPMs - that is with TPMs that are a device separate to the CPU chip, e.g. soldered onto the motherboard.
The problem comes with Intel's firmware TPM implementation, which does not use a separate physical TPM, but is a software implemention in a part of the CPU chip, isolated from what the OS can see, except via its "BIOS" interface.
The problem seems to be that the interface breaks Intel's own rules for mapping I/O into the address space, and this is what breaks the driver. More than that, I don't know (or understand). That's what I gathered from reading that long thread. There is a driver patch avaliable, but I haven't tried it myself (yet).