linux-kernel - Re: [PATCH v3 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 22 Jun 2016 14:02:45 -0300
From:	Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>
To:	Balbir Singh <bsingharora@...il.com>
Cc:	linuxppc-dev@...ts.ozlabs.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

Hello Balbir,

Am Mittwoch, 22 Juni 2016, 23:29:46 schrieb Balbir Singh:
> On Tue, 21 Jun 2016 16:48:32 -0300
> Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com> wrote:
> > This patch series implements the kexec_file_load system call on
> > PowerPC.
> > 
> > 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. Yesterday I posted a set of patches which allows 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.
> 
> OK.. and this is safe? Do both the kernels need to be signed by the
> same certificate?

They don't. The integrity of the event log (assuming that is what you mean 
by "this" in "this is safe") is guaranteed by the TPM device. Each event in 
the measurement list extends a PCR and records its PCR value. It is 
cryptographically guaranteed that if you replay the PCR extends recorded in 
the event log and in the end of the process they match the current PCR 
values in the TPM device, then that event log is correct.

The kernel signature serves to ensure that you only run kernels from an 
authorized provider. It doesn't play a role in integrity assurance, which 
aims to verify that the machine is really running the code it says it is 
running. As I understand it, at least. It's a bit subtle and I could be 
missing something...

[]'s
Thiago Jung Bauermann
IBM Linux Technology Center