Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp1739013ybj; Fri, 20 Sep 2019 15:53:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqwVWWAImEoBmWmb0qo56bep8OI91HridfJGkmYitC57PeqCF1TBIngVuUHUYw0wcNkRtg41 X-Received: by 2002:a05:6402:2cb:: with SMTP id b11mr24880416edx.285.1569019980223; Fri, 20 Sep 2019 15:53:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569019980; cv=none; d=google.com; s=arc-20160816; b=WpdyQlohgckohBsGdj9SsrBLat2XfNCwXb/pBVXoPwuqY0io8v27UGSUrchPHWlzwz 0adUUXHzLRXBixzr0hU621K4oAucbYw1qZKSwt9QFdTfVJ4Qt0HMRzDdeau6UVRyLj/g 06ac9ywV2JoDPqdGsPvzOcNIHtn3T4hoQ7XP32ICfEDVqLDeJs1SRLjZhtn/GoJ/Kdke elFyk9evcndVUBcZecjFDKsz2Jf1coke4102tR8CkDoiA6b3mMgsHOLiwccM8TlxXinP 0S8iorjoKK8zhImd4B7LkIhYsqClQ4sHABiIZu5sEOcyT419jDvwPzybOOPVwi4JWIeU 5v0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=249oIv7GnE63FAC0VOLNaBV4LOLLar3uIvMhV/Vj/RA=; b=rsiDM0vIF6NK2xxBKyqvDBDEjCELvL8hMHKdIbai+FIUMF3fk/Z0CXmvntlK8eRtct UJkjN2Qh6QcV9ADPcHiK9R+5OlTmhepKQVnppln+Jo27glsh/bMIaMpKz9548WD9caRZ ypx4Aju1nsyk0Rtn5q/vyzCcnY3vGAB1zvz0n5z0UubzmUyPl1PoFf42GUy9Eovf9Oz2 NmrMoMq/QdmrRSBv+aULbjm4fOCUq3mkdzft8oXZGPxIvdW4gDdaxVDN4USet6Cl63YI rJ0xPO2s1WPM+V6+GeNUkcP7Z18fjhwthhgDTVoo/Df045APmQNulfCw3N6ZjWm9rwou /l7Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e23si2200847edq.344.2019.09.20.15.52.36; Fri, 20 Sep 2019 15:53:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437114AbfITDIH (ORCPT + 99 others); Thu, 19 Sep 2019 23:08:07 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:63116 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404190AbfITDIH (ORCPT ); Thu, 19 Sep 2019 23:08:07 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x8K32GnS112296; Thu, 19 Sep 2019 23:07:14 -0400 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com with ESMTP id 2v4hjc02fe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Sep 2019 23:07:14 -0400 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x8K352eH011696; Fri, 20 Sep 2019 03:07:13 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma01wdc.us.ibm.com with ESMTP id 2v3vbttjuy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Sep 2019 03:07:13 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x8K37CQv7275148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Sep 2019 03:07:12 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AE9CAC068; Fri, 20 Sep 2019 03:07:12 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6591CAC05B; Fri, 20 Sep 2019 03:07:08 +0000 (GMT) Received: from morokweng.localdomain (unknown [9.85.222.171]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTPS; Fri, 20 Sep 2019 03:07:08 +0000 (GMT) References: <20190913225009.3406-1-prsriva@linux.microsoft.com> <20190913225009.3406-2-prsriva@linux.microsoft.com> User-agent: mu4e 1.2.0; emacs 26.2 From: Thiago Jung Bauermann To: Prakhar Srivastava Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-integrity@vger.kernel.org, kexec@lists.infradead.org, arnd@arndb.de, jean-philippe@linaro.org, allison@lohutok.net, kristina.martsenko@arm.org, yamada.masahiro@socionext.com, duwe@lst.de, mark.rutland@arm.com, tglx@linutronix.de, takahiro.akashi@linaro.org, james.morse@arm.org, catalin.marinas@arm.com, sboyd@kernel.org, zohar@linux.ibm.com Subject: Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load In-reply-to: <20190913225009.3406-2-prsriva@linux.microsoft.com> Date: Fri, 20 Sep 2019 00:07:02 -0300 Message-ID: <87zhiz1x9l.fsf@morokweng.localdomain> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-19_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909200033 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Prakhar, Prakhar Srivastava writes: > During kexec_file_load, carrying forward the ima measurement log allows > a verifying party to get the entire runtime event log since the last > full reboot since that is when PCRs were last reset. > > Signed-off-by: Prakhar Srivastava > --- > arch/arm64/Kconfig | 7 + > arch/arm64/include/asm/ima.h | 29 ++++ > arch/arm64/include/asm/kexec.h | 5 + > arch/arm64/kernel/Makefile | 3 +- > arch/arm64/kernel/ima_kexec.c | 213 +++++++++++++++++++++++++ > arch/arm64/kernel/machine_kexec_file.c | 6 + > 6 files changed, 262 insertions(+), 1 deletion(-) > create mode 100644 arch/arm64/include/asm/ima.h > create mode 100644 arch/arm64/kernel/ima_kexec.c > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 3adcec05b1f6..f39b12dbf9e8 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -976,6 +976,13 @@ config KEXEC_VERIFY_SIG > verification for the corresponding kernel image type being > loaded in order for this to work. > > +config HAVE_IMA_KEXEC > + bool "Carry over IMA measurement log during kexec_file_load() syscall" > + depends on KEXEC_FILE > + help > + Select this option to carry over IMA measurement log during > + kexec_file_load. > + > config KEXEC_IMAGE_VERIFY_SIG > bool "Enable Image signature verification support" > default y This is not right. As it stands, HAVE_IMA_KEXEC is essentially a synonym for IMA_KEXEC. It's not meant to be user-visible in the config process. Instead, it's meant to be selected by the arch Kconfig (probably by the ARM64 config symbol) to signal to IMA's Kconfig that it can offer the IMA_KEXEC option. I also mentioned in my previous review that config HAVE_IMA_KEXEC should be defined in arch/Kconfig, not separately in both arch/arm64/Kconfig and arch/powerpc/Kconfig. > diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h > new file mode 100644 > index 000000000000..e23cee84729f > --- /dev/null > +++ b/arch/arm64/include/asm/ima.h > @@ -0,0 +1,29 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _ASM_ARM64_IMA_H > +#define _ASM_ARM64_IMA_H > + > +struct kimage; > + > +int ima_get_kexec_buffer(void **addr, size_t *size); > +int ima_free_kexec_buffer(void); > + > +#ifdef CONFIG_IMA > +void remove_ima_buffer(void *fdt, int chosen_node); > +#else > +static inline void remove_ima_buffer(void *fdt, int chosen_node) {} > +#endif I mentioned in my previous review that remove_ima_buffer() should exist even if CONFIG_IMA isn't set. Did you arrive at a different conclusion? > + > +#ifdef CONFIG_IMA_KEXEC > +int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr, > + size_t size); > + > +int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node); > +#else > +static inline int setup_ima_buffer(const struct kimage *image, void *fdt, > + int chosen_node) > +{ > + remove_ima_buffer(fdt, chosen_node); > + return 0; > +} > +#endif /* CONFIG_IMA_KEXEC */ > +#endif /* _ASM_ARM64_IMA_H */ > diff --git a/arch/arm64/kernel/ima_kexec.c b/arch/arm64/kernel/ima_kexec.c > new file mode 100644 > index 000000000000..b14326d541f3 > --- /dev/null > +++ b/arch/arm64/kernel/ima_kexec.c In the previous patch, you took the powerpc file and made a few modifications to fit your needs. This file is now somewhat different than the powerpc version, but I don't understand to what purpose. It's not different in any significant way. Based on review comments from your previous patch, I was expecting to see code from the powerpc file moved to an arch-independent part of the the kernel and possibly adapted so that both arm64 and powerpc could use it. Can you explain why you chose this approach instead? What is the advantage of having superficially different but basically equivalent code in the two architectures? Actually, there's one change that is significant: instead of a single linux,ima-kexec-buffer property holding the start address and size of the buffer, ARM64 is now using two properties (linux,ima-kexec-buffer and linux,ima-kexec-buffer-end) for the start and end addresses. In my opinion, unless there's a good reason for it Linux should be consistent accross architectures when possible. -- Thiago Jung Bauermann IBM Linux Technology Center