Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1428116 > unrolled thread

[PATCH v3 0/9] kexec_file_load implementation for PowerPC

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/9] kexec_file_load implementation for PowerPC Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-21 21:50 +0200
    [PATCH v3 9/9] powerpc: Add purgatory for kexec_file_load implementation. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-21 21:50 +0200
    [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-21 22:00 +0200
      Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Dave Young <dyoung@redhat.com> - 2016-06-22 12:30 +0200
        Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-23 01:40 +0200
          Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Dave Young <dyoung@redhat.com> - 2016-06-23 04:30 +0200
            Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-29 00:20 +0200
              Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Dave Young <dyoung@redhat.com> - 2016-06-29 21:50 +0200
                Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-29 23:30 +0200
                  Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Dave Young <dyoung@redhat.com> - 2016-06-30 17:10 +0200
                    Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-30 18:00 +0200
                      Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-30 21:20 +0200
                        Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Dave Young <dyoung@redhat.com> - 2016-06-30 23:50 +0200
                          Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-01 20:00 +0200
                            Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Dave Young <dyoung@redhat.com> - 2016-07-01 20:50 +0200
                              Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-01 22:20 +0200
                                Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-02 03:30 +0200
                                  Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer. Dave Young <dyoung@redhat.com> - 2016-07-05 03:00 +0200
    [PATCH v3 4/9] powerpc: Factor out relocation code from module_64.c to elf_util_64.c. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-21 22:00 +0200
    [PATCH v3 5/9] powerpc: Generalize elf64_apply_relocate_add. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-21 22:00 +0200
    [PATCH v3 7/9] powerpc: Implement kexec_file_load. Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-21 22:00 +0200
    Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Balbir Singh <bsingharora@gmail.com> - 2016-06-22 15:40 +0200
      Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-22 19:10 +0200
        Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Balbir Singh <bsingharora@gmail.com> - 2016-06-23 02:00 +0200
          Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-23 18:50 +0200
            Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Balbir Singh <bsingharora@gmail.com> - 2016-06-24 00:40 +0200
              Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-06-24 01:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1428124 — [PATCH v3 7/9] powerpc: Implement kexec_file_load.

Adds the basic machinery needed by kexec_file_load.

Signed-off-by: Josh Sklar <sklar@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: kexec@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/powerpc/Kconfig                   | 13 +++++++++
 arch/powerpc/include/asm/systbl.h      |  1 +
 arch/powerpc/include/asm/unistd.h      |  2 +-
 arch/powerpc/include/uapi/asm/unistd.h |  1 +
 arch/powerpc/kernel/machine_kexec_64.c | 50 ++++++++++++++++++++++++++++++++++
 5 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 01f7464d9fea..3ed5770b89e4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -457,6 +457,19 @@ config KEXEC
 	  interface is strongly in flux, so no good recommendation can be
 	  made.
 
+config KEXEC_FILE
+	bool "kexec file based system call"
+	select KEXEC_CORE
+	select BUILD_BIN2C
+	depends on PPC64
+	depends on CRYPTO=y
+	depends on CRYPTO_SHA256=y
+	help
+	  This is a new version of the kexec system call. This call is
+	  file based and takes in file descriptors as system call arguments
+	  for kernel and initramfs as opposed to a list of segments as is the
+	  case for the older kexec call.
+
 config CRASH_DUMP
 	bool "Build a kdump crash kernel"
 	depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
index 2fc5d4db503c..4b369d83fe9c 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -386,3 +386,4 @@ SYSCALL(mlock2)
 SYSCALL(copy_file_range)
 COMPAT_SYS_SPU(preadv2)
 COMPAT_SYS_SPU(pwritev2)
+SYSCALL(kexec_file_load)
diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h
index cf12c580f6b2..a01e97d3f305 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -12,7 +12,7 @@
 #include <uapi/asm/unistd.h>
 
 
-#define NR_syscalls		382
+#define NR_syscalls		383
 
 #define __NR__exit __NR_exit
 
diff --git a/arch/powerpc/include/uapi/asm/unistd.h b/arch/powerpc/include/uapi/asm/unistd.h
index e9f5f41aa55a..2f26335a3c42 100644
--- a/arch/powerpc/include/uapi/asm/unistd.h
+++ b/arch/powerpc/include/uapi/asm/unistd.h
@@ -392,5 +392,6 @@
 #define __NR_copy_file_range	379
 #define __NR_preadv2		380
 #define __NR_pwritev2		381
+#define __NR_kexec_file_load	382
 
 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 50bf55135ef8..b242f2293a6e 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -31,6 +31,10 @@
 #include <asm/hw_breakpoint.h>
 #include <asm/asm-prototypes.h>
 
+#ifdef CONFIG_KEXEC_FILE
+static struct kexec_file_ops *kexec_file_loaders[] = { };
+#endif
+
 #ifdef CONFIG_PPC_BOOK3E
 int default_machine_kexec_prepare(struct kimage *image)
 {
@@ -427,3 +431,49 @@ static int __init export_htab_values(void)
 }
 late_initcall(export_htab_values);
 #endif /* CONFIG_PPC_STD_MMU_64 */
+
+#ifdef CONFIG_KEXEC_FILE
+int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
+				  unsigned long buf_len)
+{
+	int i, ret = -ENOEXEC;
+	struct kexec_file_ops *fops;
+
+	/* We don't support crash kernels yet. */
+	if (image->type == KEXEC_TYPE_CRASH)
+		return -ENOTSUPP;
+
+	for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
+		fops = kexec_file_loaders[i];
+		if (!fops || !fops->probe)
+			continue;
+
+		ret = fops->probe(buf, buf_len);
+		if (!ret) {
+			image->fops = fops;
+			return ret;
+		}
+	}
+
+	return ret;
+}
+
+void *arch_kexec_kernel_image_load(struct kimage *image)
+{
+	if (!image->fops || !image->fops->load)
+		return ERR_PTR(-ENOEXEC);
+
+	return image->fops->load(image, image->kernel_buf,
+				 image->kernel_buf_len, image->initrd_buf,
+				 image->initrd_buf_len, image->cmdline_buf,
+				 image->cmdline_buf_len);
+}
+
+int arch_kimage_file_post_load_cleanup(struct kimage *image)
+{
+	if (!image->fops || !image->fops->cleanup)
+		return 0;
+
+	return image->fops->cleanup(image->image_loader_data);
+}
+#endif /* CONFIG_KEXEC_FILE */
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1428796

On Tue, 21 Jun 2016 16:48:32 -0300
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote:

> Hello,
> 
> 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?


Balbir Singh

[toc] | [prev] | [next] | [standalone]

#1429005

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@linux.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

[toc] | [prev] | [next] | [standalone]

#1429349

On 23/06/16 03:02, Thiago Jung Bauermann wrote:
> Hello Balbir,
>
Hi Thiago
 
>>> 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.


What I meant was how does the new kernel know that the old kernel did not
cheat while passing on the values? I presume because we trust that kernel
via a signature.


and

How do we know the new kernel is safe to load - I guess via a signature that
the new kernel is signed with (assuming it is present in the key ring).

Balbir Singh

[toc] | [prev] | [next] | [standalone]

#1429980

Am Donnerstag, 23 Juni 2016, 09:57:51 schrieb Balbir Singh:
> On 23/06/16 03:02, Thiago Jung Bauermann wrote:
> >>> 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.
> 
> What I meant was how does the new kernel know that the old kernel did not
> cheat while passing on the values? I presume because we trust that kernel
> via a signature.

Sorry, I still don't understand your concern. What kind of cheating? Which 
values? If it's the values in the event log, there's no need to trust the 
old kernel. The new kernel knows that the old kernel didn't pass wrong 
measurement values in the event log because it can recalculate the PCR 
extend operations recorded in the log and compare the results of the replay 
with the current PCR values stored in the TPM device. If they match, then 
the event log is guaranteed to be correct. If they don't match, either the 
memory was corrupted somehow during the kexec process, or the old kernel 
tried to pass a falsified event log.

There's no known way to construct an alternative series of PCR extend 
operations that will result in the same final value in the PCR register of 
the TPM device. If you can do that, you discovered a hash collision attack 
on the SHA-1 or SHA-256 algorithms (depending on which algorithm is being 
used by IMA in the event log). Or a bug in the TPM device implementation.

> and
> 
> How do we know the new kernel is safe to load - I guess via a signature
> that the new kernel is signed with (assuming it is present in the key
> ring).

Correct. That goal is met by signature verification, not by integrity 
assurance.

I'll note that even with both of my patch series there's still code missing 
for kernel signature verification in PowerPC. I believe there's not a file 
format defined yet for how to store a signature in a PowerPC kernel image.

Integrity assurance doesn't depend on kernel signature verification though. 
There's value in both my patch series even without kernel signature 
verification support. They're complementary features.
 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

[toc] | [prev] | [next] | [standalone]

#1430225

On 24/06/16 02:44, Thiago Jung Bauermann wrote:
> Am Donnerstag, 23 Juni 2016, 09:57:51 schrieb Balbir Singh:
>> On 23/06/16 03:02, Thiago Jung Bauermann wrote:
>>>>> 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.
>>
>> What I meant was how does the new kernel know that the old kernel did not
>> cheat while passing on the values? I presume because we trust that kernel
>> via a signature.
> 
> Sorry, I still don't understand your concern. What kind of cheating? Which 
> values? If it's the values in the event log, there's no need to trust the 
> old kernel. The new kernel knows that the old kernel didn't pass wrong 
> measurement values in the event log because it can recalculate the PCR 
> extend operations recorded in the log and compare the results of the replay 
> with the current PCR values stored in the TPM device. If they match, then 
> the event log is guaranteed to be correct. If they don't match, either the 
> memory was corrupted somehow during the kexec process, or the old kernel 
> tried to pass a falsified event log.
> 

Yep, get it/got it. My concern was anything using passed on the values should
compare the results with the current PCR values.

BTW, what do we gain by passing the values if we are relying on the PCR registers
anyway, can't we directly read them off from there? Aren't we going to ready anyway
to compare, what does passing the values gain?

[snip]

>> and
>>
>> How do we know the new kernel is safe to load - I guess via a signature
>> that the new kernel is signed with (assuming it is present in the key
>> ring).
> 
> Correct. That goal is met by signature verification, not by integrity 
> assurance.
> 
> I'll note that even with both of my patch series there's still code missing 
> for kernel signature verification in PowerPC. I believe there's not a file 
> format defined yet for how to store a signature in a PowerPC kernel image.
> 
> Integrity assurance doesn't depend on kernel signature verification though. 
> There's value in both my patch series even without kernel signature 
> verification support. They're complementary features.
>  

Thanks for clarifying

Balbir Singh.

[toc] | [prev] | [next] | [standalone]

#1430250

Am Freitag, 24 Juni 2016, 08:33:24 schrieb Balbir Singh:
> On 24/06/16 02:44, Thiago Jung Bauermann wrote:
> > Sorry, I still don't understand your concern. What kind of cheating?
> > Which values? If it's the values in the event log, there's no need to
> > trust the old kernel. The new kernel knows that the old kernel didn't
> > pass wrong measurement values in the event log because it can
> > recalculate the PCR extend operations recorded in the log and compare
> > the results of the replay with the current PCR values stored in the TPM
> > device. If they match, then the event log is guaranteed to be correct.
> > If they don't match, either the memory was corrupted somehow during the
> > kexec process, or the old kernel tried to pass a falsified event log.
> 
> Yep, get it/got it. My concern was anything using passed on the values
> should compare the results with the current PCR values.
> 
> BTW, what do we gain by passing the values if we are relying on the PCR
> registers anyway, can't we directly read them off from there? Aren't we
> going to ready anyway to compare, what does passing the values gain?

The PCR values themselves change for reasons that the application/user may 
not care about. For example, just changing the order in which measurements 
are made changes the final value of the PCR, even if all the measurements 
themselves don't change. And in current multi-processor machines this order 
does change at each boot, so you can't rely on two boots of the same machine 
with the same software to have the same PCR values.

Also, you may want to verify only the measurement of one of the components 
and not care about the other components.

With an event log, you can verify the checksum of each measured component 
individually, and the PCR value serves to confirm that the event log is 
correct. Just having the final PCR value without the event log, you don't 
know which measurements were made.

> >> and
> >> 
> >> How do we know the new kernel is safe to load - I guess via a signature
> >> that the new kernel is signed with (assuming it is present in the key
> >> ring).
> > 
> > Correct. That goal is met by signature verification, not by integrity
> > assurance.
> > 
> > I'll note that even with both of my patch series there's still code
> > missing for kernel signature verification in PowerPC. I believe there's
> > not a file format defined yet for how to store a signature in a PowerPC
> > kernel image.
> > 
> > Integrity assurance doesn't depend on kernel signature verification
> > though. There's value in both my patch series even without kernel
> > signature verification support. They're complementary features.
> 
> Thanks for clarifying

Thank you for your interest.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web