From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754215AbcGLOFe (ORCPT ); Tue, 12 Jul 2016 10:05:34 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:51909 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751335AbcGLOFb (ORCPT ); Tue, 12 Jul 2016 10:05:31 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: "Eric W. Biederman" , AKASHI Takahiro , bhe@redhat.com, linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, bauerman@linux.vnet.ibm.com, dyoung@redhat.com, vgoyal@redhat.com Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Tue, 12 Jul 2016 16:02:46 +0200 Message-ID: <1911992.H2WpLRr2Fi@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:dF/8ltE71cerD3f6qCRGqN8sIWxYbc/7ULljfRnWlZkqkl/4FPg bh5s71BklCBQyDKTjvMXf+YGEtnEBItERgytnfz6wgHwSKnUKQ+4/7gob5lD/gQnqDL01Oe KknzMWeCLFRMMoFvTAM1t6GfqXv9cAK37qRuRi3R5k9DbCkQCbcWvn9SVruYrjJx8j1XBNv yWX9xf7uneliMiCU7lS3g== X-UI-Out-Filterresults: notjunk:1;V01:K0:hW3hZn+7jLs=:OSdtz0IsSzP6McAyg9XXue 9YoSj5Yil6Am6J7q37liiuT4J837UrDvEi2HTFrg4yAW1O8PKkLC22hXupkebvgvAEe+QHEP2 I9xkANoYVieLZlXfgaa1NXsK3nmtN1Y0gwsYbCkiq3h+1viQvDQCkCkThB5DUPaDCRPOv3qVx PYvbApJHwO2N6K8JRWsExYF0ltC85XXTA3jFHT9wVsgN2it6ycnDu5ZDc3i1ZpXqAtttMjAPo lxNDHn2iwjZ4jdpACB8PYx1KYkB94NXM+v/H7qkVktzKWtIdQlF/3jwD8hrPA5HAwP0mvB1wJ lek0iqEuKuHrzpoQWkWlrxwI8WQDe49Y8frBuRLhedy8/Fmbbboh8Vf8SRp+NJF5M0hwYoXDh gzYGZN8kEhS0wWw7ceR1+WAN8MdLfto41RXDWCbKOZTiME5vj1wKf2iqUUBn90aYarV383ZOo yJKoR5d/8O0JTBtFaFqbIwRSh0j8SvAvuGwnxZtLWcZ513FhYQovpLYCVq22DMuX9HSGCqm+3 0sOaxfAW4l85obl5E8wrkNfNj7zuFJeVQno+lQv4yfDbp/q+zi5Zyno+uPslPCgUGn57cyrlF yxpMDNhhePNDw/lyv7uj+XnfpUVjRJUegcRljLAsZ4GgZDWmITiPywYnSNhLovK9j+LzJYOM6 XhftNmElfpBkMPa4u4Yr1+/Hs3pPviqQVFO38+kIRkYMBbgx2i3eRx5EHrRpgMqnG8Xyl+alq 9mz6W+aXSRuJCnAq Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, July 12, 2016 8:25:48 AM CEST Eric W. Biederman wrote: > 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. > > 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. > > Nacked-by: "Eric W. Biederman" > > I am happy to see support for other architectures, but for the sake of > not moving some code in the kernel let's not build an attackable > infrastructure. > For historic context, the flattened devicetree format that we now use to pass data about the system from boot loader to kernel was initially introduced specifically for the purpose of enabling kexec: On Open Firmware, the DT is extracted from running firmware and copied into dynamically allocated data structures. After a kexec, the runtime interface to the firmware is not available, so the flattened DT format was created as a way to pass the same data in a binary blob to the new kernel in a format that can be read from the kernel by walking the directories in /proc/device-tree/*. There are a couple of reasons for modifying the devicetree: - For kboot/petitboot, you can have a kernel that is not booted through DT at all but hardwired to a particular machine, and that passes a DT for the entire hardware to the kernel that you actually want to run. - for kdump, you need to tell the new kernel about the modified location of the memory, so the dump kernel doesn't overwrite the contents it wants to dump - we typically ship devicetree sources for embedded machines with the kernel sources. As more hardware of the system gets enabled, the devicetree gains extra nodes and properties that describe the hardware more completely, so we need to use the latest DT blob to use all the drivers - in some cases, kernels will fail to boot at all with an older version of the DT, or fail to use the devices that were working on the earlier kernel. This is usually considered a bug, but it's not rare - In some cases, the kernel can update its DT at runtime, and the new settings are expected to be available in the new kernel too, though there are cases where you actually don't want the modified contents. Arnd