From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752103AbcGMNQ7 (ORCPT ); Wed, 13 Jul 2016 09:16:59 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:50126 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751531AbcGMNQn (ORCPT ); Wed, 13 Jul 2016 09:16:43 -0400 From: Arnd Bergmann To: Mark Rutland Cc: linuxppc-dev@lists.ozlabs.org, Dave Young , linux-arm-kernel@lists.infradead.org, bhe@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro , "Eric W. Biederman" , bauerman@linux.vnet.ibm.com, Vivek Goyal Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Wed, 13 Jul 2016 15:13:42 +0200 Message-ID: <7352796.seiSnHrYPy@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160713094127.GC14522@leverpostej> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <5352106.oQ0Ff9gWJA@wuerfel> <20160713094127.GC14522@leverpostej> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:FC4LTuYXXWyg44I1mYjh63KMHXiTABeH0z9bj0UWTxbwz6jHrMp MC6IdXpAfsPOu0G6N7+TbuSWkEnAtRY3uHS23HFzRJih5knzs0yQUOYRnX6U/at9ATSszq2 v/O9C0CEmWtNiUXRjxHlUbWwciHiMsSZxBO8zZE21+zpk07Eau0Ek40vThMph2sSxrMH2KD c4jh4Etm8BlSU8NmqCY+A== X-UI-Out-Filterresults: notjunk:1;V01:K0:+ToZplt77IM=:JtwNmhaSVlXk4HMRbpMug3 eHKsPFCykykNeJoqXhS15Owb30VOxQ9K3+a9P0/4RlCMPQbHkVSXLkB40ZuBWyu6JFRkKOt3L KhDTdm/eTGuN3/A7s3VmfThtIBucoALBTG6IWqvBrTHCh1SPuWVideqdOZnUTyqcw9/bGVJka Zo7Xn4wl0V0Xt3CBMA8G7QdHyk3vaMkxKjX99h0OhkF4SuUHH8lwRBasuwKWkRi5pIWRy49KP i4RsnROklzcZtpbPxDjlD/QEmVj4cPc6PawRfiB8SPZaA+lCWS1k7MtNgNWAAO3LR6cilb8zI Uuz91rqIUthKK5NFq4bfFyxbUfXIZycqsfydaLGVFM8yI/BiXwe9EHRS/yzaQtujOh7pvS+DG sTSygP3Ie8abi2r96T2NJso5kJg35c2dLi+Iq140D7hNLxDHLbqPp0qSi9diDFVy8m4rLODiS jLWi724K4DXSj1bt0S9AqhS/9QOilS7KT4d+lDQPr51iEYSFBGxJxhIvOjqS4emZoGR1NAFR0 avujNpvdqc1YrHz2AoQHKzYCFvZmMPMY0OPaDUupW2cHUEP6YpcHTPnFq9Gphj264w1lJWm5S b8iRR2XF3kr9WXvJrbRtJ7LGCIq7upr8GQ9JbsbvVoOLFtkTfb5TU/qT0U6S0PifBDQ9/Y1wU Oz4ZAmzZM0htKZ+fYA0pEjSAdrHPDyWdLcPdgROL/rEPef97PVEup3dnP8EsfhaM4/kkf8QHs gb206YauVUIM3s5Y Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > > > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived > > > > from the raw DTB (which is exposed at /sys/firmware/fdt). > > > > > > > > The blob that was handed to the kernel at boot time is exposed at > > > > /sys/firmware/fdt. > > > > > > I believe the blob can be read and passed to kexec kernel in kernel code without > > > the extra fd. > > > > > > But consider we can kexec to a different kernel and a different initrd so there > > > will be use cases to pass a total different dtb as well. From my understanding > > > it is reasonable but yes I think we should think carefully about the design. > > > > Ok, I can see four interesting use cases here: > > > > - Using the dtb that the kernel has saved at boot time. Ideally this should not > > require an additional step of signing it, since the running kernel already > > trusts it. > > We have sufficient information from the existing kexec_file_load syscall > prototype to do this in-kernel. Ok. > > - A dtb blob from the file system that was produced along with the kernel image. > > If we require a signature on the kernel, the the same requirement should be > > made on the dtb. Whoever signs the kernel can also sign the dtb. > > The tricky part here is the kernel command line that is part of the dtb > > and that may need to be modified. > > I suspect that for this case, following the example of the existing > sycall, we'd allow the kernel to modify bootargs and initrd properties > after verfiying the signature of the DTB. Makes sense. > The big question is whether this is a realistic case on a secure boot > system. What does x86 do here? I assume changes to the command line are also limited. > > - Modifying the dtb at for any of the reasons I listed: This should always > > be possible when we do not use secure boot, just like booting an unsigned > > kernel is. > > This is possible with the existing kexec_load syscall, for the non > secure boot case. Ok, let's skip that then. > > - kboot/petitboot with all of the user space being part of the trusted boot > > chain: it would be good to allow these to modify the dtb as needed without > > breaking the trust chain, just like we allow grub or u-boot to modify the dtb > > before passing it to the kernel. > > It depends on *what* we need to modify here. We can modify the bootargs > and initrd properties as part of the kexec_file_load syscall, so what > else would we want to alter? I guess petitboot can also just use kexec_load() instead of kexec_file_load(), as long as the initramfs containing petitboot is trusted by the kernel. Arnd