From: ebiederm@xmission.com (Eric W. Biederman)
To: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
Michael Ellerman <michael@ellerman.id.au>
Subject: Re: ima measurement carrying on -mm
Date: Thu, 29 Sep 2016 16:53:50 -0500 [thread overview]
Message-ID: <87a8eqwexd.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <10788418.Ym8VJ8yVbp@hactar> (Thiago Jung Bauermann's message of "Thu, 29 Sep 2016 18:29:22 -0300")
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> writes:
> Am Donnerstag, 29 September 2016, 14:02:06 schrieb Andrew Morton:
>> On Thu, 29 Sep 2016 17:44:10 -0300 Thiago Jung Bauermann
> <bauerman@linux.vnet.ibm.com> wrote:
>> > Hello Andrew,
>> >
>> > You have in the -mm tree a version of the "kexec handover buffer" and
>> > "ima carry measurement list" patches that were NAKed by Eric Biederman.
>> > I would just like to double-check that there's no risk of that version
>> > reaching v4.9.
>> >
>> > Mimi posted v5 of a merged patch set that addresses Eric's concern:
>> >
>> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-September/149183.ht
>> > ml
>> >
>> > There are no separate kexec handover patches anymore. They were folded
>> > into the series above. The kexec code is simplified now, it doesn't
>> > support updating the buffer and recalculating the hash on reboot, and
>> > is now IMA- specific instead of a generic kexec feature.
>>
>> Yup, thanks.
>>
>> I wasn't thinking any of this material is suitable for 4.9. Seems that
>> a bit more consideration will be needed. Am I wrong about that?
>
> Yes regarding the "ima carry measurement list" patches, but I was hoping
> that at least the kexec_file_load patches would be upstreamed.
Oh bah. I was confused about that straight forward adding of kexec_file
support to powerpc. I thought that was already in existence.
In that case let me say I am concerned about modifying the flattened
device tree, especially in the kexec_file. I would think that the
flattened device tree would be something that it would be desirable to
keep intact.
I know in the x86 boot protocol we have some variables that are purely
passed by the bootloader (like the command line) and some that just
representations of firmware provided information. Does powerpc not have
that separation.
I would think being able to pass the flattened device tree through
unchanged would be very desirable in the kexec case as it removes the
possibility of error.
>> Are all of these -mm patches up to date?
>>
>> kexec_file-allow-arch-specific-memory-walking-for-kexec_add_buffer.patch
>> kexec_file-change-kexec_add_buffer-to-take-kexec_buf-as-argument.patch
>> kexec_file-factor-out-kexec_locate_mem_hole-from-kexec_add_buffer.patch
>> powerpc-change-places-using-config_kexec-to-use-config_kexec_core-instead.
>> patch
>> powerpc-factor-out-relocation-code-from-module_64c-to-elf_util_64c.patch
>> powerpc-generalize-elf64_apply_relocate_add.patch
>> powerpc-adapt-elf64_apply_relocate_add-for-kexec_file_load.patch
>> powerpc-add-functions-to-read-elf-files-of-any-endianness.patch
>> powerpc-implement-kexec_file_load.patch
>> powerpc-add-code-to-work-with-device-trees-in-kexec_file_load.patch
>> powerpc-add-support-for-loading-elf-kernels-with-kexec_file_load.patch
>> powerpc-add-support-for-loading-elf-kernels-with-kexec_file_load-fix.patch
>> powerpc-add-purgatory-for-kexec_file_load-implementation.patch
>> powerpc-add-purgatory-for-kexec_file_load-implementation-fix.patch
>> powerpc-enable-config_kexec_file-in-powerpc-server-defconfigs.patch
>
> Yes, the above are the latest version (v8).
Eric
next prev parent reply other threads:[~2016-09-29 21:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 20:44 ima measurement carrying on -mm Thiago Jung Bauermann
2016-09-29 21:02 ` Andrew Morton
2016-09-29 21:29 ` Thiago Jung Bauermann
2016-09-29 21:53 ` Eric W. Biederman [this message]
2016-09-29 22:16 ` Thiago Jung Bauermann
2016-09-29 21:47 ` Eric W. Biederman
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=87a8eqwexd.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=bauerman@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@ellerman.id.au \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox