linux-kernel - Re: [PATCH v2 0/9] kexec_file_load implementation for PowerPC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <17475630.nMjKSPkg4b@hactar>
Date:	Thu, 16 Jun 2016 16:55:33 -0300
From:	Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>
To:	Michael Ellerman <mpe@...erman.id.au>
Cc:	linuxppc-dev@...ts.ozlabs.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/9] kexec_file_load implementation for PowerPC

Am Donnerstag, 16 Juni 2016, 15:48:30 schrieb Michael Ellerman:
> On Tue, 2016-06-14 at 11:59 -0300, Thiago Jung Bauermann wrote:
> > Hello,
> > 
> > This patch series implements the kexec_file_load system call on PowerPC.
> 
> Can you tell me what this syscall does and why I would want it?

Sorry, should have provided the motivation when I posted the patches.

This system call moves the reading of the kernel, initrd and the device tree 
from the userspace kexec tool to the kernel. This is needed if you want to 
do one or both of the following:

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.

The above are the functions kexec already has built into kexec_file_load. I 
will soon post a set of patches which will allow a third feature:

3. have IMA pass-on its event log (where integrity measurements are 
registered) accross kexec to the second kernel, so that the event history is 
preserved.

Because OpenPower uses an intermediary Linux instance as a boot loader 
(skiroot), feature 1 is needed to implement secure boot for the platform, 
while features 2 and 3 are needed to implement trusted boot.

There's an LWN article giving more context on the origins of the system 
call, if you are interested:

https://lwn.net/Articles/603116/

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center