Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch
On 9/25/20 1:43 AM, Jarkko Sakkinen wrote: > On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote: >> From: "Daniel P. Smith" >> >> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices >> above the TPM hardware interface. >> >> Signed-off-by: Daniel P. Smith >> Signed-off-by: Ross Philipson > > This is way, way too PoC. I wonder why there is no RFC tag. > > Please also read section 2 of > > https://www.kernel.org/doc/html/v5.8/process/submitting-patches.html > > You should leverage existing TPM code in a way or another. Refine it so > that it scales for your purpose and then compile it into your thing > (just include the necesary C-files with relative paths). > > How it is now is never going to fly. > > /Jarkko > After attempts to engage in finding alternative approaches, it appears that the only welcomed approach for sending measurements from the compressed kernel would be a major rewrite of the mainline TPM driver to: 1. Abstract out the mainline kernel infrastructure that is used by the driver 2. Find ways to introduce a minimal amount of the equivalent infrastructure into the compressed kernel, to make the driver code reusable within the compressed kernel. This approach would exceed the scope of changes we want to introduce to non-SecureLaunch code to enable direct DRTM launch for the Linux kernel. After careful consideration and discussions with colleagues from the trusted computing community, an alternative has been crafted. We aim to submit a version 2 with the following approach: 1. SecureLaunch will take measurements in the compressed kernel as we do in version 1, but instead of immediately sending them to the TPM, they will be stored in the DRTM TPM event log. 2. When the SecureLaunch module in the mainline kernel comes on line, it can send measurements to the TPM using the mainline TPM driver. While it would be ideal to record measurements at the time they are taken, the mainline kernel is measured alongside the compressed kernel as a single measurement. This means the same measured entity stays in control, prior to execution by any other entity within the system. At a later date, if the TPM maintainers refactor the TPM driver for reuse within the compressed kernel, then the sending of measurements can be revisited. For individuals and distributions that may prefer to record DRTM measurements earlier, the TrenchBoot project will do its best to maintain an external patch to provide that capability to a mainline LTS kernel. V/r, Daniel P. Smith ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch
On Wed, Sep 30, 2020 at 06:19:57AM +0300, Jarkko Sakkinen wrote: > On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote: > > TrenchBoot's AMD Secure Loader (LZ). The former is not well supported > > and the latter will be getting maintenance under TB. While this is not > > preferred, we had to weigh this versus trying to convince you and the > > other TPM driver maintainers on a significant refactoring of the TPM > > driver. It was elected for the reuse of a clean implementation that can > > be replaced later if/when the TPM driver was refactored. When we > > explained this during the RFC and it was not rejected, therefore we > > carried it forward into this submission. > > What does it anyway mean when you say "RFC was not rejected"? I don't > get the semantics of that sentence. It probably neither was ack'd, > right? I do not really care what happened with the RFC. All I can say > is that in the current state this totally PoC from top to bottom. > > > > How it is now is never going to fly. > > > > We would gladly work with you and the other TPM maintainers on a > > refactoring of the TPM driver to separate core logic into standalone > > files that both the driver and the compressed kernel can share. > > Yes, exactly. You have to refactor out the common parts. This is way too > big patch to spend time on giving any more specific advice. Should be in > way smaller chunks. For (almost) any possible, this is of unacceptable ^ " patch" > size. > > I think that it'd be best first to keep the common files in > drivers/char/tpm and include them your code with relative paths in the > Makefile. At least up until we have clear view what are the common > parts. > > You might also want to refactor drivers/char/tpm/tpm.h and include/linux > TPM headers to move more stuff into include/linux. > > If you are expecting a quick upstreaming process, please do not. This > will take considerable amount of time to get right. /Jarkko ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch
On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote: > TrenchBoot's AMD Secure Loader (LZ). The former is not well supported > and the latter will be getting maintenance under TB. While this is not > preferred, we had to weigh this versus trying to convince you and the > other TPM driver maintainers on a significant refactoring of the TPM > driver. It was elected for the reuse of a clean implementation that can > be replaced later if/when the TPM driver was refactored. When we > explained this during the RFC and it was not rejected, therefore we > carried it forward into this submission. What does it anyway mean when you say "RFC was not rejected"? I don't get the semantics of that sentence. It probably neither was ack'd, right? I do not really care what happened with the RFC. All I can say is that in the current state this totally PoC from top to bottom. > > How it is now is never going to fly. > > We would gladly work with you and the other TPM maintainers on a > refactoring of the TPM driver to separate core logic into standalone > files that both the driver and the compressed kernel can share. Yes, exactly. You have to refactor out the common parts. This is way too big patch to spend time on giving any more specific advice. Should be in way smaller chunks. For (almost) any possible, this is of unacceptable size. I think that it'd be best first to keep the common files in drivers/char/tpm and include them your code with relative paths in the Makefile. At least up until we have clear view what are the common parts. You might also want to refactor drivers/char/tpm/tpm.h and include/linux TPM headers to move more stuff into include/linux. If you are expecting a quick upstreaming process, please do not. This will take considerable amount of time to get right. /Jarkko ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch
On 9/25/20 1:43 AM, Jarkko Sakkinen wrote: > On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote: >> From: "Daniel P. Smith" >> >> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices >> above the TPM hardware interface. >> >> Signed-off-by: Daniel P. Smith >> Signed-off-by: Ross Philipson > > This is way, way too PoC. I wonder why there is no RFC tag. An RFC was sent back in March and we incorporated the feedback we received at that time. > Please also read section 2 of > > https://www.kernel.org/doc/html/v5.8/process/submitting-patches.html > > You should leverage existing TPM code in a way or another. Refine it so > that it scales for your purpose and then compile it into your thing > (just include the necesary C-files with relative paths). We explained during the RFC phase that we took a fair bit of time and a very hard look to see if we could #include sections out the TPM driver but as it is today none of the TPM driver's c files can be included outside of the mainline kernel. If you look at the early boot stub for the compressed kernel you will see that we are interacting with the TPM as the first thing upon leaving the assembly world and entering C. Since we weren't going to be able to get the mainline TPM driver plucked down, we could either 1.) borrow an implementation from a colleague that provides the minimum command strings hard coded in C macros to send measurements to the TPM or 2.) reuse the TPM implementation we wrote for TrenchBoot's AMD Secure Loader (LZ). The former is not well supported and the latter will be getting maintenance under TB. While this is not preferred, we had to weigh this versus trying to convince you and the other TPM driver maintainers on a significant refactoring of the TPM driver. It was elected for the reuse of a clean implementation that can be replaced later if/when the TPM driver was refactored. When we explained this during the RFC and it was not rejected, therefore we carried it forward into this submission. > How it is now is never going to fly. We would gladly work with you and the other TPM maintainers on a refactoring of the TPM driver to separate core logic into standalone files that both the driver and the compressed kernel can share. > /Jarkko > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch
On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote: > From: "Daniel P. Smith" > > This commit introduces an abstraction for TPM1.2 and TPM2.0 devices > above the TPM hardware interface. > > Signed-off-by: Daniel P. Smith > Signed-off-by: Ross Philipson This is way, way too PoC. I wonder why there is no RFC tag. Please also read section 2 of https://www.kernel.org/doc/html/v5.8/process/submitting-patches.html You should leverage existing TPM code in a way or another. Refine it so that it scales for your purpose and then compile it into your thing (just include the necesary C-files with relative paths). How it is now is never going to fly. /Jarkko ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
