Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1429349
| From | Balbir Singh <bsingharora@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC |
| Date | 2016-06-23 02:00 +0200 |
| Message-ID | <rN0dP-1Pz-7@gated-at.bofh.it> (permalink) |
| References | <rMzQl-1Gf-3@gated-at.bofh.it> <rMQxP-44t-7@gated-at.bofh.it> <rMTP4-6im-49@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[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
[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
csiph-web