From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752112AbcIIEUz (ORCPT ); Fri, 9 Sep 2016 00:20:55 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:37224 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbcIIEUv (ORCPT ); Fri, 9 Sep 2016 00:20:51 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Thiago Jung Bauermann Cc: kexec@lists.infradead.org, linux-security-module@vger.kernel.org, linux-ima-devel@lists.sourceforge.net, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Dave Young , Vivek Goyal , Baoquan He , Michael Ellerman , Stewart Smith , Mimi Zohar , Eric Richter , Andrew Morton , Balbir Singh References: <1472579105-26296-1-git-send-email-bauerman@linux.vnet.ibm.com> <8760q7lswz.fsf@x220.int.ebiederm.org> <871t0vlrlv.fsf@x220.int.ebiederm.org> <3106532.NfQxgDJQ20@hactar> Date: Thu, 08 Sep 2016 23:07:17 -0500 In-Reply-To: <3106532.NfQxgDJQ20@hactar> (Thiago Jung Bauermann's message of "Thu, 08 Sep 2016 16:20:45 -0300") Message-ID: <87k2elhg22.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=1biDJ0-00010o-7i;;;mid=<87k2elhg22.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=97.119.97.64;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX192IMfL9o0rKFtkzzf7zxJbB22ERzj+okw= 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.7 XMSubLong Long Subject * 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Thiago Jung Bauermann X-Spam-Relay-Country: X-Spam-Timing: total 632 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.9 (0.6%), b_tie_ro: 2.7 (0.4%), parse: 1.03 (0.2%), extract_message_metadata: 13 (2.1%), get_uri_detail_list: 3.2 (0.5%), tests_pri_-1000: 6 (0.9%), tests_pri_-950: 1.15 (0.2%), tests_pri_-900: 0.98 (0.2%), tests_pri_-400: 33 (5.3%), check_bayes: 32 (5.1%), b_tokenize: 10 (1.5%), b_tok_get_all: 12 (1.8%), b_comp_prob: 3.9 (0.6%), b_tok_touch_all: 4.2 (0.7%), b_finish: 0.82 (0.1%), tests_pri_0: 562 (89.0%), check_dkim_signature: 0.64 (0.1%), check_dkim_adsp: 2.5 (0.4%), tests_pri_500: 7 (1.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel 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 in02.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 Mittwoch, 07 September 2016, 09:19:40 schrieb Eric W. Biederman: >> ebiederm@xmission.com (Eric W. Biederman) writes: >> > Thiago Jung Bauermann writes: >> >> Hello, >> >> >> >> The purpose of this new version of the series is to fix a small issue >> >> that I found, which is that the kernel doesn't remove the memory >> >> reservation for the hand-over buffer it received from the previous >> >> kernel in the device tree it sets up for the next kernel. The result >> >> is that for each successive kexec, a stale hand-over buffer is left >> >> behind, wasting memory. >> >> >> >> This is fixed by changes to kexec_free_handover_buffer and >> >> setup_handover_buffer in patch 2. The other change is to fix checkpatch >> >> warnings in the last patch. >> > >> > This is fundamentally broken. You do not increase the integrity of a >> > system by dropping integrity checks. >> > >> > No. No. No. No. >> > >> > Nacked-by: "Eric W. Biederman" > > The IMA measurement list can be verified without the need of a checksum over > its contents by replaying the PCR extend operations and checking that the > result matches the registers in the TPM device. So the fact that it is not > part of the kexec segments checksum verification doesn't actually reduce the > integrity of the system. Bit flips and errant DMA transfers are the concern here. That happens routinely and can easily result in a corrupt data structure which may be non-trivial to verify. > Currently, IMA doesn't perform that verification when it restores the > measurement list from the kexec handover buffer, so if you believe it's > necessary to do that check at boot time, we could do one of the following: > > 1. Have IMA replay the PCR extend operations when it restores the > measurement list from the handover buffer and validate it against the TPM > PCRs, or > > 2. Have a buffer hash in the ima_kexec_hdr that IMA includes in the handover > buffer, and verify the buffer checksum before restoring the measurement > list. > > What do you think? I think you are playing very much with fire and I am extremely uncomfortable with the entire concept. I think you are making things more complicated in a way that will allow system to try and start booting when their memory is correct. Which may wind up corrupting someones non-volatile storage. It makes me doubly nervous that this adds a general purpose facility that is generally not at all reusable. I have seen malicious actors cause entirely too much damage to be at all comfortable using a data structure before we validate that it was valid before we started booting. This isn't the same case but it is close enough I don't trust someone just splatting data structures. We can't guarantee integrity but we should not bypass best practices either. >> To be constructive the way we have handled similiar situations in the >> past (hotplu memory) is to call kexec_load again. > > Thanks for your suggestion. Unfortunately it's always possible for new > measurements to be added to the measurement list between the kexec_file_load > and the reboot. We see that happen in practice with system scripts and > configuration files that are only read or executed during the reboot > process. They are only measured by IMA as a result of the kexec execute. If I understand what you are saying correctly I expect things could be setup so that those measurements are forced to happen before kexec load. Especially in a boot loader context which you described earlier I believe you should have quite a lot of control of the system. Having a facility that fundamentally undermines the design of kexec for a case where someone might do something you have not predicted does not make me comfortable. Which is to say I don't see why you can't measure things before the kexec_load system call in a tightly controlled setup like a boot loader. Which should make it that in practice no measurements change. I believe that should increase the reliability of the system overall. Having code in the kernel that updates a buffer that kexec will use after that buffer is loaded in memory honestely gives me the heebie jeebies. Eric