From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751358AbcGNIdz (ORCPT ); Thu, 14 Jul 2016 04:33:55 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:58597 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750829AbcGNIa0 (ORCPT ); Thu, 14 Jul 2016 04:30:26 -0400 From: Arnd Bergmann To: Thiago Jung Bauermann Cc: Mark Rutland , 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" , Vivek Goyal , Mimi Zohar Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Thu, 14 Jul 2016 10:29:11 +0200 Message-ID: <4321972.HZgDox36RC@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1678419.ODVtyXKVYJ@hactar> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <5108278.va6WuahHro@wuerfel> <1678419.ODVtyXKVYJ@hactar> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:vFyjG0siK4eTT8M+8VcASPjd7pRalAoAkPDw2kxWsphyLZ1JSS6 Is0FU1tcGp4YpgcMVoDPDmkaRNZIH4gigTrly+RuM2K5TpM41s210yDg1VCgQT7FZPHEQQv i1HYHFHecMH5drZmjFvXzVsbD7A1X6WPSU7Q/4NU1yC8ows5GdMSEjE58bk7IRZv6qZeoma IdjS1FGn/eaiindbNFg8Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:D1QnuvK5WQo=:+vZyO723g9lQHkHk6n/3v6 ErBbOU0unjGPR7FgJbpVzq/5AM/ERP/BeL8bbmJVi4nSy2mclRpWLcVqyM0p8C+FiYqVa5TYB Suw08tBTNJuGZAJqcdRXuqY3aA6/nNM9Ur/w4gX9h7uzriB/dLIqi3u1DkzvIjnoFBmFECA3e +8fI8J2rd1aysl/7OOfFgFsMCXQSlxV3u1MyzWXoVduvFKV1YjdCCDhkp4EBoHVeTWssbbBR5 SkjzPqTUWHirwQJ/xQgYGGfGyJzE5HuleBwnVLmjFZGCDLupsQfVlReJMqs7qYYpjQRqMudLj 60BhwEm3fmzaX7sffftGic/zc1yNAaProSO6d6SILVLbrCeTMbabB+LOj5fJh0nf2s+0TDeaP +YolCWIlxmSFq4v6cGa7S8F4S0jokW3fY/oHrfMS/eAnvVhUe8zScIGuuSkObp1fB3H9uWBGp mGfmj9vqCnNldnnZzddOoowwuGjKeUp0VNcEkrDvQxO9nv/yyb2NdXzKKLTgQb5ceC61axZ38 jGpG2XM39F8eUOWEe0ie2kmSzSKG6ZHo+v4Fl0DWzovQaw0K9lp2y1f5rtoIhwfuN55TagqYH IrV2wsOuDW5KT8HVIcBsWKmq+X1ju1aKj6ka8CLl0xuq3VjLYArNDyWUNa5wMvd7GWeAzgRnP oYcyWS0Xp6CJhs6l1ebXmOVdjTCOzHKdyd11T9GV+AdEZjdofVZ5RteVc4uRuaCU6tFxRl8Sc ZVZWQcrYxNTI92W3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, July 13, 2016 11:18:04 PM CEST Thiago Jung Bauermann wrote: > Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann: > > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > > > > > For secure boot, Petitboot needs to use kexec_file_load, because of the > > > following two features which the system call enables: > > > > > > 1. only allow loading of signed kernels. > > > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel > > > > > > command line and other boot inputs for the Integrity Measurement > > > Architecture subsystem. > > > > > > Those can't be done with kexec_load. > > > > Can't petitboot do both of these in user space? > > To be honest I'm not sure if it *can't* be done from userspace but if you do > it from the kernel you can guarantee that any kernel image that is loaded > gets verified and measured. > > Whereas if you verify and measure the kernel in userspace then if there's a > vulnerability in the system which allows an attacker to upload their own > binary, then they can use kexec_load directly and bypass the verification > and measurement. > > So it's a more resilient design. Right, but the question remains whether this helps while you allow the boot loader to modify the dtb. If an attacker gets in and cannot modify the kernel or initid but can modify the DT, a successful attack would be a bit harder than having a modified kernel, but you may still need to treat the system as compromised. Arnd