From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163036AbcIZSbw (ORCPT ); Mon, 26 Sep 2016 14:31:52 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52533 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933770AbcIZSbs (ORCPT ); Mon, 26 Sep 2016 14:31:48 -0400 From: Thiago Jung Bauermann To: "Eric W. Biederman" Cc: Mimi Zohar , 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, Stephen Rothwell Subject: Re: [PATHC v2 0/9] ima: carry the measurement list across kexec Date: Mon, 26 Sep 2016 15:31:38 -0300 User-Agent: KMail/4.14.3 (Linux/4.4.0-38-generic; KDE/4.14.13; x86_64; ; ) In-Reply-To: <87y42mk11a.fsf@x220.int.ebiederm.org> References: <1472596811-9596-1-git-send-email-zohar@linux.vnet.ibm.com> <15061913.JRHEL97DN3@hactar> <87y42mk11a.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16092618-0024-0000-0000-0000010DF63E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16092618-0025-0000-0000-000015BF2513 Message-Id: <1743059.2ZOQaNILxh@hactar> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-26_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609260347 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Eric, Am Dienstag, 20 September 2016, 11:07:29 schrieb Eric W. Biederman: > Thiago Jung Bauermann writes: > > Am Samstag, 17 September 2016, 00:17:37 schrieb Eric W. Biederman: > >> Thiago Jung Bauermann 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