Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.
> zImage on ppc64 BE is an ELF32 file. This patch set only supports loading > ELF files of the same class as the kernel, so a 64 bit kernel can't load an > ELF32 file. It would be possible to add such support, but it would be a new > feature. > > The distros I was able to check on ppc64 LE and BE all use vmlinux. > kexec-tools with kexec_load also doesn't support zImage. Do you think it is > important to support zImage? > Well if it didn't work already, I think its low priority. Michael should be able to confirm this. Oliver's been trying to cleanup the zImage to get rid the old zImage limitation, cc'ing him Balbir Singh ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.
On 17/08/16 04:49, Thiago Jung Bauermann wrote: > Am Dienstag, 16 August 2016, 16:15:55 schrieb Balbir Singh: >> On 16/08/16 00:49, Thiago Jung Bauermann wrote: >>> Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh: >>>> On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann wrote: >>>>> Adapt all callers to the new function prototype. >>>> >>>> Could you please expand on this? >>> >>> Is the following better? >>> >>> Adapt all callers to set up a kexec_buf to pass to kexec_add_buffer. >> >> Yes and the reason for doing so? Consolidation/clarity of implementation? > > Indeed. What about this commit message? > > Subject: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take > kexec_buf as argument. > > This is done to simplify the kexec_add_buffer argument list. > Adapt all callers to set up a kexec_buf to pass to kexec_add_buffer. > > In addition, change the type of kexec_buf.buffer from char * to void *. > There is no particular reason for it to be a char *, and the change > allows us to get rid of 3 existing casts to char * in the code. > > Signed-off-by: Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> > Acked-by: Dave Young <dyo...@redhat.com> > Acked-by: Balbir Singh <bsinghar...@gmail.com> > Looks good Balbir ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.
On 16/08/16 09:25, Thiago Jung Bauermann wrote:
> Am Montag, 15 August 2016, 17:46:34 schrieb Balbir Singh:
>> On Thu, Aug 11, 2016 at 08:08:09PM -0300, Thiago Jung Bauermann wrote:
>>> +/**
>>> + * elf64_apply_relocate_add - apply 64 bit RELA relocations
>>> + * @elf_info: Support information for the ELF binary being
> relocated.
>>> + * @strtab:String table for the associated symbol
> table.
>>> + * @symindex: Section header index for the associated
> symbol table.
>>> + * @relsec:Section header index for the relocations to
> apply.
>>> + * @obj_name: The name of the ELF binary, for information
> messages.
>>> + */
>>> +int elf64_apply_relocate_add(const struct elf_info *elf_info,
>>> +const char *strtab, unsigned int symindex,
>>> +unsigned int relsec, const char *obj_name)
>>> +{
>>> + unsigned int i;
>>> + Elf64_Shdr *sechdrs = elf_info->sechdrs;
>>> + Elf64_Rela *rela = (void *)sechdrs[relsec].sh_addr;
>>> + Elf64_Sym *sym;
>>> + unsigned long *location;
>>> + unsigned long value;
>>> +
>>
>> For the relocatable kernel we expect only
>>
>> R_PPC64_RELATIVE
>> R_PPC64_NONE
>> R_PPC64_ADDR64
>>
>> In the future we can use this to check/assert the usage of this
>> for the core kernel (vmlinux) when loaded.
>>
>> Did we check elf64_apply_relocate_add with zImage and vmlinux?
>
> kexec_file_load doesn't call call elf64_apply_relocate_add on the kernel
> image, it only uses it to relocate the purgatory. So whether it is loading a
> zImage or a vmlinux file, the function will work in the same way since the
> purgatory binary is the same regardless of the kernel image format.
Thanks for clarifying.
>
> For the same reason, as it currently stands kexec_file_load can't check the
> relocation types used in the kernel image. But it is possible to add such a
> check/assertion in kexec_elf_64.c:build_elf_exec_info if we want.
>
> I tested kexec_file_load on both relocatable and non-relocatable vmlinux and
> it works correctly.
>
> I hadn't tested with zImage yet. I just did, and I had two problems:
>
> 1. For some reason, it has an INTERP segment. This patch series doesn't
> support loading program interpreters for ELF binaries, so
> kexec_elf_64.c:build_elf_exec_info refuses to load them.
>
> 2. If I disable the check for the INTERP segment, the zImage file loads
> correctly, but then I get an exception during reboot when loading the kexec
> image, right before jumping into the purgatory. I suspect this is because
> the LOAD segment has a virtual address of 0, and the first kernel is not
> coping well with that. But I still have to debug it further.
>
> Is there a reason for the zImage ELF header to request an interpreter and to
> have a virtual address of 0?
>
Not that I am aware of.
Balbir Singh
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.
On 16/08/16 00:49, Thiago Jung Bauermann wrote: > Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh: >> On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann wrote: >>> Adapt all callers to the new function prototype. >> >> Could you please expand on this? > > Is the following better? > > Adapt all callers to set up a kexec_buf to pass to kexec_add_buffer. Yes and the reason for doing so? Consolidation/clarity of implementation? > >> Looks good otherwise >> >> Acked-by: Balbir Singh <bsinghar...@gmail.com> > > Thank you for reviewing this series! > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.
+ 0x8000)
>
> #ifndef __powerpc64__
> /*
> @@ -33,8 +40,7 @@ struct ppc_plt_entry {
>
> struct mod_arch_specific {
> #ifdef __powerpc64__
> - unsigned int stubs_section; /* Index of stubs section in module */
> - unsigned int toc_section; /* What section is the TOC? */
> + struct elf_info elf_info;
> bool toc_fixed; /* Have we fixed up .TOC.? */
> #ifdef CONFIG_DYNAMIC_FTRACE
> unsigned long toc;
> @@ -90,6 +96,10 @@ static inline int module_finalize_ftrace(struct module
> *mod, const Elf_Shdr *sec
> }
> #endif
>
> +unsigned long stub_for_addr(const struct elf_info *elf_info, unsigned long
> addr,
> + const char *obj_name);
> +int restore_r2(u32 *instruction, const char *obj_name);
> +
> struct exception_table_entry;
> void sort_ex_table(struct exception_table_entry *start,
> struct exception_table_entry *finish);
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index b2027a5cf508..e38aace0a6e7 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -123,6 +123,10 @@ ifneq ($(CONFIG_PPC_INDIRECT_PIO),y)
> obj-y+= iomap.o
> endif
>
> +ifeq ($(CONFIG_MODULES)$(CONFIG_WORD_SIZE),y64)
> +obj-y+= elf_util_64.o
> +endif
> +
> obj64-$(CONFIG_PPC_TRANSACTIONAL_MEM)+= tm.o
>
> obj-$(CONFIG_PPC64) += $(obj64-y)
> diff --git a/arch/powerpc/kernel/elf_util_64.c
> b/arch/powerpc/kernel/elf_util_64.c
> new file mode 100644
> index ..decad2c34f38
> --- /dev/null
> +++ b/arch/powerpc/kernel/elf_util_64.c
> @@ -0,0 +1,269 @@
> +/*
> + * Utility functions to work with ELF files.
> + *
> + * Copyright (C) 2016, IBM Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2, or (at your option)
> + * any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +
> +/*
> + * We just need to use the functions defined in , so just
> declare
> + * struct module here and avoid having to import .
> + */
> +struct module;
> +#include
> +
> +#ifdef PPC64_ELF_ABI_v2
> +/* PowerPC64 specific values for the Elf64_Sym st_other field. */
> +#define STO_PPC64_LOCAL_BIT 5
> +#define STO_PPC64_LOCAL_MASK (7 << STO_PPC64_LOCAL_BIT)
> +#define PPC64_LOCAL_ENTRY_OFFSET(other)
> \
> + (((1 << (((other) & STO_PPC64_LOCAL_MASK) >> STO_PPC64_LOCAL_BIT)) >> 2) <<
> 2)
> +
> +static unsigned int local_entry_offset(const Elf64_Sym *sym)
> +{
> + /* sym->st_other indicates offset to local entry point
> + * (otherwise it will assume r12 is the address of the start
> + * of function and try to derive r2 from it). */
> + return PPC64_LOCAL_ENTRY_OFFSET(sym->st_other);
> +}
> +#else
> +static unsigned int local_entry_offset(const Elf64_Sym *sym)
> +{
> + return 0;
> +}
> +#endif
> +
> +#ifdef CC_USING_MPROFILE_KERNEL
> +/*
> + * In case of _mcount calls, do not save the current callee's TOC (in r2)
> into
> + * the original caller's stack frame. If we did we would clobber the saved
> TOC
> + * value of the original caller.
> + */
> +static void squash_toc_save_inst(const char *name, unsigned long addr)
> +{
> + struct ppc64_stub_entry *stub = (struct ppc64_stub_entry *)addr;
> +
> + /* Only for calls to _mcount */
> + if (strcmp("_mcount", name) != 0)
> + return;
> +
> + stub->jump[2] = PPC_INST_NOP;
> +}
> +#else
> +static void squash_toc_save_inst(const char *name, unsigned long addr) { }
> +#endif
> +
> +/**
> + * elf64_apply_relocate_add - apply 64 bit RELA relocations
> + * @elf_info:Support information for the ELF binary being
> relocated.
> + * @strtab: String table for the associated symbol table.
> + * @symindex:Section header index for the associated symbol
> table.
> + * @relsec: Section header index for the relocations to apply.
> + * @obj_name:The name of the ELF binary, for information
> messages.
> + */
> +int elf64_apply_relocate_add(const struct elf_info *elf_info,
> + const char *strtab, unsigned int symindex,
> + unsigned int relsec, const char *obj_name)
> +{
> + unsigned int i;
> + Elf64_Shdr *sechdrs = elf_info->sechdrs;
> + Elf64_Rela *rela = (void *)sechdrs[relsec].sh_addr;
> + Elf64_Sym *sym;
> + unsigned long *location;
> + unsigned long value;
> +
For the relocatable kernel we expect only
R_PPC64_RELATIVE
R_PPC64_NONE
R_PPC64_ADDR64
In the future we can use this to check/assert the usage of this
for the core kernel (vmlinux) when loaded.
Did we check elf64_apply_relocate_add with zImage and vmlinux?
Balbir Singh
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.
On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann wrote: > Adapt all callers to the new function prototype. > Could you please expand on this? > In addition, change the type of kexec_buf.buffer from char * to void *. > There is no particular reason for it to be a char *, and the change > allows us to get rid of 3 existing casts to char * in the code. > > Signed-off-by: Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> > Acked-by: Dave Young <dyo...@redhat.com> > --- Looks good otherwise Acked-by: Balbir Singh <bsinghar...@gmail.com> ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 01/13] kexec_file: Allow arch-specific memory walking for kexec_add_buffer
On Thu, Aug 11, 2016 at 08:08:06PM -0300, Thiago Jung Bauermann wrote: > Allow architectures to specify a different memory walking function for > kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but > PowerPC uses the memblock subsystem. > > Signed-off-by: Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> > Acked-by: Dave Young <dyo...@redhat.com> > --- Acked-by: Balbir Singh <bsinghar...@gmail.com> ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/7] ima: carry the measurement list across kexec
On 09/08/16 22:36, Mimi Zohar wrote: > On Tue, 2016-08-09 at 15:19 +1000, Balbir Singh wrote: >> >> On 04/08/16 22:24, Mimi Zohar wrote: >>> The TPM PCRs are only reset on a hard reboot. In order to validate a >>> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list >>> of the running kernel must be saved and then restored on the subsequent >>> boot. >>> >>> The existing securityfs binary_runtime_measurements file conveniently >>> provides a serialized format of the IMA measurement list. This patch >>> set serializes the measurement list in this format and restores it. >>> >>> This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer >>> hand-over for the next kernel" patch set* for actually carrying the >>> serialized measurement list across the kexec. >>> >>> Mimi >>> >> >> Hi, Mimi >> >> I am trying to convince myself of the security of the solution. I asked >> Thiago as well, but may be I am be lagging behind in understanding. >> >> We trust the kernel to hand over PCR values of the old kernel (which >> cannot be validated) to the IMA subsystem in the new kernel for storage. >> I guess the idea is for ima_add_boot_aggregate to do the right thing? >> How do we validate what the old kernel is giving us? Why do we care for >> the old measurement list? Is it still of significance in the new kernel? >> > > Hi Balbir, > > To validate the hardware TPM PCR values requires walking the measurement > list simulating the TPM extend operation. The resulting values should > match the hardware TPM PCRs. > > In the case of a soft reboot, the TPM PCRs are not reset to 0, so all > the measurements of the running system, including those from previous > soft reboots, need to be included in the measurement list. Without > these measurements, the simulated PCR values will not match the hardware > TPM PCR values. Thus the need for this patch set. > > Measurements can not be added/removed/changed in the measurement list > without it being detectable. > Thanks Mimi I think that makes sense So effectively we do first kernel boot -> second kernel boot -> and so on Balbir Singh ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/7] ima: carry the measurement list across kexec
On 04/08/16 22:24, Mimi Zohar wrote: > The TPM PCRs are only reset on a hard reboot. In order to validate a > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list > of the running kernel must be saved and then restored on the subsequent > boot. > > The existing securityfs binary_runtime_measurements file conveniently > provides a serialized format of the IMA measurement list. This patch > set serializes the measurement list in this format and restores it. > > This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer > hand-over for the next kernel" patch set* for actually carrying the > serialized measurement list across the kexec. > > Mimi > Hi, Mimi I am trying to convince myself of the security of the solution. I asked Thiago as well, but may be I am be lagging behind in understanding. We trust the kernel to hand over PCR values of the old kernel (which cannot be validated) to the IMA subsystem in the new kernel for storage. I guess the idea is for ima_add_boot_aggregate to do the right thing? How do we validate what the old kernel is giving us? Why do we care for the old measurement list? Is it still of significance in the new kernel? Balbir Singh. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC 0/3] extend kexec_file_load system call
>>>>> >>>>> Command line options are not signed. I thought idea behind secureboot >>>>> was to execute only trusted code and command line options don't enforce >>>>> you to execute unsigned code. >>>>> >> >> You can set module.sig_enforce=0 and open up the system a bit assuming >> that you can get a module to load with another attack > > IIUC, sig_enforce bool_enable_only so it can only be enabled. Default > value of it is 0 if CONFIG_MODULE_SIG_FORCE=n. > > IOW, if your kernel forced signature verification, you should not be > able to do sig_enforce=0. If you kernel did not have > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway > and you are not making it worse using command line. > OK.. I checked and you are right, but that is an example and there are other things like security=, thermal.*, nosmep, nosmap that need auditing for safety and might hurt the system security if used. I still think think that assuming you can pass any command line without breaking security is a broken argument. >> >>>>> So it sounds like different class of security problems which you are >>>>> referring to and not necessarily covered by secureboot or signed >>>>> kernel. >>>> Let me give you an example. >>>> >>>> You have a secure boot setup, where the firmware/ROM validates the boot >>>> loader. Good, the boot loader hasn't been tampered with. >>>> >>>> You interrupt the boot loader and are able to modify the command line >>>> for the booted kernel. >>>> >>>> The boot loader loads the kernel and verifies the kernel's signature. >>>> Good, the kernel hasn't been tampered with. The kernel starts running. >>>> >>>> You've plugged in a USB drive to the device, and specified a partition >>>> containing a root filesystem that you control to the kernel. The >>>> validated kernel finds the USB drive, and mounts it, and executes >>>> your own binaries on the USB drive. >>> You will require physical access to the machine to be able to >>> insert your usb drive. And IIRC, argument was that if attacker has >>> physical access to machine, all bets are off anyway. >>> >> >> You don't need physical access -- your machine controller BMC can >> do the magic for you. So its not always physical access, is it? > > Well, idea was that if you have physical access to machine, then all > bets are off. If BMC can do something which allows running unsigned > code at ring level 0, its a problem I think from secureboot model of > security. > >> >>>> >>>> >>>> You run a shell on the console. You now have control of the system, >>>> and can mount the real rootfs, inspect it, and work out what it does, >>>> etc. >>>> >>>> At this point, what use was all the validation that the secure boot >>>> has done? Absolutely useless. >>>> >>>> If you can change the command line arguments given to the kernel, you >>>> have no security, no matter how much you verify signatures. It's >>>> the illusion of security, nothing more, nothing less. >>>> >> >> I agree, if you can change command line arguments, all bets are of lesser >> value > > If changing command line allows execution of unsigned code at ring level > 0, then it is a problem. Otherwise we are talking of security issues which > are not covered by secure I agree that from what I can see/grep there is nothing that allows unsigned code to run at boot in ring0, but there are implications like the ones I've mentioned above. Attacks are typically built as a chain and every bit might matter. One could turn off features that might lead to the system being attacked at run-time Balbir Singh. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC 0/3] extend kexec_file_load system call
On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > > > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > > > > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > > > > > > > Indeed - maybe Eric knows better, but I can't see any situation where > > > > the dtb we load via kexec should ever affect "the bootloader", unless > > > > the "kernel" that's being loaded into kexec is "the bootloader". > > > > > > > > Now, going back to the more fundamental issue raised in my first reply, > > > > about the kernel command line. > > > > > > > > On x86, I can see that it _is_ possible for userspace to specify a > > > > command line, and the kernel loading the image provides the command > > > > line to the to-be-kexeced kernel with very little checking. So, if > > > > your kernel is signed, what stops the "insecure userspace" loading > > > > a signed kernel but giving it an insecure rootfs and/or console? > > > It is not kexec specific. I could do this for regular boot too, right? > > > > > > Command line options are not signed. I thought idea behind secureboot > > > was to execute only trusted code and command line options don't enforce > > > you to execute unsigned code. > > > You can set module.sig_enforce=0 and open up the system a bit assuming that you can get a module to load with another attack > > > So it sounds like different class of security problems which you are > > > referring to and not necessarily covered by secureboot or signed > > > kernel. > > Let me give you an example. > > > > You have a secure boot setup, where the firmware/ROM validates the boot > > loader. Good, the boot loader hasn't been tampered with. > > > > You interrupt the boot loader and are able to modify the command line > > for the booted kernel. > > > > The boot loader loads the kernel and verifies the kernel's signature. > > Good, the kernel hasn't been tampered with. The kernel starts running. > > > > You've plugged in a USB drive to the device, and specified a partition > > containing a root filesystem that you control to the kernel. The > > validated kernel finds the USB drive, and mounts it, and executes > > your own binaries on the USB drive. > You will require physical access to the machine to be able to > insert your usb drive. And IIRC, argument was that if attacker has > physical access to machine, all bets are off anyway. > You don't need physical access -- your machine controller BMC can do the magic for you. So its not always physical access, is it? > > > > > > You run a shell on the console. You now have control of the system, > > and can mount the real rootfs, inspect it, and work out what it does, > > etc. > > > > At this point, what use was all the validation that the secure boot > > has done? Absolutely useless. > > > > If you can change the command line arguments given to the kernel, you > > have no security, no matter how much you verify signatures. It's > > the illusion of security, nothing more, nothing less. > > I agree, if you can change command line arguments, all bets are of lesser value Balbir Singh ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC
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. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC
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 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC
On Tue, 21 Jun 2016 16:48:32 -0300 Thiago Jung Bauermann <bauer...@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 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: Kdump with signed images
On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? Probably, worth trying. Balbir Singh ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
