From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bN0V8-0006sf-T6 for kexec@lists.infradead.org; Tue, 12 Jul 2016 16:25:39 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u6CGJsiB079437 for ; Tue, 12 Jul 2016 12:25:17 -0400 Received: from e24smtp02.br.ibm.com (e24smtp02.br.ibm.com [32.104.18.86]) by mx0a-001b2d01.pphosted.com with ESMTP id 243es61esx-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Jul 2016 12:25:16 -0400 Received: from localhost by e24smtp02.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 12 Jul 2016 13:25:15 -0300 From: Thiago Jung Bauermann Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Tue, 12 Jul 2016 13:25:11 -0300 In-Reply-To: <87furf7ztv.fsf@x220.int.ebiederm.org> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <87furf7ztv.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Message-Id: <50662781.Utjsnse3nb@hactar> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: "Eric W. Biederman" Cc: bhe@redhat.com, arnd@arndb.de, linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro , linux-arm-kernel@lists.infradead.org, dyoung@redhat.com, vgoyal@redhat.com Hi Eric, I'm trying to understand your concerns leading to your nack. I hope you don't mind expanding your thoughts on them a bit. Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro writes: > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > > > > This patch extends kexec_file_load system call by adding an extra > > argument to this syscall so that an arbitrary number of file descriptors > > can be handed out from user space to the kernel. > > > > See the background [1]. > > > > Please note that the new interface looks quite similar to the current > > system call, but that it won't always mean that it provides the "binary > > compatibility." > > > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html > > So this design is wrong. The kernel already has the device tree blob, > you should not be extracting it from the kernel munging it, and then > reinserting it in the kernel if you want signatures and everything to > pass. I don't understand how the kernel signature will be invalidated. There are some types of boot images that can embed a device tree blob in them, but the kernel can also be handed a separate device tree blob from firmware, the boot loader, or kexec. This latter case is what we are discussing, so we are not talking about modifying an embedded blob in the kernel image. > What x86 does is pass it's equivalent of the device tree blob from one > kernel to another directly and behind the scenes. It does not go > through userspace for this. > > Until a persuasive case can be made for going around the kernel and > probably adding a feature (like code execution) that can be used to > defeat the signature scheme I am going to nack this. I also don't understand what you mean by code execution. How does passing a device tree blob via kexec enables code execution? How can the signature scheme be defeated? -- []'s Thiago Jung Bauermann IBM Linux Technology Center _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3rpnPW32HQzDqDT for ; Wed, 13 Jul 2016 02:25:19 +1000 (AEST) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u6CGJf82074087 for ; Tue, 12 Jul 2016 12:25:17 -0400 Received: from e24smtp04.br.ibm.com (e24smtp04.br.ibm.com [32.104.18.25]) by mx0a-001b2d01.pphosted.com with ESMTP id 24507b1pgn-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Jul 2016 12:25:17 -0400 Received: from localhost by e24smtp04.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 12 Jul 2016 13:25:14 -0300 Received: from d24relay03.br.ibm.com (d24relay03.br.ibm.com [9.13.184.25]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id 9DDD11DC006E for ; Tue, 12 Jul 2016 12:25:04 -0400 (EDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.8.31.93]) by d24relay03.br.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u6CGPC3A14745956 for ; Tue, 12 Jul 2016 13:25:12 -0300 Received: from d24av02.br.ibm.com (localhost [127.0.0.1]) by d24av02.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u6CGPCma026810 for ; Tue, 12 Jul 2016 13:25:12 -0300 From: Thiago Jung Bauermann To: "Eric W. Biederman" Cc: AKASHI Takahiro , vgoyal@redhat.com, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Tue, 12 Jul 2016 13:25:11 -0300 In-Reply-To: <87furf7ztv.fsf@x220.int.ebiederm.org> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <87furf7ztv.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <50662781.Utjsnse3nb@hactar> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Eric, I'm trying to understand your concerns leading to your nack. I hope you don't mind expanding your thoughts on them a bit. Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro writes: > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > > > > This patch extends kexec_file_load system call by adding an extra > > argument to this syscall so that an arbitrary number of file descriptors > > can be handed out from user space to the kernel. > > > > See the background [1]. > > > > Please note that the new interface looks quite similar to the current > > system call, but that it won't always mean that it provides the "binary > > compatibility." > > > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html > > So this design is wrong. The kernel already has the device tree blob, > you should not be extracting it from the kernel munging it, and then > reinserting it in the kernel if you want signatures and everything to > pass. I don't understand how the kernel signature will be invalidated. There are some types of boot images that can embed a device tree blob in them, but the kernel can also be handed a separate device tree blob from firmware, the boot loader, or kexec. This latter case is what we are discussing, so we are not talking about modifying an embedded blob in the kernel image. > What x86 does is pass it's equivalent of the device tree blob from one > kernel to another directly and behind the scenes. It does not go > through userspace for this. > > Until a persuasive case can be made for going around the kernel and > probably adding a feature (like code execution) that can be used to > defeat the signature scheme I am going to nack this. I also don't understand what you mean by code execution. How does passing a device tree blob via kexec enables code execution? How can the signature scheme be defeated? -- []'s Thiago Jung Bauermann IBM Linux Technology Center From mboxrd@z Thu Jan 1 00:00:00 1970 From: bauerman@linux.vnet.ibm.com (Thiago Jung Bauermann) Date: Tue, 12 Jul 2016 13:25:11 -0300 Subject: [RFC 0/3] extend kexec_file_load system call In-Reply-To: <87furf7ztv.fsf@x220.int.ebiederm.org> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <87furf7ztv.fsf@x220.int.ebiederm.org> Message-ID: <50662781.Utjsnse3nb@hactar> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Eric, I'm trying to understand your concerns leading to your nack. I hope you don't mind expanding your thoughts on them a bit. Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro writes: > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > > > > This patch extends kexec_file_load system call by adding an extra > > argument to this syscall so that an arbitrary number of file descriptors > > can be handed out from user space to the kernel. > > > > See the background [1]. > > > > Please note that the new interface looks quite similar to the current > > system call, but that it won't always mean that it provides the "binary > > compatibility." > > > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html > > So this design is wrong. The kernel already has the device tree blob, > you should not be extracting it from the kernel munging it, and then > reinserting it in the kernel if you want signatures and everything to > pass. I don't understand how the kernel signature will be invalidated. There are some types of boot images that can embed a device tree blob in them, but the kernel can also be handed a separate device tree blob from firmware, the boot loader, or kexec. This latter case is what we are discussing, so we are not talking about modifying an embedded blob in the kernel image. > What x86 does is pass it's equivalent of the device tree blob from one > kernel to another directly and behind the scenes. It does not go > through userspace for this. > > Until a persuasive case can be made for going around the kernel and > probably adding a feature (like code execution) that can be used to > defeat the signature scheme I am going to nack this. I also don't understand what you mean by code execution. How does passing a device tree blob via kexec enables code execution? How can the signature scheme be defeated? -- []'s Thiago Jung Bauermann IBM Linux Technology Center