From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, linux-security-module <linux-security-module@vger.kernel.org>, linux-ima-devel@lists.sourceforge.net, Dave Young <dyoung@redhat.com>, kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Stephen Rothwell <sfr@canb.auug.org.au> Subject: Re: [PATHC v2 0/9] ima: carry the measurement list across kexec Date: Mon, 26 Sep 2016 15:31:38 -0300 [thread overview] Message-ID: <1743059.2ZOQaNILxh@hactar> (raw) In-Reply-To: <87y42mk11a.fsf@x220.int.ebiederm.org> Hello Eric, Am Dienstag, 20 September 2016, 11:07:29 schrieb Eric W. Biederman: > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> writes: > > Am Samstag, 17 September 2016, 00:17:37 schrieb Eric W. Biederman: > >> Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> writes: > > Is this what you had in mind? > > Sort of. > > I was just thinking that instead of having the boot path verify your ima > list matches what is in the tpm and halting the boot there, we could > test that on reboot. Which would give a clean failure without the nasty > poking into a prepared image. The downside is that we have already run > the shutdown scripts so it wouldn't be much cleaner, than triggering a > machine reboot from elsewhere. > > But I don't think we should spend too much time on that. It was a > passing thought. We should focus on getting a non-poked ima buffer > cleanly into kexec and we can worry about the rest later. I was thinking of this as something orthogonal to the ima buffer feature. But you're right, it's better not to discuss this now. I'll post a separate patch for this later. > >> So from 10,000 feet I think that is correct. > >> > >> I am not quite certain why a new mechanism is being invented. We have > >> other information that is already passed (much of it architecture > >> specific) like the flattened device tree. If you remove the need to > >> update the information can you just append this information to the > >> flattened device tree without a new special mechanism to pass the data? > >> > >> I am just reluctant to invent a new mechanism when there is an existing > >> mechanism that looks like it should work without problems. > > > > Michael Ellerman suggested putting the buffer contents inside the device > > tree itself, but the s390 people are also planning to implement this > > feature. That architecture doesn't use device trees, so a solution that > > depends on DTs won't help them. > > > > With this mechanism each architecture will still need its own way of > > communicating to the next kernel where the buffer is, but I think it's > > easier to pass a base address and length than to pass a whole buffer. > > A base address and length pair is fine. There are several other pieces > of data that we pass that way. > > > I suppose we could piggyback the ima measurements buffer at the end of > > one of the other segments such as the kernel or, in the case of > > powerpc, the dtb but it looks hackish to me. I think it's cleaner to > > put it in its own segment. > > The boot protocol unfortunately is different on different architectures, > and for each one we will have to implement and document the change. > Because when you get into boot protocol issues you can't assume the > kernel you are booting is the same version as the kernel that is booting > it. > > Where I run into a problem is you added a semi-generic concept a > hand-over buffer. Not a ima data buffer but a hand-over buffer. > > The data falling in it's own dedicated area of memory and being added > with kexec_add_buffer is completely fine. I can see a dedicated pointer > in struct kimage if necessary. > > A semi-generic concept called a hand-over buffer seems to be a > construction of infrustructure for no actual reason that will just > result in confusion. There are lots of things that are handed over, the > flattend device tree, ramdisks, bootparams on x86, etc, etc. ima is not > special in this execpt for being perhaps the first addition that we are > going to want the option of including on most architectures. Ok, I understand. I decided to implement a generic concept because I thought that proposing a feature that is more useful than what I need it for would increase its chance of being accepted. It's interesting to see that it had the opposite effect. I reworked and simplified the code and folded the hand-over buffer patches into Mimi's patch series to carry the measurement list across kexec. The kexec buffer code is in the following patches now: [PATCH v5 01/10] powerpc: ima: Get the kexec buffer passed by the previous kernel [PATCH v5 05/10] powerpc: ima: Send the kexec buffer to the next kernel Each patch has a changelog listing what I changed to make it specific to IMA. -- []'s Thiago Jung Bauermann IBM Linux Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au>, Mimi Zohar <zohar@linux.vnet.ibm.com>, kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-security-module <linux-security-module@vger.kernel.org>, linux-ima-devel@lists.sourceforge.net, Andrew Morton <akpm@linux-foundation.org>, Dave Young <dyoung@redhat.com> Subject: Re: [PATHC v2 0/9] ima: carry the measurement list across kexec Date: Mon, 26 Sep 2016 15:31:38 -0300 [thread overview] Message-ID: <1743059.2ZOQaNILxh@hactar> (raw) In-Reply-To: <87y42mk11a.fsf@x220.int.ebiederm.org> Hello Eric, Am Dienstag, 20 September 2016, 11:07:29 schrieb Eric W. Biederman: > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> writes: > > Am Samstag, 17 September 2016, 00:17:37 schrieb Eric W. Biederman: > >> Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> writes: > > Is this what you had in mind? > > Sort of. > > I was just thinking that instead of having the boot path verify your ima > list matches what is in the tpm and halting the boot there, we could > test that on reboot. Which would give a clean failure without the nasty > poking into a prepared image. The downside is that we have already run > the shutdown scripts so it wouldn't be much cleaner, than triggering a > machine reboot from elsewhere. > > But I don't think we should spend too much time on that. It was a > passing thought. We should focus on getting a non-poked ima buffer > cleanly into kexec and we can worry about the rest later. I was thinking of this as something orthogonal to the ima buffer feature. But you're right, it's better not to discuss this now. I'll post a separate patch for this later. > >> So from 10,000 feet I think that is correct. > >> > >> I am not quite certain why a new mechanism is being invented. We have > >> other information that is already passed (much of it architecture > >> specific) like the flattened device tree. If you remove the need to > >> update the information can you just append this information to the > >> flattened device tree without a new special mechanism to pass the data? > >> > >> I am just reluctant to invent a new mechanism when there is an existing > >> mechanism that looks like it should work without problems. > > > > Michael Ellerman suggested putting the buffer contents inside the device > > tree itself, but the s390 people are also planning to implement this > > feature. That architecture doesn't use device trees, so a solution that > > depends on DTs won't help them. > > > > With this mechanism each architecture will still need its own way of > > communicating to the next kernel where the buffer is, but I think it's > > easier to pass a base address and length than to pass a whole buffer. > > A base address and length pair is fine. There are several other pieces > of data that we pass that way. > > > I suppose we could piggyback the ima measurements buffer at the end of > > one of the other segments such as the kernel or, in the case of > > powerpc, the dtb but it looks hackish to me. I think it's cleaner to > > put it in its own segment. > > The boot protocol unfortunately is different on different architectures, > and for each one we will have to implement and document the change. > Because when you get into boot protocol issues you can't assume the > kernel you are booting is the same version as the kernel that is booting > it. > > Where I run into a problem is you added a semi-generic concept a > hand-over buffer. Not a ima data buffer but a hand-over buffer. > > The data falling in it's own dedicated area of memory and being added > with kexec_add_buffer is completely fine. I can see a dedicated pointer > in struct kimage if necessary. > > A semi-generic concept called a hand-over buffer seems to be a > construction of infrustructure for no actual reason that will just > result in confusion. There are lots of things that are handed over, the > flattend device tree, ramdisks, bootparams on x86, etc, etc. ima is not > special in this execpt for being perhaps the first addition that we are > going to want the option of including on most architectures. Ok, I understand. I decided to implement a generic concept because I thought that proposing a feature that is more useful than what I need it for would increase its chance of being accepted. It's interesting to see that it had the opposite effect. I reworked and simplified the code and folded the hand-over buffer patches into Mimi's patch series to carry the measurement list across kexec. The kexec buffer code is in the following patches now: [PATCH v5 01/10] powerpc: ima: Get the kexec buffer passed by the previous kernel [PATCH v5 05/10] powerpc: ima: Send the kexec buffer to the next kernel Each patch has a changelog listing what I changed to make it specific to IMA. -- []'s Thiago Jung Bauermann IBM Linux Technology Center _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2016-09-26 18:31 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-30 22:40 [PATHC v2 0/9] ima: carry the measurement list across kexec Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 1/9] ima: on soft reboot, restore the measurement list Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 2/9] ima: permit duplicate measurement list entries Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 3/9] ima: maintain memory size needed for serializing the measurement list Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 4/9] ima: serialize the binary_runtime_measurements Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 5/9] ima: on soft reboot, save the measurement list Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-09-01 1:57 ` Dave Young 2016-09-01 1:57 ` Dave Young 2016-09-02 13:22 ` Mimi Zohar 2016-09-02 13:22 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 6/9] ima: store the builtin/custom template definitions in a list Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 7/9] ima: support restoring multiple template formats Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 8/9] ima: define a canonical binary_runtime_measurements list format Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-30 22:40 ` [PATHC v2 9/9] ima: platform-independent hash value Mimi Zohar 2016-08-30 22:40 ` Mimi Zohar 2016-08-31 20:50 ` [PATHC v2 0/9] ima: carry the measurement list across kexec Andrew Morton 2016-08-31 20:50 ` Andrew Morton 2016-08-31 22:38 ` Mimi Zohar 2016-08-31 22:38 ` Mimi Zohar 2016-09-15 15:44 ` Mimi Zohar 2016-09-15 15:44 ` Mimi Zohar 2016-09-16 19:47 ` Eric W. Biederman 2016-09-16 19:47 ` Eric W. Biederman 2016-09-16 21:03 ` Eric W. Biederman 2016-09-16 21:03 ` Eric W. Biederman 2016-09-16 23:32 ` Thiago Jung Bauermann 2016-09-16 23:32 ` Thiago Jung Bauermann 2016-09-17 5:17 ` Eric W. Biederman 2016-09-17 5:17 ` Eric W. Biederman 2016-09-18 21:25 ` Thiago Jung Bauermann 2016-09-18 21:25 ` Thiago Jung Bauermann 2016-09-20 16:07 ` Eric W. Biederman 2016-09-20 16:07 ` Eric W. Biederman 2016-09-26 18:31 ` Thiago Jung Bauermann [this message] 2016-09-26 18:31 ` Thiago Jung Bauermann 2016-09-29 21:43 ` Eric W. Biederman 2016-09-29 21:43 ` Eric W. Biederman 2016-09-29 22:21 ` Thiago Jung Bauermann 2016-09-29 22:21 ` Thiago Jung Bauermann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1743059.2ZOQaNILxh@hactar \ --to=bauerman@linux.vnet.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=dyoung@redhat.com \ --cc=ebiederm@xmission.com \ --cc=kexec@lists.infradead.org \ --cc=linux-ima-devel@lists.sourceforge.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=sfr@canb.auug.org.au \ --cc=zohar@linux.vnet.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.