From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934854AbcI2Vzq (ORCPT ); Thu, 29 Sep 2016 17:55:46 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:51592 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932185AbcI2Vzk (ORCPT ); Thu, 29 Sep 2016 17:55:40 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Thiago Jung Bauermann Cc: Andrew Morton , Stephen Rothwell , Mimi Zohar , LKML , Michael Ellerman References: <1687520.U903BamSQx@hactar> <20160929140206.bc37b32cd63d9635682274c8@linux-foundation.org> <10788418.Ym8VJ8yVbp@hactar> Date: Thu, 29 Sep 2016 16:53:50 -0500 In-Reply-To: <10788418.Ym8VJ8yVbp@hactar> (Thiago Jung Bauermann's message of "Thu, 29 Sep 2016 18:29:22 -0300") Message-ID: <87a8eqwexd.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bpjIo-0003vo-Cw;;;mid=<87a8eqwexd.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=75.170.125.99;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/WkVouywW81bSL+kW8iJBstHV+NhtpIWg= X-SA-Exim-Connect-IP: 75.170.125.99 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Thiago Jung Bauermann X-Spam-Relay-Country: X-Spam-Timing: total 289 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.2 (1.1%), b_tie_ro: 2.3 (0.8%), parse: 1.21 (0.4%), extract_message_metadata: 18 (6.3%), get_uri_detail_list: 4.0 (1.4%), tests_pri_-1000: 9 (3.0%), tests_pri_-950: 1.64 (0.6%), tests_pri_-900: 1.35 (0.5%), tests_pri_-400: 27 (9.3%), check_bayes: 25 (8.8%), b_tokenize: 7 (2.5%), b_tok_get_all: 9 (3.0%), b_comp_prob: 2.6 (0.9%), b_tok_touch_all: 3.8 (1.3%), b_finish: 0.86 (0.3%), tests_pri_0: 220 (76.3%), check_dkim_signature: 0.78 (0.3%), check_dkim_adsp: 2.4 (0.8%), tests_pri_500: 3.6 (1.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: ima measurement carrying on -mm X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thiago Jung Bauermann writes: > Am Donnerstag, 29 September 2016, 14:02:06 schrieb Andrew Morton: >> On Thu, 29 Sep 2016 17:44:10 -0300 Thiago Jung Bauermann > 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