diff for duplicates of <1521133728.5348.51.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 98d1d3c..e15dbc3 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -8,10 +8,10 @@ On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > > > 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 delayed loading of the TPM needs to be clearly +> > > 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 +> > Why if the measurement chain isn't broken? ?The way I'm thinking of > > implementing it, IMA wouldn't even know. > > I'm not sure this is good news. @@ -25,18 +25,18 @@ On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > If EFI is extending the TPM, will the events be added to the TPM > event log or to the IMA measurement list? -I'm not proposing any changes to the tpm_pcr_extend API. At the moment +I'm not proposing any changes to the tpm_pcr_extend API. ?At the moment it does an extend without logging, so that's what it will do in the EFI -driver case as well. That means logging is still the responsibility of +driver case as well. ?That means logging is still the responsibility of the caller. -> Up to now the IMA boot aggregate record includes PCRs from 0 - 7. -> With these PCRs, the boot aggregate wouldn't change when booting the -> same kernel. Would you change the boot-aggregate to include these +> ? Up to now the IMA boot aggregate record includes PCRs from 0 - 7. +> ?With these PCRs, the boot aggregate wouldn't change when booting the +> same kernel. ?Would you change the boot-aggregate to include these > other PCRs? -This is all IMA internal stuff that's up to you. All I would do is -make the tpm_pcr API work with an EFI driver. That has no impact on +This is all IMA internal stuff that's up to you. ?All I would do is +make the tpm_pcr API work with an EFI driver. ?That has no impact on what the PCRs return (well, unless we start using it to log early components of the kernel boot, which is a possibility). @@ -52,9 +52,14 @@ components of the kernel boot, which is a possibility). > What happens for non EFI systems, when you can't extend the TPM? The same as happens today if there's no TPM available: you'd get an -error return. Since older bios is essentially legacy, I wouldn't +error return. ?Since older bios is essentially legacy, I wouldn't propose fixing this, but the TCG does define a non-EFI BIOS interface which could theoretically be used in the same way as the BIOS one if someone with a legacy box were interested in implementing it. James + +-- +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 db95490..9da8a26 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -16,21 +16,10 @@ "ref\01521047286.3547.470.camel@linux.vnet.ibm.com\0" "ref\01521048306.4508.56.camel@HansenPartnership.com\0" "ref\01521130749.3547.608.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\0Thu, 15 Mar 2018 10:08:48 -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-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 Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote:\n" @@ -43,10 +32,10 @@ "> > > Adding additional support for post IMA-initialization for TPM's\n" "> > > built as kernel modules is clearly not optimal for all of the\n" "> > > reasons provided to now and will be confusing, but could be\n" - "> > > supported. This delayed loading of the TPM needs to be clearly\n" + "> > > supported. ?This delayed loading of the TPM needs to be clearly\n" "> > > indicated in both the 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" + "> > Why if the measurement chain isn't broken? ?The way I'm thinking of\n" "> > implementing it, IMA wouldn't even know.\n" "> \n" "> I'm not sure this is good news.\n" @@ -60,18 +49,18 @@ "> If EFI is extending the TPM, will the events be added to the TPM\n" "> event log or to the IMA measurement list?\n" "\n" - "I'm not proposing any changes to the tpm_pcr_extend API. At the moment\n" + "I'm not proposing any changes to the tpm_pcr_extend API. ?At the moment\n" "it does an extend without logging, so that's what it will do in the EFI\n" - "driver case as well. That means logging is still the responsibility of\n" + "driver case as well. ?That means logging is still the responsibility of\n" "the caller.\n" "\n" - "> Up to now the IMA boot aggregate record includes PCRs from 0 - 7.\n" - "> With these PCRs, the boot aggregate wouldn't change when booting the\n" - "> same kernel. Would you change the boot-aggregate to include these\n" + "> ? Up to now the IMA boot aggregate record includes PCRs from 0 - 7.\n" + "> ?With these PCRs, the boot aggregate wouldn't change when booting the\n" + "> same kernel. ?Would you change the boot-aggregate to include these\n" "> other PCRs?\n" "\n" - "This is all IMA internal stuff that's up to you. All I would do is\n" - "make the tpm_pcr API work with an EFI driver. That has no impact on\n" + "This is all IMA internal stuff that's up to you. ?All I would do is\n" + "make the tpm_pcr API work with an EFI driver. ?That has no impact on\n" "what the PCRs return (well, unless we start using it to log early\n" "components of the kernel boot, which is a possibility).\n" "\n" @@ -87,11 +76,16 @@ "> What happens for non EFI systems, when you can't extend the TPM?\n" "\n" "The same as happens today if there's no TPM available: you'd get an\n" - "error return. Since older bios is essentially legacy, I wouldn't\n" + "error return. ?Since older bios is essentially legacy, I wouldn't\n" "propose fixing this, but the TCG does define a non-EFI BIOS interface\n" "which could theoretically be used in the same way as the BIOS one if\n" "someone with a legacy box were interested in implementing it.\n" "\n" - James + "James\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 -23ed0a6c511d2ca3028494bae2de2f22c6c137ab99e13b1cc82d0eaf23f9d974 +759f16e9d5d60960d6681d77758a0fc754769f64002add26a59cf4c4181f4239
diff --git a/a/1.txt b/N2/1.txt index 98d1d3c..63c9a15 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -8,10 +8,10 @@ On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > > > 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 delayed loading of the TPM needs to be clearly +> > > 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 +> > Why if the measurement chain isn't broken? The way I'm thinking of > > implementing it, IMA wouldn't even know. > > I'm not sure this is good news. @@ -25,18 +25,18 @@ On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > If EFI is extending the TPM, will the events be added to the TPM > event log or to the IMA measurement list? -I'm not proposing any changes to the tpm_pcr_extend API. At the moment +I'm not proposing any changes to the tpm_pcr_extend API. At the moment it does an extend without logging, so that's what it will do in the EFI -driver case as well. That means logging is still the responsibility of +driver case as well. That means logging is still the responsibility of the caller. -> Up to now the IMA boot aggregate record includes PCRs from 0 - 7. -> With these PCRs, the boot aggregate wouldn't change when booting the -> same kernel. Would you change the boot-aggregate to include these +> Up to now the IMA boot aggregate record includes PCRs from 0 - 7. +> With these PCRs, the boot aggregate wouldn't change when booting the +> same kernel. Would you change the boot-aggregate to include these > other PCRs? -This is all IMA internal stuff that's up to you. All I would do is -make the tpm_pcr API work with an EFI driver. That has no impact on +This is all IMA internal stuff that's up to you. All I would do is +make the tpm_pcr API work with an EFI driver. That has no impact on what the PCRs return (well, unless we start using it to log early components of the kernel boot, which is a possibility). @@ -52,7 +52,7 @@ components of the kernel boot, which is a possibility). > What happens for non EFI systems, when you can't extend the TPM? The same as happens today if there's no TPM available: you'd get an -error return. Since older bios is essentially legacy, I wouldn't +error return. Since older bios is essentially legacy, I wouldn't propose fixing this, but the TCG does define a non-EFI BIOS interface which could theoretically be used in the same way as the BIOS one if someone with a legacy box were interested in implementing it. diff --git a/a/content_digest b/N2/content_digest index db95490..cef3166 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -43,10 +43,10 @@ "> > > Adding additional support for post IMA-initialization for TPM's\n" "> > > built as kernel modules is clearly not optimal for all of the\n" "> > > reasons provided to now and will be confusing, but could be\n" - "> > > supported. This delayed loading of the TPM needs to be clearly\n" + "> > > supported. \302\240This delayed loading of the TPM needs to be clearly\n" "> > > indicated in both the 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" + "> > Why if the measurement chain isn't broken? \302\240The way I'm thinking of\n" "> > implementing it, IMA wouldn't even know.\n" "> \n" "> I'm not sure this is good news.\n" @@ -60,18 +60,18 @@ "> If EFI is extending the TPM, will the events be added to the TPM\n" "> event log or to the IMA measurement list?\n" "\n" - "I'm not proposing any changes to the tpm_pcr_extend API. At the moment\n" + "I'm not proposing any changes to the tpm_pcr_extend API. \302\240At the moment\n" "it does an extend without logging, so that's what it will do in the EFI\n" - "driver case as well. That means logging is still the responsibility of\n" + "driver case as well. \302\240That means logging is still the responsibility of\n" "the caller.\n" "\n" - "> Up to now the IMA boot aggregate record includes PCRs from 0 - 7.\n" - "> With these PCRs, the boot aggregate wouldn't change when booting the\n" - "> same kernel. Would you change the boot-aggregate to include these\n" + "> \302\240 Up to now the IMA boot aggregate record includes PCRs from 0 - 7.\n" + "> \302\240With these PCRs, the boot aggregate wouldn't change when booting the\n" + "> same kernel. \302\240Would you change the boot-aggregate to include these\n" "> other PCRs?\n" "\n" - "This is all IMA internal stuff that's up to you. All I would do is\n" - "make the tpm_pcr API work with an EFI driver. That has no impact on\n" + "This is all IMA internal stuff that's up to you. \302\240All I would do is\n" + "make the tpm_pcr API work with an EFI driver. \302\240That has no impact on\n" "what the PCRs return (well, unless we start using it to log early\n" "components of the kernel boot, which is a possibility).\n" "\n" @@ -87,11 +87,11 @@ "> What happens for non EFI systems, when you can't extend the TPM?\n" "\n" "The same as happens today if there's no TPM available: you'd get an\n" - "error return. Since older bios is essentially legacy, I wouldn't\n" + "error return. \302\240Since older bios is essentially legacy, I wouldn't\n" "propose fixing this, but the TCG does define a non-EFI BIOS interface\n" "which could theoretically be used in the same way as the BIOS one if\n" "someone with a legacy box were interested in implementing it.\n" "\n" James -23ed0a6c511d2ca3028494bae2de2f22c6c137ab99e13b1cc82d0eaf23f9d974 +d066907c0c53c14dba29a67397cada1b04bd787479f87f1a465260c58d10a8c3
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.