From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965141AbcIPUBE (ORCPT ); Fri, 16 Sep 2016 16:01:04 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:44161 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935545AbcIPUAx (ORCPT ); Fri, 16 Sep 2016 16:00:53 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Mimi Zohar Cc: Andrew Morton , linux-security-module , linux-ima-devel@lists.sourceforge.net, Dave Young , kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Thiago Jung Bauermann , Stephen Rothwell References: <1472596811-9596-1-git-send-email-zohar@linux.vnet.ibm.com> <20160831135047.4b05a7f912f158ed5f888241@linux-foundation.org> <1472683086.2607.17.camel@linux.vnet.ibm.com> <1473954263.2526.88.camel@linux.vnet.ibm.com> Date: Fri, 16 Sep 2016 14:47:13 -0500 In-Reply-To: <1473954263.2526.88.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 15 Sep 2016 11:44:23 -0400") Message-ID: <87lgyrsk3i.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=1bkzJZ-0007td-07;;;mid=<87lgyrsk3i.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=97.119.97.64;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/PyvzSLFp5rxwYFQOjz+pPvqdq3z0Kqn8= X-SA-Exim-Connect-IP: 97.119.97.64 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.7 XMSubLong Long Subject * 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: ;Mimi Zohar X-Spam-Relay-Country: X-Spam-Timing: total 467 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.0 (0.6%), b_tie_ro: 2.1 (0.5%), parse: 0.81 (0.2%), extract_message_metadata: 12 (2.6%), get_uri_detail_list: 2.8 (0.6%), tests_pri_-1000: 4.8 (1.0%), tests_pri_-950: 1.15 (0.2%), tests_pri_-900: 0.97 (0.2%), tests_pri_-400: 48 (10.3%), check_bayes: 47 (10.1%), b_tokenize: 9 (2.0%), b_tok_get_all: 19 (4.1%), b_comp_prob: 3.2 (0.7%), b_tok_touch_all: 13 (2.8%), b_finish: 0.59 (0.1%), tests_pri_0: 388 (83.2%), check_dkim_signature: 0.49 (0.1%), check_dkim_adsp: 3.0 (0.6%), tests_pri_500: 4.4 (0.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATHC v2 0/9] ima: carry the measurement list across kexec 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 Mimi Zohar writes: > Hi Andrew, > > On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote: >> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote: >> > On Tue, 30 Aug 2016 18:40:02 -0400 Mimi Zohar wrote: >> > >> > > The TPM PCRs are only reset on a hard reboot. In order to validate a >> > > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list >> > > of the running kernel must be saved and then restored on the subsequent >> > > boot, possibly of a different architecture. >> > > >> > > The existing securityfs binary_runtime_measurements file conveniently >> > > provides a serialized format of the IMA measurement list. This patch >> > > set serializes the measurement list in this format and restores it. >> > > >> > > Up to now, the binary_runtime_measurements was defined as architecture >> > > native format. The assumption being that userspace could and would >> > > handle any architecture conversions. With the ability of carrying the >> > > measurement list across kexec, possibly from one architecture to a >> > > different one, the per boot architecture information is lost and with it >> > > the ability of recalculating the template digest hash. To resolve this >> > > problem, without breaking the existing ABI, this patch set introduces >> > > the boot command line option "ima_canonical_fmt", which is arbitrarily >> > > defined as little endian. >> > > >> > > The need for this boot command line option will be limited to the >> > > existing version 1 format of the binary_runtime_measurements. >> > > Subsequent formats will be defined as canonical format (eg. TPM 2.0 >> > > support for larger digests). >> > > >> > > This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer >> > > hand-over for the next kernel" patch set. >> > > >> > > These patches can also be found in the next-kexec-restore branch of: >> > > git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git >> > >> > I'll merge these into -mm to get some linux-next exposure. I don't >> > know what your upstream merge plans will be? >> >> Sounds good. I'm hoping to get some review/comments on this patch set >> as well. At the moment, I'm chasing down a kernel test robot report >> from this afternoon. > > My concern about changing the canonical format as originally defined in > patch 9/9 from big endian to little endian never materialized. Andreas > Steffan, the patch author, is happy either way. > > We proposed two methods of addressing Eric Biederman's concerns of not > including the IMA measurement list segment in the kexec hash as > described in https://lkml.org/lkml/2016/9/9/355. > > - defer calculating and verifying the serialized IMA measurement list > buffer hash to IMA > - calculate the kexec hash on load, verify it on the kexec execute, > before re-calculating and updating it. I need to ask: How this is anticipated to interact with kexec on panic? Because honestly I can't see this ever working in that case. The assumption is that the original kernel has gone crazy. So from a practical standpoint any trusted path should have been invalided. This entire idea of updating the kexec image makes me extremely extremely nervious. It feels like sticking a screw driver through the spokes of your bicicle tires while ridding down the road. I can see tracking to see if the list has changed at some point and causing a reboot(LINUX_REBOOT_CMD_KEXEC) to fail. At least the common bootloader cases that I know of using kexec are very minimal distributions that live in a ramdisk and as such it should be very straight forward to measure what is needed at or before sys_kexec_load. But that was completely dismissed as unrealistic so I don't have a clue what actual problem you are trying to solve. If there is anyway we can start small and not with this big scary infrastructure change I would very much prefer it. Eric