diff for duplicates of <1521048306.4508.56.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index a0e2d23..f2f75a2 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -11,29 +11,29 @@ On Wed, 2018-03-14 at 13:08 -0400, Mimi Zohar wrote: I don't believe it does, see below. -> Grub, to the best of my knowledge, is not interested in having -> anything to do with TPM based measurements. Many attempts have been +> ?Grub, to the best of my knowledge, is not interested in having +> anything to do with TPM based measurements. ?Many attempts have been > made to upstream trusted boot patches, but none have been accepted. Just for the sake of accuracy, even though it has nothing to do with the current proposal, grub does actually measure the booting -components. It does this via a shim protocol trick, so when grub +components. ?It does this via a shim protocol trick, so when grub passes the kernel to shim to verify the signature, shim also stores its measurement in the TPM boot log. -> Any support would need to piggyback on the callback hooks introduced +> ?Any support would need to piggyback on the callback hooks introduced > for secure boot and then be carried by the distros. Right, that's how it does actually work today. This is more or less what made me think of the compromise: the way shim -does measurements is using the EFI TPM protocol. Although this is +does measurements is using the EFI TPM protocol. ?Although this is technically a boot time UEFI driver, we can make it serve us until we're ready to load the real TPM driver, so we could write measurements to a PCR without any kernel drivers loaded. > As for Linux based boot loaders, the driver needs to be builtin for -> these measurements. So this wouldn't help you. +> these measurements. ?So this wouldn't help you. > > > > > That way IMA would have no dependency on any built in TPM driver @@ -41,12 +41,12 @@ to a PCR without any kernel drivers loaded. > > Adding additional support for post IMA-initialization for TPM's built > as kernel modules is clearly not optimal for all of the reasons -> provided to now and will be confusing, but could be supported. This +> provided to now and will be confusing, but could be supported. ?This > delayed loading of the TPM needs to be clearly indicated in both the > audit log and in IMA's measurement list. -Why if the measurement chain isn't broken? The way I'm thinking of -implementing it, IMA wouldn't even know. What would happen is that a +Why if the measurement chain isn't broken? ?The way I'm thinking of +implementing it, IMA wouldn't even know. ?What would happen is that a NULL tpm chip in tpm_pcr_read/tpm_pcr_extend would trigger the usual search for the first TPM but if none were found and we'd booted on an EFI system, we'd just use the EFI driver to do perform the operation. @@ -67,4 +67,9 @@ James > IMA-measurement initialization. > > Mimi -> +> + +-- +To unsubscribe from this list: send the line "unsubscribe linux-security-module" in +the body of a message to majordomo at vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index e1bc760..68815d1 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -14,23 +14,10 @@ "ref\0BCA04D5D9A3B764C9B7405BBA4D4A3C002367FEF@ALPMBAPA12.e2k.ad.ge.com\0" "ref\01521038471.4508.25.camel@HansenPartnership.com\0" "ref\01521047286.3547.470.camel@linux.vnet.ibm.com\0" - "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" - "Subject\0Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64\0" + "From\0James.Bottomley@hansenpartnership.com (James Bottomley)\0" + "Subject\0[PATCH] security: Fix IMA Kconfig for dependencies on ARM64\0" "Date\0Wed, 14 Mar 2018 10:25:06 -0700\0" - "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>" - Safford - David (GE Global Research - US) <david.safford@ge.com> - Jiandi An <anjiandi@codeaurora.org> - " Jason Gunthorpe <jgg@ziepe.ca>\0" - "Cc\0dmitry.kasatkin@gmail.com <dmitry.kasatkin@gmail.com>" - jmorris@namei.org <jmorris@namei.org> - serge@hallyn.com <serge@hallyn.com> - linux-integrity@vger.kernel.org <linux-integrity@vger.kernel.org> - linux-ima-devel@lists.sourceforge.net <linux-ima-devel@lists.sourceforge.net> - linux-ima-user@lists.sourceforge.net <linux-ima-user@lists.sourceforge.net> - linux-security-module@vger.kernel.org <linux-security-module@vger.kernel.org> - " linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Wed, 2018-03-14 at 13:08 -0400, Mimi Zohar wrote:\n" @@ -46,29 +33,29 @@ "\n" "I don't believe it does, see below.\n" "\n" - "> Grub, to the best of my knowledge, is not interested in having\n" - "> anything to do with TPM based measurements. Many attempts have been\n" + "> ?Grub, to the best of my knowledge, is not interested in having\n" + "> anything to do with TPM based measurements. ?Many attempts have been\n" "> made to upstream trusted boot patches, but none have been accepted. \n" "\n" "Just for the sake of accuracy, even though it has nothing to do with\n" "the current proposal, grub does actually measure the booting\n" - "components. It does this via a shim protocol trick, so when grub\n" + "components. ?It does this via a shim protocol trick, so when grub\n" "passes the kernel to shim to verify the signature, shim also stores its\n" "measurement in the TPM boot log.\n" "\n" - "> Any support would need to piggyback on the callback hooks introduced\n" + "> ?Any support would need to piggyback on the callback hooks introduced\n" "> for secure boot and then be carried by the distros.\n" "\n" "Right, that's how it does actually work today.\n" "\n" "This is more or less what made me think of the compromise: the way shim\n" - "does measurements is using the EFI TPM protocol. Although this is\n" + "does measurements is using the EFI TPM protocol. ?Although this is\n" "technically a boot time UEFI driver, we can make it serve us until\n" "we're ready to load the real TPM driver, so we could write measurements\n" "to a PCR without any kernel drivers loaded.\n" "\n" "> As for Linux based boot loaders, the driver needs to be builtin for\n" - "> these measurements. So this wouldn't help you.\n" + "> these measurements. ?So this wouldn't help you.\n" "> \n" "> > \n" "> > That way IMA would have no dependency on any built in TPM driver\n" @@ -76,12 +63,12 @@ "> \n" "> Adding additional support for post IMA-initialization for TPM's built\n" "> as kernel modules is clearly not optimal for all of the reasons\n" - "> provided to now and will be confusing, but could be supported. This\n" + "> provided to now and will be confusing, but could be supported. ?This\n" "> delayed loading of the TPM needs to be clearly indicated in both the\n" "> audit log and in IMA's measurement list.\n" "\n" - "Why if the measurement chain isn't broken? The way I'm thinking of\n" - "implementing it, IMA wouldn't even know. What would happen is that a\n" + "Why if the measurement chain isn't broken? ?The way I'm thinking of\n" + "implementing it, IMA wouldn't even know. ?What would happen is that a\n" "NULL tpm chip in tpm_pcr_read/tpm_pcr_extend would trigger the usual\n" "search for the first TPM but if none were found and we'd booted on an\n" "EFI system, we'd just use the EFI driver to do perform the operation.\n" @@ -102,6 +89,11 @@ "> IMA-measurement initialization.\n" "> \n" "> Mimi\n" - > + "> \n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" + "the body of a message to majordomo at vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -afed6682b865db0e37f333520f98073e964d755c4ac22c1bd30752a27384fdc2 +3cc875bfb72752659ff4557e229f5e73175fa79bd6aaa801d4b7d3d835b1704f
diff --git a/a/1.txt b/N2/1.txt index a0e2d23..bf6cf43 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -11,29 +11,29 @@ On Wed, 2018-03-14 at 13:08 -0400, Mimi Zohar wrote: I don't believe it does, see below. -> Grub, to the best of my knowledge, is not interested in having -> anything to do with TPM based measurements. Many attempts have been +> Grub, to the best of my knowledge, is not interested in having +> anything to do with TPM based measurements. Many attempts have been > made to upstream trusted boot patches, but none have been accepted. Just for the sake of accuracy, even though it has nothing to do with the current proposal, grub does actually measure the booting -components. It does this via a shim protocol trick, so when grub +components. It does this via a shim protocol trick, so when grub passes the kernel to shim to verify the signature, shim also stores its measurement in the TPM boot log. -> Any support would need to piggyback on the callback hooks introduced +> Any support would need to piggyback on the callback hooks introduced > for secure boot and then be carried by the distros. Right, that's how it does actually work today. This is more or less what made me think of the compromise: the way shim -does measurements is using the EFI TPM protocol. Although this is +does measurements is using the EFI TPM protocol. Although this is technically a boot time UEFI driver, we can make it serve us until we're ready to load the real TPM driver, so we could write measurements to a PCR without any kernel drivers loaded. > As for Linux based boot loaders, the driver needs to be builtin for -> these measurements. So this wouldn't help you. +> these measurements. So this wouldn't help you. > > > > > That way IMA would have no dependency on any built in TPM driver @@ -41,12 +41,12 @@ to a PCR without any kernel drivers loaded. > > Adding additional support for post IMA-initialization for TPM's built > as kernel modules is clearly not optimal for all of the reasons -> provided to now and will be confusing, but could be supported. This +> provided to now and will be confusing, but could be supported. This > delayed loading of the TPM needs to be clearly indicated in both the > audit log and in IMA's measurement list. -Why if the measurement chain isn't broken? The way I'm thinking of -implementing it, IMA wouldn't even know. What would happen is that a +Why if the measurement chain isn't broken? The way I'm thinking of +implementing it, IMA wouldn't even know. What would happen is that a NULL tpm chip in tpm_pcr_read/tpm_pcr_extend would trigger the usual search for the first TPM but if none were found and we'd booted on an EFI system, we'd just use the EFI driver to do perform the operation. diff --git a/a/content_digest b/N2/content_digest index e1bc760..be967a7 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -46,29 +46,29 @@ "\n" "I don't believe it does, see below.\n" "\n" - "> Grub, to the best of my knowledge, is not interested in having\n" - "> anything to do with TPM based measurements. Many attempts have been\n" + "> \302\240Grub, to the best of my knowledge, is not interested in having\n" + "> anything to do with TPM based measurements. \302\240Many attempts have been\n" "> made to upstream trusted boot patches, but none have been accepted. \n" "\n" "Just for the sake of accuracy, even though it has nothing to do with\n" "the current proposal, grub does actually measure the booting\n" - "components. It does this via a shim protocol trick, so when grub\n" + "components. \302\240It does this via a shim protocol trick, so when grub\n" "passes the kernel to shim to verify the signature, shim also stores its\n" "measurement in the TPM boot log.\n" "\n" - "> Any support would need to piggyback on the callback hooks introduced\n" + "> \302\240Any support would need to piggyback on the callback hooks introduced\n" "> for secure boot and then be carried by the distros.\n" "\n" "Right, that's how it does actually work today.\n" "\n" "This is more or less what made me think of the compromise: the way shim\n" - "does measurements is using the EFI TPM protocol. Although this is\n" + "does measurements is using the EFI TPM protocol. \302\240Although this is\n" "technically a boot time UEFI driver, we can make it serve us until\n" "we're ready to load the real TPM driver, so we could write measurements\n" "to a PCR without any kernel drivers loaded.\n" "\n" "> As for Linux based boot loaders, the driver needs to be builtin for\n" - "> these measurements. So this wouldn't help you.\n" + "> these measurements. \302\240So this wouldn't help you.\n" "> \n" "> > \n" "> > That way IMA would have no dependency on any built in TPM driver\n" @@ -76,12 +76,12 @@ "> \n" "> Adding additional support for post IMA-initialization for TPM's built\n" "> as kernel modules is clearly not optimal for all of the reasons\n" - "> provided to now and will be confusing, but could be supported. This\n" + "> provided to now and will be confusing, but could be supported. \302\240This\n" "> delayed loading of the TPM needs to be clearly indicated in both the\n" "> audit log and in IMA's measurement list.\n" "\n" - "Why if the measurement chain isn't broken? The way I'm thinking of\n" - "implementing it, IMA wouldn't even know. What would happen is that a\n" + "Why if the measurement chain isn't broken? \302\240The way I'm thinking of\n" + "implementing it, IMA wouldn't even know. \302\240What would happen is that a\n" "NULL tpm chip in tpm_pcr_read/tpm_pcr_extend would trigger the usual\n" "search for the first TPM but if none were found and we'd booted on an\n" "EFI system, we'd just use the EFI driver to do perform the operation.\n" @@ -104,4 +104,4 @@ "> Mimi\n" > -afed6682b865db0e37f333520f98073e964d755c4ac22c1bd30752a27384fdc2 +980c3018ed8e8c375a799950d93ba044b7d6ccb2259b2de64b7299eee8e64fc1
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.