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]
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

Powered by blists - more mailing lists