[PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting

[PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting

[Dave Young]

In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve
the acpi root table physical address.

Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab
If there's no such file or read fail the function will just do nothing.

Tested efi boot Fedora 17 on thinkpad T420.

Some background info for this issue:
http://lists.infradead.org/pipermail/kexec/2010-March/003889.html

[v1 -> v2]:
Address comments from Khalid and Simon
use fgets instead of read(2) to iterate the file
do not add 'noefi' because kexec does not construct EFI signature
in bootloader signature in boot_params, so kexec'd kernel will
disable EFI automatically even without noefi.

Signed-off-by: Dave Young <dyoung@redhat.com>
---
 kexec/arch/i386/crashdump-x86.c |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

--- kexec-tools.orig/kexec/arch/i386/crashdump-x86.c
+++ kexec-tools/kexec/arch/i386/crashdump-x86.c
@@ -835,6 +835,40 @@ static int cmdline_add_memmap_acpi(char 
 	return 0;
 }
 
+/* Appends 'acpi_rsdp=' commandline for efi boot crash dump */
+static void cmdline_add_efi(char *cmdline)
+{
+	FILE *fp;
+	int cmdlen, len;
+	char line[MAX_LINE], *s;
+	const char *acpis = " acpi_rsdp=";
+
+	fp = fopen("/sys/firmware/efi/systab", "r");
+	if (!fp)
+		return;
+
+	while(fgets(line, sizeof(line), fp) != 0) {
+		/* ACPI20= always goes before ACPI= */
+		if ((strstr(line, "ACPI20=")) || (strstr(line, "ACPI="))) {
+		        line[strlen(line) - 1] = '\0';
+			s = strchr(line, '=');
+			s += 1;
+			len = strlen(s) + strlen(acpis);
+			cmdlen = strlen(cmdline) + len;
+			if (cmdlen > (COMMAND_LINE_SIZE - 1))
+				die("Command line overflow\n");
+			strcat(cmdline, acpis);
+			strcat(cmdline, s);
+			dbgprintf("Command line after adding efi\n");
+			dbgprintf("%s\n", cmdline);
+
+			break;
+		}
+	}
+
+	fclose(fp);
+}
+
 static void get_backup_area(struct kexec_info *info,
 				struct memory_range *range, int ranges)
 {
@@ -998,6 +1032,7 @@ int load_crashdump_segments(struct kexec
 	if (delete_memmap(memmap_p, elfcorehdr, memsz) < 0)
 		return -1;
 	cmdline_add_memmap(mod_cmdline, memmap_p);
+	cmdline_add_efi(mod_cmdline);
 	cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
 
 	/* Inform second kernel about the presence of ACPI tables. */

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting

[Khalid Aziz]

On Thu, 2012-10-18 at 11:10 +0800, Dave Young wrote:
> In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve
> the acpi root table physical address.
> 
> Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab
> If there's no such file or read fail the function will just do nothing.
> 
> Tested efi boot Fedora 17 on thinkpad T420.
> 
> Some background info for this issue:
> http://lists.infradead.org/pipermail/kexec/2010-March/003889.html
> 
> [v1 -> v2]:
> Address comments from Khalid and Simon
> use fgets instead of read(2) to iterate the file
> do not add 'noefi' because kexec does not construct EFI signature
> in bootloader signature in boot_params, so kexec'd kernel will
> disable EFI automatically even without noefi.
> 
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
>  kexec/arch/i386/crashdump-x86.c |   35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)


Looks good.

Reviewed-by: Khalid Aziz <khalid@gonehiking.org>




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting

[Vivek Goyal]

On Thu, Oct 18, 2012 at 08:56:34AM -0600, Khalid Aziz wrote:
> On Thu, 2012-10-18 at 11:10 +0800, Dave Young wrote:
> > In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve
> > the acpi root table physical address.
> > 
> > Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab
> > If there's no such file or read fail the function will just do nothing.
> > 
> > Tested efi boot Fedora 17 on thinkpad T420.
> > 
> > Some background info for this issue:
> > http://lists.infradead.org/pipermail/kexec/2010-March/003889.html
> > 
> > [v1 -> v2]:
> > Address comments from Khalid and Simon
> > use fgets instead of read(2) to iterate the file
> > do not add 'noefi' because kexec does not construct EFI signature
> > in bootloader signature in boot_params, so kexec'd kernel will
> > disable EFI automatically even without noefi.
> > 
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> >  kexec/arch/i386/crashdump-x86.c |   35 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> 
> 
> Looks good.
> 
> Reviewed-by: Khalid Aziz <khalid@gonehiking.org>

Khalid/Dave,

Last time khalid mentioned that we are currently taking normal boot path
in second kernel and that's why things are working even without "noefi"?

If that's the case, then we don't need "acpi_rsdp" also? In normal boot
path we used to just pass acpi memmap ranges in e820 map and second
kernel could find those.

So now I am full confused that howcome we require acpi_rsdp but not
"noefi".

This UEFI thing is a mess. We need to sort it out. I am primarily
interested in making sure kdump works well with UEFI systems as more
and more systems are going to adopt UEFI. Also this UEFI secure boot
will make things very interesting. Now we can't trust the purgatory
code prepared in user space.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting

[Khalid Aziz]

On Thu, 2012-10-18 at 15:11 -0400, Vivek Goyal wrote:
> On Thu, Oct 18, 2012 at 08:56:34AM -0600, Khalid Aziz wrote:
> > On Thu, 2012-10-18 at 11:10 +0800, Dave Young wrote:
> > > In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve
> > > the acpi root table physical address.
> > > 
> > > Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab
> > > If there's no such file or read fail the function will just do nothing.
> > > 
> > > Tested efi boot Fedora 17 on thinkpad T420.
> > > 
> > > Some background info for this issue:
> > > http://lists.infradead.org/pipermail/kexec/2010-March/003889.html
> > > 
> > > [v1 -> v2]:
> > > Address comments from Khalid and Simon
> > > use fgets instead of read(2) to iterate the file
> > > do not add 'noefi' because kexec does not construct EFI signature
> > > in bootloader signature in boot_params, so kexec'd kernel will
> > > disable EFI automatically even without noefi.
> > > 
> > > Signed-off-by: Dave Young <dyoung@redhat.com>
> > > ---
> > >  kexec/arch/i386/crashdump-x86.c |   35 +++++++++++++++++++++++++++++++++++
> > >  1 file changed, 35 insertions(+)
> > 
> > 
> > Looks good.
> > 
> > Reviewed-by: Khalid Aziz <khalid@gonehiking.org>
> 
> Khalid/Dave,
> 
> Last time khalid mentioned that we are currently taking normal boot path
> in second kernel and that's why things are working even without "noefi"?
> 
> If that's the case, then we don't need "acpi_rsdp" also? In normal boot
> path we used to just pass acpi memmap ranges in e820 map and second
> kernel could find those.
> 
> So now I am full confused that howcome we require acpi_rsdp but not
> "noefi".
> 
> This UEFI thing is a mess. We need to sort it out. I am primarily
> interested in making sure kdump works well with UEFI systems as more
> and more systems are going to adopt UEFI. Also this UEFI secure boot
> will make things very interesting. Now we can't trust the purgatory
> code prepared in user space.
> 
> Thanks
> Vivek

Hi Vivek,

kdump works even without "noefi" because the kdump kernel automatically
boots up with EFI disabled as explained here -
<http://lists.infradead.org/pipermail/kexec/2012-September/006797.html>.
On a BIOS based or EFI based, but with CSM, systems, kdump kernel will
find RSDP by searching through Extended BIOS Data Area. I don't believe
EBDA exists on EFI systems without CSM, so kdump kernel will fail to
find RSDP. We will need to pass "acpi_rsdp=" for the benefit of those
systems, but those systems are also going to need fix in the bootloader
signature to boot kdump kernel in EFI mode.

Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes
life even more difficult. Matthew Garret had earlier sent out patches to
support SecureBoot on Linux and one of the things those patches did was
to disable kexec completely. That is a drastic measure and ok as a short
term solution but we need to come up with something better. If
SecureBoot does not go away, we will have to do something in kexec-tools
or even kernel to validate kernel code being loaded for kexec/kdump and
the purgatory code as well. This will require interfacing with UEFI key
checking mechanism. That is going to be ugly.

Thanks,
Khalid


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Thu, Oct 18, 2012 at 01:22:01PM -0600, Khalid Aziz wrote:

[..]
> Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes
> life even more difficult. Matthew Garret had earlier sent out patches to
> support SecureBoot on Linux and one of the things those patches did was
> to disable kexec completely. That is a drastic measure and ok as a short
> term solution but we need to come up with something better. If
> SecureBoot does not go away, we will have to do something in kexec-tools
> or even kernel to validate kernel code being loaded for kexec/kdump and
> the purgatory code as well. This will require interfacing with UEFI key
> checking mechanism. That is going to be ugly.

CCing Eric and Matthew Garret and hpa.

Ok, I will split this thread in two parts. Lets us quickly discuss
the UEFI secure boot also as it is happening soon. 

I was thinking that how about supporting in kernel bootloader. That is,
kernel acts as a boot loader. User passes the kernel, initrd and
commandline from user space using kexec system call and kernel parses
it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs,
backup region, elf header region etc). At the time of kexec -e, we just
follow th regular path and jump to second kernel.

At the time of loading, kernel can verify the signature of incoming
bzImage and reject it if signatures don't match. Matthew mentioned that
kernel signing certificate will be available inside the running kernel,
so verifying PE/COFF bzImage should be easy.

We don't have to worry about initramfs verification as it runs in 
user space.

There is one side issue of acpi_rsdp. Because second kernel executes
the code specified by acpi_rsdp, it is unsafe to let user specify
that location. Matthew metioned that figure a way out to pass acpi_rsdp
using boot params and drop it from command line.

Looking for thoughts and ideas on how to support kdump with UEFI
secureboot. (This is assuming that kdump already works with UEFI with
parameters "noefi" and "acpi_rsdp" in non secure boot mode).

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Matthew Garrett]

On Thu, Oct 18, 2012 at 03:38:31PM -0400, Vivek Goyal wrote:

> I was thinking that how about supporting in kernel bootloader. That is,
> kernel acts as a boot loader. User passes the kernel, initrd and
> commandline from user space using kexec system call and kernel parses
> it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs,
> backup region, elf header region etc). At the time of kexec -e, we just
> follow th regular path and jump to second kernel.
> 
> At the time of loading, kernel can verify the signature of incoming
> bzImage and reject it if signatures don't match. Matthew mentioned that
> kernel signing certificate will be available inside the running kernel,
> so verifying PE/COFF bzImage should be easy.

That all sounds fine to me.

> There is one side issue of acpi_rsdp. Because second kernel executes
> the code specified by acpi_rsdp, it is unsafe to let user specify
> that location. Matthew metioned that figure a way out to pass acpi_rsdp
> using boot params and drop it from command line.

That would just be a matter of adding it to the structure and modifying 
drivers/acpi/osl.c.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Oct 18, 2012 at 01:22:01PM -0600, Khalid Aziz wrote:
>
> [..]
>> Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes
>> life even more difficult. Matthew Garret had earlier sent out patches to
>> support SecureBoot on Linux and one of the things those patches did was
>> to disable kexec completely. That is a drastic measure and ok as a short
>> term solution but we need to come up with something better. If
>> SecureBoot does not go away, we will have to do something in kexec-tools
>> or even kernel to validate kernel code being loaded for kexec/kdump and
>> the purgatory code as well. This will require interfacing with UEFI key
>> checking mechanism. That is going to be ugly.
>
> CCing Eric and Matthew Garret and hpa.
>
> Ok, I will split this thread in two parts. Lets us quickly discuss
> the UEFI secure boot also as it is happening soon. 

Any fimware secure boot solution fundamentally is about having the
firmware not boot something that is not trusted.  This reduces the area
of attack in your firmware to your executable loader, your signature
verification code and the key itself.  Making your firmware and the
early parts of the boot process less susceptible to attack.  UEFI secure
boot seems to match that criteria.

I am happy to see a similar system implemented in the kernel for the
kexec boot path.

I do not support limiting that solution to UEFI systems or making the
jusficiation UEFI systems.  The code needs to make sense without any
UEFI justifications.

> I was thinking that how about supporting in kernel bootloader. That is,
> kernel acts as a boot loader. User passes the kernel, initrd and
> commandline from user space using kexec system call and kernel parses
> it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs,
> backup region, elf header region etc). At the time of kexec -e, we just
> follow th regular path and jump to second kernel.
>
> At the time of loading, kernel can verify the signature of incoming
> bzImage and reject it if signatures don't match. Matthew mentioned that
> kernel signing certificate will be available inside the running kernel,
> so verifying PE/COFF bzImage should be easy.

Except that we don't pass the executable file to the kernel.  That
approach was nixed in the early review of kexec.  So we either need to
find a way to trust the /sbin/kexec binary and do the signature
verification there on a per file type basis, or we need to pass an
additional signature along with the code (the signature would be encoded
with an extra kexec flag and a special purpose segment I expect).

If we pass the signature to the kernel for verification there are rough
bits like how do file formats with relocation entries, the purgatory
code, ramdisks, and kernel parameters.

> We don't have to worry about initramfs verification as it runs in 
> user space.

Except that we need a way to distinguish the initramfs and other data
the part that is signed.

> There is one side issue of acpi_rsdp. Because second kernel executes
> the code specified by acpi_rsdp, it is unsafe to let user specify
> that location. Matthew metioned that figure a way out to pass acpi_rsdp
> using boot params and drop it from command line.

The acpi_rsdp option is really orthogonal to this issue.  Since
everything comes from userspace the trust picture is essentially the
same (unless we can find a way to trust /sbin/kexec).

But specifically for acpi_rdsp if we can figure out how to successfully
use the EFI code path that should not be a problem.  For other code
paths shrug, that is a detail we should look at when we get there.

> Looking for thoughts and ideas on how to support kdump with UEFI
> secureboot. (This is assuming that kdump already works with UEFI with
> parameters "noefi" and "acpi_rsdp" in non secure boot mode).

We don't support kdump with UEFI secure boot.  We support kexec loading
signed images.  An important difference because it means that everyone
can benefit or not as they choose.

This leaves us with a couple of important questions to answer.
- How do we trust /sbin/kexec or how do we avoid the need to trust
  /sbin/kexec.
- Where is the root of trust located?
- How do we verify /sbin/kexec or do we verify /sbin/kexec.
- How do we verify the images we load?
- How do we separate code/data that needs trust from code/data that
  doesn't need trust?
- How does the design we pick reduce the amount of code we need to trust?

None of this is particularly hard but it all needs going through
carefully by someone who cares.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Thu, Oct 18, 2012 at 03:25:21PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Oct 18, 2012 at 01:22:01PM -0600, Khalid Aziz wrote:
> >
> > [..]
> >> Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes
> >> life even more difficult. Matthew Garret had earlier sent out patches to
> >> support SecureBoot on Linux and one of the things those patches did was
> >> to disable kexec completely. That is a drastic measure and ok as a short
> >> term solution but we need to come up with something better. If
> >> SecureBoot does not go away, we will have to do something in kexec-tools
> >> or even kernel to validate kernel code being loaded for kexec/kdump and
> >> the purgatory code as well. This will require interfacing with UEFI key
> >> checking mechanism. That is going to be ugly.
> >
> > CCing Eric and Matthew Garret and hpa.
> >
> > Ok, I will split this thread in two parts. Lets us quickly discuss
> > the UEFI secure boot also as it is happening soon. 
> 
> Any fimware secure boot solution fundamentally is about having the
> firmware not boot something that is not trusted.  This reduces the area
> of attack in your firmware to your executable loader, your signature
> verification code and the key itself.  Making your firmware and the
> early parts of the boot process less susceptible to attack.  UEFI secure
> boot seems to match that criteria.
> 
> I am happy to see a similar system implemented in the kernel for the
> kexec boot path.
> 
> I do not support limiting that solution to UEFI systems or making the
> jusficiation UEFI systems.  The code needs to make sense without any
> UEFI justifications.

Well, UEFI secure boot is just the driver for this discussion. But main
idea reamains that how to kexec signed images.

I think in general idea of using kernel itself a loader is generic. Any
certificate which has been used for signing the images, can be loaded
in kernel ring and image can be verified against that. That certificate
does not have to be in UEFI. In fact we should be able to use it
even without UEFI. Just boot kernel with secure boot enabled (by passing
kernel parameter) and kernel would try to do signature verify the
image being loaded.

> 
> > I was thinking that how about supporting in kernel bootloader. That is,
> > kernel acts as a boot loader. User passes the kernel, initrd and
> > commandline from user space using kexec system call and kernel parses
> > it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs,
> > backup region, elf header region etc). At the time of kexec -e, we just
> > follow th regular path and jump to second kernel.
> >
> > At the time of loading, kernel can verify the signature of incoming
> > bzImage and reject it if signatures don't match. Matthew mentioned that
> > kernel signing certificate will be available inside the running kernel,
> > so verifying PE/COFF bzImage should be easy.
> 
> Except that we don't pass the executable file to the kernel.  That
> approach was nixed in the early review of kexec.

Ok, this is the crux of this discussion. Why was passing executable image
to kernel was rejected. What's wrong with it? We can pass the executable
segments but not the executable image? Is it about keeping the file type
handling code in user space? 

>  So we either need to
> find a way to trust the /sbin/kexec binary

This would be the key. How do we trust /sbin/kexec. We don't have any
infrastrucutre to sign user space executables. Code for signing modules
got just in after a long battle. 
 
> and do the signature
> verification there on a per file type basis,

This will be possible only if we figure a way out to trust /sbin/kexec
otherwise trust chain is broken.

> or we need to pass an
> additional signature along with the code (the signature would be encoded
> with an extra kexec flag and a special purpose segment I expect).

We can possibly pass the signature in separate segment but part of the
verification process also involves calculating the digest of executable.
And how digest is calculated depends on file type. For PE/Coff there is
specific method regarding how to go about digest calculation and what
area to include and what fields to exclude.

That means for kernel to do signature verification, we shall have to
pass the full executable to kenrel as it is with PE/COFF headers and
we are back to original idea of passing executables to kernel.

> 
> If we pass the signature to the kernel for verification there are rough
> bits like how do file formats with relocation entries, the purgatory
> code, ramdisks, and kernel parameters.
> 
> > We don't have to worry about initramfs verification as it runs in 
> > user space.
> 
> Except that we need a way to distinguish the initramfs and other data
> the part that is signed.

If we are ok with the idea of passing executables and initramfs to
kernel, then kernel can do the placement. That means fields "mem and
memsz fields of kexec_segment will be free. We can possibly overload
memsz field and pass flags to represent segment type. This will happen
only if user chooses kernel as bootloader functionality.

> 
> > There is one side issue of acpi_rsdp. Because second kernel executes
> > the code specified by acpi_rsdp, it is unsafe to let user specify
> > that location. Matthew metioned that figure a way out to pass acpi_rsdp
> > using boot params and drop it from command line.
> 
> The acpi_rsdp option is really orthogonal to this issue.  Since
> everything comes from userspace the trust picture is essentially the
> same (unless we can find a way to trust /sbin/kexec).
> 
> But specifically for acpi_rdsp if we can figure out how to successfully
> use the EFI code path that should not be a problem.  For other code
> paths shrug, that is a detail we should look at when we get there.
> 
> > Looking for thoughts and ideas on how to support kdump with UEFI
> > secureboot. (This is assuming that kdump already works with UEFI with
> > parameters "noefi" and "acpi_rsdp" in non secure boot mode).
> 
> We don't support kdump with UEFI secure boot.  We support kexec loading
> signed images.  An important difference because it means that everyone
> can benefit or not as they choose.
> 
> This leaves us with a couple of important questions to answer.
> - How do we trust /sbin/kexec or how do we avoid the need to trust
>   /sbin/kexec.
> - Where is the root of trust located?

I think it is either in UEFI or in kernel.

> - How do we verify /sbin/kexec or do we verify /sbin/kexec.
> - How do we verify the images we load?
> - How do we separate code/data that needs trust from code/data that
>   doesn't need trust?

If we agree on passing executable to kernel, then we just need to
verify only kernel. And we could overload kexec_segment->mem for
this.

> - How does the design we pick reduce the amount of code we need to trust?
> 

I think if we loading in kernel, then we don't have to trust /sbin/kexec
and problem gets simplified a lot.

> None of this is particularly hard but it all needs going through
> carefully by someone who cares.

I think here crux of the matter is what's wrong with passing kernel
executable to kernel for loading and verification.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

>> 
>> > I was thinking that how about supporting in kernel bootloader. That is,
>> > kernel acts as a boot loader. User passes the kernel, initrd and
>> > commandline from user space using kexec system call and kernel parses
>> > it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs,
>> > backup region, elf header region etc). At the time of kexec -e, we just
>> > follow th regular path and jump to second kernel.
>> >
>> > At the time of loading, kernel can verify the signature of incoming
>> > bzImage and reject it if signatures don't match. Matthew mentioned that
>> > kernel signing certificate will be available inside the running kernel,
>> > so verifying PE/COFF bzImage should be easy.
>> 
>> Except that we don't pass the executable file to the kernel.  That
>> approach was nixed in the early review of kexec.
>
> Ok, this is the crux of this discussion. Why was passing executable image
> to kernel was rejected. What's wrong with it? We can pass the executable
> segments but not the executable image? Is it about keeping the file type
> handling code in user space? 

Handling the file formats etc in kernel space in inflexible.

Given that what we load current at no time is exactly what is in the
executable but is the executable plus it's ``arguments'' I have to agree
with that assesment.

In practice we have all kinds of argument passing conventions and those
conventions prevent the kernel from executing another linux kernel
directly, even if we had the other pieces in place.

Not to mention things like the SHA512 checksum that we do to verify the
kdump kernel has not been corrupted.

>>  So we either need to
>> find a way to trust the /sbin/kexec binary
>
> This would be the key. How do we trust /sbin/kexec. We don't have any
> infrastrucutre to sign user space executables. Code for signing modules
> got just in after a long battle. 

There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
and it is conceivable to have ELF note sections with signatures for
executables.


>> and do the signature
>> verification there on a per file type basis,
>
> This will be possible only if we figure a way out to trust /sbin/kexec
> otherwise trust chain is broken.

Not so.  When loading an executable in general we don't process
relocation entries.  Which means the bits in the file and the bits
actually loaded in memory match.  Since we are passing the bits through
/sbin/kexec if we also pass through the signature bits all should be
well.

Modulo argument passing.

If we can pass in two signed executable blobs we can also perform
trusted argument conversions.

>> or we need to pass an
>> additional signature along with the code (the signature would be encoded
>> with an extra kexec flag and a special purpose segment I expect).
>
> We can possibly pass the signature in separate segment but part of the
> verification process also involves calculating the digest of executable.
> And how digest is calculated depends on file type. For PE/Coff there is
> specific method regarding how to go about digest calculation and what
> area to include and what fields to exclude.
>
> That means for kernel to do signature verification, we shall have to
> pass the full executable to kenrel as it is with PE/COFF headers and
> we are back to original idea of passing executables to kernel.

See above.

>> If we pass the signature to the kernel for verification there are rough
>> bits like how do file formats with relocation entries, the purgatory
>> code, ramdisks, and kernel parameters.
>> 
>> > We don't have to worry about initramfs verification as it runs in 
>> > user space.
>> 
>> Except that we need a way to distinguish the initramfs and other data
>> the part that is signed.
>
> If we are ok with the idea of passing executables and initramfs to
> kernel, then kernel can do the placement. That means fields "mem and
> memsz fields of kexec_segment will be free. We can possibly overload
> memsz field and pass flags to represent segment type. This will happen
> only if user chooses kernel as bootloader functionality.

Which sounds nice initially but I don't think the notion of the kernel
being a general purpose bootloader holds up to well.  It doesn't provide
an easy place to put all of the weird cases.

If we are going to pass in a file it probably makes sense to do a
variation of kexec_load that passes in a file descriptor, a filename
could work but I don't think we want those races.

But then we get how do we pass in a different kernel command line and
an initrd.  Things that were simple start quickly becoming complex.

>> This leaves us with a couple of important questions to answer.
>> - How do we trust /sbin/kexec or how do we avoid the need to trust
>>   /sbin/kexec.
>> - Where is the root of trust located?
>
> I think it is either in UEFI or in kernel.

So for our purposes then it must be in the kernel, because the
implementation must work on all 25+ architectures that linux supports.

>> - How do we verify /sbin/kexec or do we verify /sbin/kexec.
>> - How do we verify the images we load?
>> - How do we separate code/data that needs trust from code/data that
>>   doesn't need trust?
>
> If we agree on passing executable to kernel, then we just need to
> verify only kernel. And we could overload kexec_segment->mem for
> this.

If we are passing in a file I think it calls for a new variant of the
kexec_load system call.

>> - How does the design we pick reduce the amount of code we need to trust?
>> 
>
> I think if we loading in kernel, then we don't have to trust /sbin/kexec
> and problem gets simplified a lot.

I don't see loading in the kernel being a requirement needed for
simplification.

If we are going to have a thing about first class and second class
arguments we are likely going to need to do something to allow the
arguments memorized at boot time to be passed through the kernel
and not read into userspace.  Another kexec flag?

Grumble.  If we didn't support ACPI or firmware callbacks it would be
simpler...

>> None of this is particularly hard but it all needs going through
>> carefully by someone who cares.
>
> I think here crux of the matter is what's wrong with passing kernel
> executable to kernel for loading and verification.

Lack of flexibility, and lack of backward compatibility.  And at this
point complete rearchitecture of kexec.

....

So at this point my recommendation would be:

- Target images where the bits are passed straight through.

- Add support for passing the initial kernels parameters through to the
  kexec'd image.

- Add support for passing the executable image signed signature through
  to the kernel, and the conversion code signed signature through to the
  kernel.

modulo a few implementation details that should allow for preservation
of most of the existing design and flexibility while allowing for signed
images without too much work.

Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote:

[..]
> Handling the file formats etc in kernel space in inflexible.
> 
> Given that what we load current at no time is exactly what is in the
> executable but is the executable plus it's ``arguments'' I have to agree
> with that assesment.
> 
> In practice we have all kinds of argument passing conventions and those
> conventions prevent the kernel from executing another linux kernel
> directly, even if we had the other pieces in place.

Can we pass all argument in one kexec segment and let associated image
format handlers parse the arguments. 

> 
> Not to mention things like the SHA512 checksum that we do to verify the
> kdump kernel has not been corrupted.

As we will be preparing all the segments intenally and also preparing
the purgatory(or equivalent) in kernel, we can alaways calculate the
checksum in kernel tool IOW, there is no reason that why can't we do
existing verifications in kernel.

> 
> >>  So we either need to
> >> find a way to trust the /sbin/kexec binary
> >
> > This would be the key. How do we trust /sbin/kexec. We don't have any
> > infrastrucutre to sign user space executables. Code for signing modules
> > got just in after a long battle. 
> 
> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> and it is conceivable to have ELF note sections with signatures for
> executables.

Can you please tell more about what is EMA and IMA. I did quick google
and could not find much.

Adding signatures to ELF should be possible. I guess this is similar
to signed PE/COFF images. Just that convention changes that how images
are signed and where exactly signatures are stored.

I do see some references to elfsign and elfverify during search. Have
not dived in to figure out what exactly they are.

I think bigger issue here is that creating that generic system of signing
user space executables and kernel verifying it. Then we end up creating
even more complicated and more locked down system.

> 
> 
> >> and do the signature
> >> verification there on a per file type basis,
> >
> > This will be possible only if we figure a way out to trust /sbin/kexec
> > otherwise trust chain is broken.
> 
> Not so.  When loading an executable in general we don't process
> relocation entries.  Which means the bits in the file and the bits
> actually loaded in memory match.  Since we are passing the bits through
> /sbin/kexec if we also pass through the signature bits all should be
> well.

So are you saying that let /sbin/kexec still load all the segments. It
will also load the attached signatures/certificates in a separate
segment and kernel can calculate hash and do verification? If yes,
few issues. here.

- What happens to purgatory code. It is unsigned piece of code which
  runs in kernel?

If you meant something else, can you please explain a bit more.

> 
> Modulo argument passing.
> 
> If we can pass in two signed executable blobs we can also perform
> trusted argument conversions.

Again lost here. Which two executable blobs you are referring to. One
is signed kernel executable, which is other one.

[..]
> > If we are ok with the idea of passing executables and initramfs to
> > kernel, then kernel can do the placement. That means fields "mem and
> > memsz fields of kexec_segment will be free. We can possibly overload
> > memsz field and pass flags to represent segment type. This will happen
> > only if user chooses kernel as bootloader functionality.
> 
> Which sounds nice initially but I don't think the notion of the kernel
> being a general purpose bootloader holds up to well.  It doesn't provide
> an easy place to put all of the weird cases.
> 
> If we are going to pass in a file it probably makes sense to do a
> variation of kexec_load that passes in a file descriptor, a filename
> could work but I don't think we want those races.
> 
> But then we get how do we pass in a different kernel command line and
> an initrd.  Things that were simple start quickly becoming complex.

Expecting three segments as input. Kernel executable, initrd and one
segment which contains all arguemnts (separated by new line) including
command line. Will that be generic enough to cover all kind of cases?

[..]
> So at this point my recommendation would be:
> 
> - Target images where the bits are passed straight through.
> 
> - Add support for passing the initial kernels parameters through to the
>   kexec'd image.
> 
> - Add support for passing the executable image signed signature through
>   to the kernel, and the conversion code signed signature through to the
>   kernel.

What is conversion code here? Are you referring to /sbin/kexec here which
breaks down kernel executables into segments? If yes, are you saying that
sign /sbin/kexec and pass its signature along with kernel signature?

But that does not help as any program can get the signature of /sbin/kexec
and pass it to kernel as its own signatures. 

I might be completely into weeds here. So little elaboration will help
me understand your ideas better.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:

[..]
> - What happens to purgatory code. It is unsigned piece of code which
>   runs in kernel?

Thinking more about it, another not so clean proposal. 

- So only non-signed executable code user space loads is purgatory. What
  if we get rid of purgatory and let kernel do the pugatory's job.

- purgatory seems to be doing few things. (atleast on x86_64).
	1. Verifies the checksums of loaded segments.
	2. Copies the backup region.
	3. Prepares the environment for jumping into target executable.
	    (32bit entry or real mode entry etc).

   First should be easily doable in kernel. At load time kernel can calculate
   the checksum of loaded segments and can verify the chesum again before
   during execute time.

   Second one should be doable too in kernel as kernel can copy the
   contents to backup region. Just that we shall have to introduce per
   segment flags so that user space can tell kernel that a particular
   segment is backup segment. (say KEXEC_BACKUP_SEGMENT).

   Third one is most tricky as it requires passing extra information to
   kernel about what kind of setup to do before jumping to entry point. If
   we can define some generic per arch kexec flags to represent those 
   states, then kernel can do the job. 

Doing lots of things based on flags does not sound very clean to me. Over
a period of time we will end up defining more flags as people come up
with new situations. But at the same time it can simplify the problem 
a bit and one does not have to introduce an new system call.

Just a thought..., Still scratching my head on how to go about this signed
image thing without too much of work.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:
>
> [..]
>> - What happens to purgatory code. It is unsigned piece of code which
>>   runs in kernel?
>
> Thinking more about it, another not so clean proposal. 
>
> - So only non-signed executable code user space loads is purgatory. What
>   if we get rid of purgatory and let kernel do the pugatory's job.

I would still say what if we sign purgatory.

> - purgatory seems to be doing few things. (atleast on x86_64).
> 	1. Verifies the checksums of loaded segments.
> 	2. Copies the backup region.
> 	3. Prepares the environment for jumping into target executable.
> 	    (32bit entry or real mode entry etc).
>
>    First should be easily doable in kernel. At load time kernel can calculate
>    the checksum of loaded segments and can verify the chesum again before
>    during execute time.
>
>    Second one should be doable too in kernel as kernel can copy the
>    contents to backup region. Just that we shall have to introduce per
>    segment flags so that user space can tell kernel that a particular
>    segment is backup segment. (say KEXEC_BACKUP_SEGMENT).
>
>    Third one is most tricky as it requires passing extra information to
>    kernel about what kind of setup to do before jumping to entry point. If
>    we can define some generic per arch kexec flags to represent those 
>    states, then kernel can do the job. 
>
> Doing lots of things based on flags does not sound very clean to me. Over
> a period of time we will end up defining more flags as people come up
> with new situations. But at the same time it can simplify the problem 
> a bit and one does not have to introduce an new system call.

The short version is over time the system call begins to look more and
more like posix spawn, and we start accumulating all kinds of weird
things in the kernel that no one needs anymore.

> Just a thought..., Still scratching my head on how to go about this signed
> image thing without too much of work.

Yeah that is the trick.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Simon Horman]

On Mon, Oct 22, 2012 at 04:43:39PM -0400, Vivek Goyal wrote:
> On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:
> 
> [..]
> > - What happens to purgatory code. It is unsigned piece of code which
> >   runs in kernel?
> 
> Thinking more about it, another not so clean proposal.

I have always assumed that purgatory can't be removed
as doing so would break backwards compatibility.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Tue, Oct 23, 2012 at 11:04:29AM +0900, Simon Horman wrote:
> On Mon, Oct 22, 2012 at 04:43:39PM -0400, Vivek Goyal wrote:
> > On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:
> > 
> > [..]
> > > - What happens to purgatory code. It is unsigned piece of code which
> > >   runs in kernel?
> > 
> > Thinking more about it, another not so clean proposal.
> 
> I have always assumed that purgatory can't be removed
> as doing so would break backwards compatibility.

Hi Simon,

I think this will be a new parallel path and this new path should be taken
only on kernel booted with secure boot enabled. (Either automatically or
by using some kexec command line option). So nothing should be broken
because we never supported anything on secure boot enabled system.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images.

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Tue, Oct 23, 2012 at 11:04:29AM +0900, Simon Horman wrote:
>> On Mon, Oct 22, 2012 at 04:43:39PM -0400, Vivek Goyal wrote:
>> > On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:
>> > 
>> > [..]
>> > > - What happens to purgatory code. It is unsigned piece of code which
>> > >   runs in kernel?
>> > 
>> > Thinking more about it, another not so clean proposal.
>> 
>> I have always assumed that purgatory can't be removed
>> as doing so would break backwards compatibility.
>
> Hi Simon,
>
> I think this will be a new parallel path and this new path should be taken
> only on kernel booted with secure boot enabled. (Either automatically or
> by using some kexec command line option). So nothing should be broken
> because we never supported anything on secure boot enabled system.

Rubbish.  Kexec works just fine today on a secure boot enabled system.
Ignoring the nonsense that there is no such thing as a secure boot
enabled linux system.

Whatever we implement must work on all linux systems.

If we implement an extension we also must write the code in /sbin/kexec
so that it works on older systems that do not implement that extension.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images.

[Vivek Goyal]

On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote:

[..]
> > I think this will be a new parallel path and this new path should be taken
> > only on kernel booted with secure boot enabled. (Either automatically or
> > by using some kexec command line option). So nothing should be broken
> > because we never supported anything on secure boot enabled system.
> 
> Rubbish.  Kexec works just fine today on a secure boot enabled system.
> Ignoring the nonsense that there is no such thing as a secure boot
> enabled linux system.

I think it is a security hole for the systems where we don't want to run
unsigned priviliged code. So yes, it works as of today, but at some point
of time we shall have to close this hole.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images.

[Maxim Uvarov]

2012/10/23 Vivek Goyal <vgoyal@redhat.com>:
> On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote:
>
> [..]
>> > I think this will be a new parallel path and this new path should be taken
>> > only on kernel booted with secure boot enabled. (Either automatically or
>> > by using some kexec command line option). So nothing should be broken
>> > because we never supported anything on secure boot enabled system.
>>
>> Rubbish.  Kexec works just fine today on a secure boot enabled system.
>> Ignoring the nonsense that there is no such thing as a secure boot
>> enabled linux system.
>
> I think it is a security hole for the systems where we don't want to run
> unsigned priviliged code. So yes, it works as of today, but at some point
> of time we shall have to close this hole.
>
> Thanks
> Vivek
>
Signatures kernel & modules in general good for support reason. We can
say for example that we support only signed kernel and signed modules
for that kernel, so we are sure that this binaries match our source.
But what is the reason of checking signatures in kexec? If you have
root privileges then more likely you have access to boot loader or to
physical machine (console, bios). Might be useful only for embedded
things to prevent enthusiasts play with already manufactured devices.

Maxim.

> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec



-- 
Best regards,
Maxim Uvarov

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images.

[Vivek Goyal]

On Tue, Oct 23, 2012 at 11:11:05PM +0400, Maxim Uvarov wrote:
> 2012/10/23 Vivek Goyal <vgoyal@redhat.com>:
> > On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote:
> >
> > [..]
> >> > I think this will be a new parallel path and this new path should be taken
> >> > only on kernel booted with secure boot enabled. (Either automatically or
> >> > by using some kexec command line option). So nothing should be broken
> >> > because we never supported anything on secure boot enabled system.
> >>
> >> Rubbish.  Kexec works just fine today on a secure boot enabled system.
> >> Ignoring the nonsense that there is no such thing as a secure boot
> >> enabled linux system.
> >
> > I think it is a security hole for the systems where we don't want to run
> > unsigned priviliged code. So yes, it works as of today, but at some point
> > of time we shall have to close this hole.
> >
> > Thanks
> > Vivek
> >
> Signatures kernel & modules in general good for support reason. We can
> say for example that we support only signed kernel and signed modules
> for that kernel, so we are sure that this binaries match our source.
> But what is the reason of checking signatures in kexec? If you have
> root privileges then more likely you have access to boot loader or to
> physical machine (console, bios). Might be useful only for embedded
> things to prevent enthusiasts play with already manufactured devices.

The way I understand is that we don't allow any unsigned code to run
at priviliged level. That's why early from boot everything is signed,
that includes shim, bootloader, kernel and modules. User space code
does not run with privilige, so it is let run without being signed.

Why do it, matthew has explained here in his blog.

http://mjg59.dreamwidth.org/9844.html

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote:
>
> [..]
>> Handling the file formats etc in kernel space in inflexible.
>> 
>> Given that what we load current at no time is exactly what is in the
>> executable but is the executable plus it's ``arguments'' I have to agree
>> with that assesment.
>> 
>> In practice we have all kinds of argument passing conventions and those
>> conventions prevent the kernel from executing another linux kernel
>> directly, even if we had the other pieces in place.
>
> Can we pass all argument in one kexec segment and let associated image
> format handlers parse the arguments.

The issue is can we pass trusted arguments?  Any kind of firmware
callback ACPI, EFI, openfirmware etc needs to be in the trusted
parameter set so it must come from a trusted location.

Unless we can trust the /sbin/kexec binary we can't trust pointers
to executable code passed to us that we can not verify are safe.

>> Not to mention things like the SHA512 checksum that we do to verify the
>> kdump kernel has not been corrupted.
>
> As we will be preparing all the segments intenally and also preparing
> the purgatory(or equivalent) in kernel, we can alaways calculate the
> checksum in kernel tool IOW, there is no reason that why can't we do
> existing verifications in kernel.

It leads to a lot more code in the kernel and a lot less flexibility, in
the long run so it is worth looking to see if we can keep the current
flexibility.

>> >>  So we either need to
>> >> find a way to trust the /sbin/kexec binary
>> >
>> > This would be the key. How do we trust /sbin/kexec. We don't have any
>> > infrastrucutre to sign user space executables. Code for signing modules
>> > got just in after a long battle. 
>> 
>> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
>> and it is conceivable to have ELF note sections with signatures for
>> executables.
>
> Can you please tell more about what is EMA and IMA. I did quick google
> and could not find much.

That should have been EVM and IMA.  Look under security/integrity/.  I
don't know much about them but they appear to be security modules with a
focus on verifying checksum or perhaps encrypted hashes of executables
are consistent.

> Adding signatures to ELF should be possible. I guess this is similar
> to signed PE/COFF images. Just that convention changes that how images
> are signed and where exactly signatures are stored.
>
> I do see some references to elfsign and elfverify during search. Have
> not dived in to figure out what exactly they are.
>
> I think bigger issue here is that creating that generic system of signing
> user space executables and kernel verifying it. Then we end up creating
> even more complicated and more locked down system.

Yes so in some ways it is a pain.

It just occurred to me there is a 4th approach we can take that seems
interesting.

Have a system call where you pass in a signature of yourself, that will
allow you to increase your set of capabilities.  I am a good binary here
is proof.  I initially that it might be a complement to sys_kexec_load
just for the kexec case but there is no reason to limit it.

>> >> and do the signature
>> >> verification there on a per file type basis,
>> >
>> > This will be possible only if we figure a way out to trust /sbin/kexec
>> > otherwise trust chain is broken.
>> 
>> Not so.  When loading an executable in general we don't process
>> relocation entries.  Which means the bits in the file and the bits
>> actually loaded in memory match.  Since we are passing the bits through
>> /sbin/kexec if we also pass through the signature bits all should be
>> well.
>
> So are you saying that let /sbin/kexec still load all the segments. It
> will also load the attached signatures/certificates in a separate
> segment and kernel can calculate hash and do verification? If yes,
> few issues. here.
>
> - What happens to purgatory code. It is unsigned piece of code which
>   runs in kernel?

The purgatory code would need to be signed.  Which is why it is
important to enable composition of signed pieces of code.

>> Modulo argument passing.
>> 
>> If we can pass in two signed executable blobs we can also perform
>> trusted argument conversions.
>
> Again lost here. Which two executable blobs you are referring to. One
> is signed kernel executable, which is other one.

Purgatory.

> [..]
>> > If we are ok with the idea of passing executables and initramfs to
>> > kernel, then kernel can do the placement. That means fields "mem and
>> > memsz fields of kexec_segment will be free. We can possibly overload
>> > memsz field and pass flags to represent segment type. This will happen
>> > only if user chooses kernel as bootloader functionality.
>> 
>> Which sounds nice initially but I don't think the notion of the kernel
>> being a general purpose bootloader holds up to well.  It doesn't provide
>> an easy place to put all of the weird cases.
>> 
>> If we are going to pass in a file it probably makes sense to do a
>> variation of kexec_load that passes in a file descriptor, a filename
>> could work but I don't think we want those races.
>> 
>> But then we get how do we pass in a different kernel command line and
>> an initrd.  Things that were simple start quickly becoming complex.
>
> Expecting three segments as input. Kernel executable, initrd and one
> segment which contains all arguemnts (separated by new line) including
> command line. Will that be generic enough to cover all kind of cases?

History strongly suggests not.

> [..]
>> So at this point my recommendation would be:
>> 
>> - Target images where the bits are passed straight through.
>> 
>> - Add support for passing the initial kernels parameters through to the
>>   kexec'd image.
>> 
>> - Add support for passing the executable image signed signature through
>>   to the kernel, and the conversion code signed signature through to the
>>   kernel.
>
> What is conversion code here?

Purgatory.  Whatever we need to run between the two kernels.

> Are you referring to /sbin/kexec here which
> breaks down kernel executables into segments? If yes, are you saying that
> sign /sbin/kexec and pass its signature along with kernel signature?

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Mon, Oct 22, 2012 at 02:07:56PM -0700, Eric W. Biederman wrote:

[..]
> > Can we pass all argument in one kexec segment and let associated image
> > format handlers parse the arguments.
> 
> The issue is can we pass trusted arguments?  Any kind of firmware
> callback ACPI, EFI, openfirmware etc needs to be in the trusted
> parameter set so it must come from a trusted location.
> 

I think parameters will include something like read only one and second
kernel should be able to verify it. It should not be an executable code
of any form. (like acpi_rsdp).  I think this is similar to that we don't
sign/verify kernel command line passed in a bootloader. 
 
> Unless we can trust the /sbin/kexec binary we can't trust pointers
> to executable code passed to us that we can not verify are safe.

Given the fact we allow user to specify command line, even if we sign
/sbin/kexec, we have no way to trust it. IMO here we just need to make
sure that input parameters/arguments can't lead one to execute arbitrary
code.

[..]
> >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> >> and it is conceivable to have ELF note sections with signatures for
> >> executables.
> >
> > Can you please tell more about what is EMA and IMA. I did quick google
> > and could not find much.
> 
> That should have been EVM and IMA.  Look under security/integrity/.  I
> don't know much about them but they appear to be security modules with a
> focus on verifying checksum or perhaps encrypted hashes of executables
> are consistent.

I will do some quick search there and I see if I can understand something.

[..]
> It just occurred to me there is a 4th approach we can take that seems
> interesting.
> 
> Have a system call where you pass in a signature of yourself, that will
> allow you to increase your set of capabilities.  I am a good binary here
> is proof.  I initially that it might be a complement to sys_kexec_load
> just for the kexec case but there is no reason to limit it.

If one presents its own signature, then anybody can copy and present
that signature. There needs to be a mechanism to verify that you 
actually have the signature you are presenting (i mean digest of
executable).

So above does not address that how that new system call will verify the
signature/hash of process invoking system call.

[..]
> > - What happens to purgatory code. It is unsigned piece of code which
> >   runs in kernel?
> 
> The purgatory code would need to be signed.  Which is why it is
> important to enable composition of signed pieces of code.

purgatory code is modified dynamically upon every invocation of kexec.
That means there needs to be a mechanism to sign it after we are done
with purgatory modification. But there are no signing keys available
on the system. All the signing happens externally during build time. So
we don't have the option of signing purgatory at run time.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:

[..]
> > >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> > >> and it is conceivable to have ELF note sections with signatures for
> > >> executables.
> > >
> > > Can you please tell more about what is EMA and IMA. I did quick google
> > > and could not find much.
> > 
> > That should have been EVM and IMA.  Look under security/integrity/.  I
> > don't know much about them but they appear to be security modules with a
> > focus on verifying checksum or perhaps encrypted hashes of executables
> > are consistent.
> 
> I will do some quick search there and I see if I can understand something.
> 

Ok, I quickly went through following paper.

http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf

So it looks like that IMA can store the hashes of files and at execute
time ensure those hashes are unchanged to protect against the possibility
of modification of files.

But what about creation of a new program which can call kexec_load()
and execute an unsigned kernel. Doesn't look like that will be
prevented using IMA.

Whole idea behind UEFI secure boot seems to be that all signing happens
outside the running system and now only signed code can run with higher
priviliges. IMA seems to be only protecting against only making sure
existing binaries are not modifed but it does not seem to prevent against
installation of new binaries and these binaries take advantage of kexec
system call to load an unsigned kernel. 

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Matthew Garrett]

On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:

> But what about creation of a new program which can call kexec_load()
> and execute an unsigned kernel. Doesn't look like that will be
> prevented using IMA.

Right. Trusting userspace would require a new system call that passes in 
a signature of the userspace binary, and the kernel would then have to 
verify the ELF object in memory in order to ensure that it 
matches the signature. Verifying that the copy on the filesystem is 
unmodified isn't adequate - an attacker could simply have paused the 
process and injected code. Realistically, the only solution here is for 
the kernel to verify that the kernel it's about to boot is signed and 
for it not to take any untrusted executable code from userspace.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Eric W. Biederman]

Matthew Garrett <mjg@redhat.com> writes:

> On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
>
>> But what about creation of a new program which can call kexec_load()
>> and execute an unsigned kernel. Doesn't look like that will be
>> prevented using IMA.
>
> Right. Trusting userspace would require a new system call that passes in 
> a signature of the userspace binary, and the kernel would then have to 
> verify the ELF object in memory in order to ensure that it 
> matches the signature. Verifying that the copy on the filesystem is 
> unmodified isn't adequate - an attacker could simply have paused the 
> process and injected code. 

Verifying the copy on the filesystem at exec time is perfectly adequate
for gating extra permissions.  Certainly that is the model everywhere
else in the signed key chain.

Where IMA falls short is there is no offline signing capability in IMA
itself.  I think EVM may fix that.

> Realistically, the only solution here is for 
> the kernel to verify that the kernel it's about to boot is signed and 
> for it not to take any untrusted executable code from userspace.

Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
perfectly reasonable, and realistic.  In fact finding a way to trust
small bits of userspace even if root is compromised seems a far superior
model to simply solving the signing problem for /sbin/kexec.

Although I do admit some part of the kexec process will need to verify
keys on the images we decide to boot.

Eric




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Matthew Garrett]

On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:

> Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> perfectly reasonable, and realistic.  In fact finding a way to trust
> small bits of userspace even if root is compromised seems a far superior
> model to simply solving the signing problem for /sbin/kexec.

The kernel verifying the signature of /sbin/kexec and then knowing that 
it should only grant permission to make this syscall to /sbin/kexec, 
without that policy being provided by userspace.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Vivek Goyal]

On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg@redhat.com> writes:
> 
> > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> >
> >> But what about creation of a new program which can call kexec_load()
> >> and execute an unsigned kernel. Doesn't look like that will be
> >> prevented using IMA.
> >
> > Right. Trusting userspace would require a new system call that passes in 
> > a signature of the userspace binary, and the kernel would then have to 
> > verify the ELF object in memory in order to ensure that it 
> > matches the signature. Verifying that the copy on the filesystem is 
> > unmodified isn't adequate - an attacker could simply have paused the 
> > process and injected code. 
> 
> Verifying the copy on the filesystem at exec time is perfectly adequate
> for gating extra permissions.  Certainly that is the model everywhere
> else in the signed key chain.
> 
> Where IMA falls short is there is no offline signing capability in IMA
> itself.  I think EVM may fix that.

[ CCing lkml. I think it is a good idea to open discussion to wider
audience. Also CCing IMA/EVM folks ]

Based on reading following wiki page, looks like EVM also does not allow
offline signing capability. And EVM is protecting IMA data to protect
against offline attack. If we can assume that unisgned kernels can't be
booted on the platform, then EVM might not be a strict requirement in
this case.

So as you said, one of the main problem with IMA use to verify /sbin/kexec
is that IMA does not provide offline signing capability.

> 
> > Realistically, the only solution here is for 
> > the kernel to verify that the kernel it's about to boot is signed and 
> > for it not to take any untrusted executable code from userspace.
> 
> Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> perfectly reasonable, and realistic.  In fact finding a way to trust
> small bits of userspace even if root is compromised seems a far superior
> model to simply solving the signing problem for /sbin/kexec.
> 
> Although I do admit some part of the kexec process will need to verify
> keys on the images we decide to boot.

It should be an option, isn't it? Either /sbin/kexec can try to verify the
integrity of kernel or we extend try to extend kexec() system call to also
pass the signature of kernel and let kernel verify it (as you mentioned
previously).

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Mimi Zohar]

On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> > Matthew Garrett <mjg@redhat.com> writes:
> > 
> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> > >
> > >> But what about creation of a new program which can call kexec_load()
> > >> and execute an unsigned kernel. Doesn't look like that will be
> > >> prevented using IMA.

Like the existing kernel modules, kexec_load() is not file descriptor
based.  There isn't an LSM or IMA-appraisal hook here.

> > > Right. Trusting userspace would require a new system call that passes in 
> > > a signature of the userspace binary, and the kernel would then have to 
> > > verify the ELF object in memory in order to ensure that it 
> > > matches the signature. Verifying that the copy on the filesystem is 
> > > unmodified isn't adequate - an attacker could simply have paused the 
> > > process and injected code. 

I haven't looked at kexec_load() in detail, but like kernel modules, I
think the better solution would be to pass a file descriptor, especially
if you're discussing a new system call.  (cc'ing Kees.)

> > Verifying the copy on the filesystem at exec time is perfectly adequate
> > for gating extra permissions.  Certainly that is the model everywhere
> > else in the signed key chain.
> > 
> > Where IMA falls short is there is no offline signing capability in IMA
> > itself.  I think EVM may fix that.

I'm not sure what you mean by offline signing capability.  IMA-appraisal
verifies a file's 'security.ima' xattr, which may contain a hash or a
digital signature.  EVM protects a file's metadata, including
'security.ima'.  'security.evm' can be either an hmac or a digital
signature.

> [ CCing lkml. I think it is a good idea to open discussion to wider
> audience. Also CCing IMA/EVM folks ]

thanks!

> Based on reading following wiki page, looks like EVM also does not allow
> offline signing capability. And EVM is protecting IMA data to protect
> against offline attack. If we can assume that unisgned kernels can't be
> booted on the platform, then EVM might not be a strict requirement in
> this case.

> So as you said, one of the main problem with IMA use to verify /sbin/kexec
> is that IMA does not provide offline signing capability.

?
 
> > 
> > > Realistically, the only solution here is for 
> > > the kernel to verify that the kernel it's about to boot is signed and 
> > > for it not to take any untrusted executable code from userspace.

From an IMA, as opposed to an IMA-appraisal, perspective, kexec is
problematic.  IMA maintains a measurement list and extends a PCR with
the file hash.  The measurement list and PCR value are used to attest to
the integrity of the running system.  As the original measurement list
is lost after kexec, but the PCR value hasn't been reset, the
measuremnet list and PCR value won't agree.

> > Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> > perfectly reasonable, and realistic.  In fact finding a way to trust
> > small bits of userspace even if root is compromised seems a far superior
> > model to simply solving the signing problem for /sbin/kexec.

Huh?  I don't understand what you're suggesting.  Once root has been
compromised, that's it.

> > Although I do admit some part of the kexec process will need to verify
> > keys on the images we decide to boot.

Which keys?  Isn't the kernel module key builtin to the kernel and
included in the kernel image signature?

> It should be an option, isn't it? Either /sbin/kexec can try to verify the
> integrity of kernel or we extend try to extend kexec() system call to also
> pass the signature of kernel and let kernel verify it (as you mentioned
> previously).
> 
> Thanks
> Vivek
> 

As suggested above, please consider passing a file descriptor, at least
in addition, if not in lieu of a signature.

thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Kees Cook]

On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
>> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
>> > Matthew Garrett <mjg@redhat.com> writes:
>> >
>> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
>> > >
>> > >> But what about creation of a new program which can call kexec_load()
>> > >> and execute an unsigned kernel. Doesn't look like that will be
>> > >> prevented using IMA.
>
> Like the existing kernel modules, kexec_load() is not file descriptor
> based.  There isn't an LSM or IMA-appraisal hook here.
>
>> > > Right. Trusting userspace would require a new system call that passes in
>> > > a signature of the userspace binary, and the kernel would then have to
>> > > verify the ELF object in memory in order to ensure that it
>> > > matches the signature. Verifying that the copy on the filesystem is
>> > > unmodified isn't adequate - an attacker could simply have paused the
>> > > process and injected code.
>
> I haven't looked at kexec_load() in detail, but like kernel modules, I
> think the better solution would be to pass a file descriptor, especially
> if you're discussing a new system call.  (cc'ing Kees.)

Yeah, it looks like kexec_load could use a nearly identical new
syscall that uses an fd, just like init_module is getting.

Another area, kind of related, is firmware loading. The interface for
that is a bit weird, if the documentation is up to date:

        echo 1 > /sys/$DEVPATH/loading
        cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data
        echo 0 > /sys/$DEVPATH/loading

It looks like there's a filp on the reader:

static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj,
                                  struct bin_attribute *bin_attr,
                                  char *buffer, loff_t offset, size_t count)

But it's not clear to me yet if we'll actually get the firmware file,
or if we'll get a random pipe we can't evaluate. Has anyone looked at
handling "signed" firmware loading yet?

-Kees

-- 
Kees Cook
Chrome OS Security

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Mimi Zohar]

On Wed, 2012-10-24 at 23:44 -0700, Kees Cook wrote:
> On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> >> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> >> > Matthew Garrett <mjg@redhat.com> writes:
> >> >
> >> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> >> > >
> >> > >> But what about creation of a new program which can call kexec_load()
> >> > >> and execute an unsigned kernel. Doesn't look like that will be
> >> > >> prevented using IMA.
> >
> > Like the existing kernel modules, kexec_load() is not file descriptor
> > based.  There isn't an LSM or IMA-appraisal hook here.
> >
> >> > > Right. Trusting userspace would require a new system call that passes in
> >> > > a signature of the userspace binary, and the kernel would then have to
> >> > > verify the ELF object in memory in order to ensure that it
> >> > > matches the signature. Verifying that the copy on the filesystem is
> >> > > unmodified isn't adequate - an attacker could simply have paused the
> >> > > process and injected code.
> >
> > I haven't looked at kexec_load() in detail, but like kernel modules, I
> > think the better solution would be to pass a file descriptor, especially
> > if you're discussing a new system call.  (cc'ing Kees.)
> 
> Yeah, it looks like kexec_load could use a nearly identical new
> syscall that uses an fd, just like init_module is getting.
> 
> Another area, kind of related, is firmware loading. The interface for
> that is a bit weird, if the documentation is up to date:
> 
>         echo 1 > /sys/$DEVPATH/loading
>         cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data
>         echo 0 > /sys/$DEVPATH/loading
> 
> It looks like there's a filp on the reader:
> 
> static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj,
>                                   struct bin_attribute *bin_attr,
>                                   char *buffer, loff_t offset, size_t count)
> 
> But it's not clear to me yet if we'll actually get the firmware file,
> or if we'll get a random pipe we can't evaluate. Has anyone looked at
> handling "signed" firmware loading yet?
> 
> -Kees

Only looked at it enough to mention at LSS, that it's needed.

Mimi



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Vivek Goyal]

On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote:
> On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> > On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> > > Matthew Garrett <mjg@redhat.com> writes:
> > > 
> > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> > > >
> > > >> But what about creation of a new program which can call kexec_load()
> > > >> and execute an unsigned kernel. Doesn't look like that will be
> > > >> prevented using IMA.
> 
> Like the existing kernel modules, kexec_load() is not file descriptor
> based.  There isn't an LSM or IMA-appraisal hook here.
> 
> > > > Right. Trusting userspace would require a new system call that passes in 
> > > > a signature of the userspace binary, and the kernel would then have to 
> > > > verify the ELF object in memory in order to ensure that it 
> > > > matches the signature. Verifying that the copy on the filesystem is 
> > > > unmodified isn't adequate - an attacker could simply have paused the 
> > > > process and injected code. 
> 
> I haven't looked at kexec_load() in detail, but like kernel modules, I
> think the better solution would be to pass a file descriptor, especially
> if you're discussing a new system call.  (cc'ing Kees.)

If we decide to go for a new system call, then yes it looks like passing
fd will make sense.

> 
> > > Verifying the copy on the filesystem at exec time is perfectly adequate
> > > for gating extra permissions.  Certainly that is the model everywhere
> > > else in the signed key chain.
> > > 
> > > Where IMA falls short is there is no offline signing capability in IMA
> > > itself.  I think EVM may fix that.
> 
> I'm not sure what you mean by offline signing capability.  IMA-appraisal
> verifies a file's 'security.ima' xattr, which may contain a hash or a
> digital signature.  EVM protects a file's metadata, including
> 'security.ima'.  'security.evm' can be either an hmac or a digital
> signature.

By offline we mean that signature generation/signing does not happen on
system in question. It happens say on build time. IIUC, in case of IMA,
security.ima is generated and signed on the system and that means private
key needs to be present on the system? 

We wanted something like module signing where modules are signed at
build time and verification happens at load time but no private key
needs to be present on the system.

> 
> > [ CCing lkml. I think it is a good idea to open discussion to wider
> > audience. Also CCing IMA/EVM folks ]
> 
> thanks!
> 
> > Based on reading following wiki page, looks like EVM also does not allow
> > offline signing capability. And EVM is protecting IMA data to protect
> > against offline attack. If we can assume that unisgned kernels can't be
> > booted on the platform, then EVM might not be a strict requirement in
> > this case.
> 
> > So as you said, one of the main problem with IMA use to verify /sbin/kexec
> > is that IMA does not provide offline signing capability.
> 
> ?

See above.

>  
> > > 
> > > > Realistically, the only solution here is for 
> > > > the kernel to verify that the kernel it's about to boot is signed and 
> > > > for it not to take any untrusted executable code from userspace.
> 
> >From an IMA, as opposed to an IMA-appraisal, perspective, kexec is
> problematic.  IMA maintains a measurement list and extends a PCR with
> the file hash.  The measurement list and PCR value are used to attest to
> the integrity of the running system.  As the original measurement list
> is lost after kexec, but the PCR value hasn't been reset, the
> measuremnet list and PCR value won't agree.
> 
> > > Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> > > perfectly reasonable, and realistic.  In fact finding a way to trust
> > > small bits of userspace even if root is compromised seems a far superior
> > > model to simply solving the signing problem for /sbin/kexec.
> 
> Huh?  I don't understand what you're suggesting.  Once root has been
> compromised, that's it.
> 
> > > Although I do admit some part of the kexec process will need to verify
> > > keys on the images we decide to boot.
> 
> Which keys?  Isn't the kernel module key builtin to the kernel and
> included in the kernel image signature?

I think Eric is referring to verifying bzImage signature. One can sign
PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec
verify the integrity/authenticity of bzImage and figure a way out to
verify integrity/authenticity of /sbin/kexec.

That way one does not have to change current logic and most of the logic
of kexec/kdump can still be in user space. Otherwise we shall probably
have to implement a new system call which takes kernel and initrd as
input parameters and kernel does signature verification and prepares
bzImage for loading. This is like re-writing kexec/kdump again with
restricted functionality.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with signed images

[Mimi Zohar]

On Thu, 2012-10-25 at 09:54 -0400, Vivek Goyal wrote:
> On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote:
> > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> > > On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> > > > Matthew Garrett <mjg@redhat.com> writes:
> > > > 
> > > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> > > > >
> > > > >> But what about creation of a new program which can call kexec_load()
> > > > >> and execute an unsigned kernel. Doesn't look like that will be
> > > > >> prevented using IMA.
> > 
> > Like the existing kernel modules, kexec_load() is not file descriptor
> > based.  There isn't an LSM or IMA-appraisal hook here.
> > 
> > > > > Right. Trusting userspace would require a new system call that passes in 
> > > > > a signature of the userspace binary, and the kernel would then have to 
> > > > > verify the ELF object in memory in order to ensure that it 
> > > > > matches the signature. Verifying that the copy on the filesystem is 
> > > > > unmodified isn't adequate - an attacker could simply have paused the 
> > > > > process and injected code. 
> > 
> > I haven't looked at kexec_load() in detail, but like kernel modules, I
> > think the better solution would be to pass a file descriptor, especially
> > if you're discussing a new system call.  (cc'ing Kees.)
> 
> If we decide to go for a new system call, then yes it looks like passing
> fd will make sense.
> 
> > 
> > > > Verifying the copy on the filesystem at exec time is perfectly adequate
> > > > for gating extra permissions.  Certainly that is the model everywhere
> > > > else in the signed key chain.
> > > > 
> > > > Where IMA falls short is there is no offline signing capability in IMA
> > > > itself.  I think EVM may fix that.
> > 
> > I'm not sure what you mean by offline signing capability.  IMA-appraisal
> > verifies a file's 'security.ima' xattr, which may contain a hash or a
> > digital signature.  EVM protects a file's metadata, including
> > 'security.ima'.  'security.evm' can be either an hmac or a digital
> > signature.
> 
> By offline we mean that signature generation/signing does not happen on
> system in question. It happens say on build time. IIUC, in case of IMA,
> security.ima is generated and signed on the system and that means private
> key needs to be present on the system? 

The signature for 'security.ima' can definitely be created offline.
'security.evm' can also be created offline, as long as the target's
inode and other metadata doesn't change.

> We wanted something like module signing where modules are signed at
> build time and verification happens at load time but no private key
> needs to be present on the system.

Modules are identifiable.  As long as you have some mechanism to
identify mutable vs immutable files during build, there shouldn't be a
problem.  I'd use the same private key for signing modules and all
others.

> > 
> > > [ CCing lkml. I think it is a good idea to open discussion to wider
> > > audience. Also CCing IMA/EVM folks ]
> > 
> > thanks!
> > 
> > > Based on reading following wiki page, looks like EVM also does not allow
> > > offline signing capability. And EVM is protecting IMA data to protect
> > > against offline attack. If we can assume that unisgned kernels can't be
> > > booted on the platform, then EVM might not be a strict requirement in
> > > this case.
> > 
> > > So as you said, one of the main problem with IMA use to verify /sbin/kexec
> > > is that IMA does not provide offline signing capability.
> > 
> > ?
> 
> See above.
> 
> >  
> > > > 
> > > > > Realistically, the only solution here is for 
> > > > > the kernel to verify that the kernel it's about to boot is signed and 
> > > > > for it not to take any untrusted executable code from userspace.
> > 
> > >From an IMA, as opposed to an IMA-appraisal, perspective, kexec is
> > problematic.  IMA maintains a measurement list and extends a PCR with
> > the file hash.  The measurement list and PCR value are used to attest to
> > the integrity of the running system.  As the original measurement list
> > is lost after kexec, but the PCR value hasn't been reset, the
> > measuremnet list and PCR value won't agree.
> > 
> > > > Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> > > > perfectly reasonable, and realistic.  In fact finding a way to trust
> > > > small bits of userspace even if root is compromised seems a far superior
> > > > model to simply solving the signing problem for /sbin/kexec.
> > 
> > Huh?  I don't understand what you're suggesting.  Once root has been
> > compromised, that's it.
> > 
> > > > Although I do admit some part of the kexec process will need to verify
> > > > keys on the images we decide to boot.
> > 
> > Which keys?  Isn't the kernel module key builtin to the kernel and
> > included in the kernel image signature?
> 
> I think Eric is referring to verifying bzImage signature. One can sign
> PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec
> verify the integrity/authenticity of bzImage and figure a way out to
> verify integrity/authenticity of /sbin/kexec.

Yes that would work.  IMA-appraisal/EVM would verify and enforce the
integrity of /sbin/kexec, like any other file.  Verifying the signature
of the kernel image itself could be left up to kexec.

> That way one does not have to change current logic and most of the logic
> of kexec/kdump can still be in user space. Otherwise we shall probably
> have to implement a new system call which takes kernel and initrd as
> input parameters and kernel does signature verification and prepares
> bzImage for loading. This is like re-writing kexec/kdump again with
> restricted functionality.
> 
> Thanks
> Vivek
> 

From an attestation perspective, it would be better to add a new hook to
measure the kernel image and append the measurement to the IMA
measurement list.  With the new hook, the integrity of the kernel image
could be enforced.   I assume you realize that calculating a hash
requires reading the entire file.

thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Tue, Oct 23, 2012 at 04:41:24PM +0100, Matthew Garrett wrote:
> On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> 
> > But what about creation of a new program which can call kexec_load()
> > and execute an unsigned kernel. Doesn't look like that will be
> > prevented using IMA.
> 
> Right. Trusting userspace would require a new system call that passes in 
> a signature of the userspace binary, and the kernel would then have to 
> verify the ELF object in memory in order to ensure that it 
> matches the signature.

[ CC lkml and IMA/EVM developers ]

Not sure how much of this is feasible. There is initialized data which
can change. That means we shall have to exclude initialized data from
digest. And then initialized data can be changed by attacker.

I think in the context of kexec, purgatory (which is actually a
relocatable executable), is embedded in kexec binary as "const char
purgatory[]". I am assuming that it will show up as initialized data
in /sbin/kexec. And if we do not include initialized data in digest
calculation, then one can overwrite purgatory with its own executable
code and kexec will load it into the kernel and let it run at priviliged
level.

So looks like even above will not be foolproof. (Assuming we can do
this. I thought we lost all the elf headers after loading elf 
binary and now we don't know which mmpaed areas need to be included
in digest and which should not be).
 
> Verifying that the copy on the filesystem is 
> unmodified isn't adequate - an attacker could simply have paused the 
> process and injected code.

This is an interesting point. So even if we verify the signature of
/sbin/kexec, parent can change the code (using ptrace() interface?).
And we are again prone to attack. So this will work if we are doing
integrity/authenticity checks on all root processes and not just
one /sbin/kexec.

> Realistically, the only solution here is for 
> the kernel to verify that the kernel it's about to boot is signed and 
> for it not to take any untrusted executable code from userspace.

Hmm.., given above, looks like implementing a new system call to pass
in full kernel and initramfs (along with some command line or other
parameters), becomes interesting.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
>
> [..]
>> > >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
>> > >> and it is conceivable to have ELF note sections with signatures for
>> > >> executables.
>> > >
>> > > Can you please tell more about what is EMA and IMA. I did quick google
>> > > and could not find much.
>> > 
>> > That should have been EVM and IMA.  Look under security/integrity/.  I
>> > don't know much about them but they appear to be security modules with a
>> > focus on verifying checksum or perhaps encrypted hashes of executables
>> > are consistent.
>> 
>> I will do some quick search there and I see if I can understand something.
>> 
>
> Ok, I quickly went through following paper.
>
> http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
>
> So it looks like that IMA can store the hashes of files and at execute
> time ensure those hashes are unchanged to protect against the possibility
> of modification of files.
>
> But what about creation of a new program which can call kexec_load()
> and execute an unsigned kernel. Doesn't look like that will be
> prevented using IMA.
>
> Whole idea behind UEFI secure boot seems to be that all signing happens
> outside the running system and now only signed code can run with higher
> priviliges.

No.  UEFI secure boot has absolutely nothing todo with this.

UEFI secure boot is about not being able to hijack the code EFI runs
directly.  Full stop.

Some people would like to implment a security policy that says
you can't boot an untrusted version of windows from linux if you have
booted with UEFI secure boot, so they don't get their bootloader
signatures revoked by microsoft.

A security model relying on Microsoft's key is totally uniteresting to
me.  Either signing at the UEFI level is of no use or Microsofts key
will fall again to the combined assult of every cracker and every
governmental dirty cyber ops division attacking it.  Not to mention that
Microsoft has little incentive to keep linux booting.

I think it is reasonable to be able to support a policy where we can't
boot unsigned versions of Microsoft windows.  However beyond being able
to exclude booting windows being one criteria for our policy mechanism
please don't even start to justify things with that ridiculous security
policy even indirectly.

> IMA seems to be only protecting against only making sure
> existing binaries are not modifed but it does not seem to prevent against
> installation of new binaries and these binaries take advantage of kexec
> system call to load an unsigned kernel. 

I believe you can combine IMA with EVM signed security attributes where
the EVM signing key is offline, and the verification key is in the
kernel.

The combination of IMA and EVM gets very close to being able to sign
executables offline and be able to update them.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Matthew Garrett]

On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> No.  UEFI secure boot has absolutely nothing todo with this.
> 
> UEFI secure boot is about not being able to hijack the code EFI runs
> directly.  Full stop.

No. It's about ensuring that no untrusted code can be run before any OS 
kernel, which means that no untrusted code can run *in* any OS kernel.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Eric W. Biederman]

Matthew Garrett <mjg@redhat.com> writes:

> On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
>> No.  UEFI secure boot has absolutely nothing todo with this.
>> 
>> UEFI secure boot is about not being able to hijack the code EFI runs
>> directly.  Full stop.
>
> No. It's about ensuring that no untrusted code can be run before any OS 
> kernel, which means that no untrusted code can run *in* any OS kernel.

Hogwash.

- All code has bugs.
- Firmware is particularly susceptible to buggy implementations.
- In the presence of bugs no guarantees can be made.
- All you can do is limit your level of exposure.
- Verifying a signature before you run code seems a reasonable way to
  limit exposure to code that can exploit bugs.

Anything else is policy people build on top of the mechanisms UEFI gives
them.



The statement that no untrusted code can run *in* any OS kernel is
ridiculous on the face of it.  In general all distros ship with patches
that have not received enough review to have been merged into the main
linux kernel.  Aka untrusted code.  Nothing has fixed the UEFI bugs aka
untrusted code.  Not to mention the how many little trust I have in
unreviewable binary blobs that UEFI needs to support to run OS's like
OSX and Windows.


Targeting never running any untrusted code in ring 0 seems like a
reasaonable target, and worth figuring out how to implement.  But don't
justify it by saying UEFI in secure boot mode requires it.  And don't
forget that what people trust are different things.

Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Matthew Garrett]

On Tue, Oct 23, 2012 at 10:03:37AM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg@redhat.com> writes:
> 
> > On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> >> No.  UEFI secure boot has absolutely nothing todo with this.
> >> 
> >> UEFI secure boot is about not being able to hijack the code EFI runs
> >> directly.  Full stop.
> >
> > No. It's about ensuring that no untrusted code can be run before any OS 
> > kernel, which means that no untrusted code can run *in* any OS kernel.
> 
> Hogwash.

Well, I don't think this conversation's going to go any further in a 
productive manner.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
> >
> > [..]
> >> > >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> >> > >> and it is conceivable to have ELF note sections with signatures for
> >> > >> executables.
> >> > >
> >> > > Can you please tell more about what is EMA and IMA. I did quick google
> >> > > and could not find much.
> >> > 
> >> > That should have been EVM and IMA.  Look under security/integrity/.  I
> >> > don't know much about them but they appear to be security modules with a
> >> > focus on verifying checksum or perhaps encrypted hashes of executables
> >> > are consistent.
> >> 
> >> I will do some quick search there and I see if I can understand something.
> >> 
> >
> > Ok, I quickly went through following paper.
> >
> > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
> >
> > So it looks like that IMA can store the hashes of files and at execute
> > time ensure those hashes are unchanged to protect against the possibility
> > of modification of files.
> >
> > But what about creation of a new program which can call kexec_load()
> > and execute an unsigned kernel. Doesn't look like that will be
> > prevented using IMA.
> >
> > Whole idea behind UEFI secure boot seems to be that all signing happens
> > outside the running system and now only signed code can run with higher
> > priviliges.
> 
> No.  UEFI secure boot has absolutely nothing todo with this.
> 
> UEFI secure boot is about not being able to hijack the code EFI runs
> directly.  Full stop.
> 
> Some people would like to implment a security policy that says
> you can't boot an untrusted version of windows from linux if you have
> booted with UEFI secure boot, so they don't get their bootloader
> signatures revoked by microsoft.
> 
> A security model relying on Microsoft's key is totally uniteresting to
> me.  Either signing at the UEFI level is of no use or Microsofts key
> will fall again to the combined assult of every cracker and every
> governmental dirty cyber ops division attacking it.  Not to mention that
> Microsoft has little incentive to keep linux booting.
> 
> I think it is reasonable to be able to support a policy where we can't
> boot unsigned versions of Microsoft windows.  However beyond being able
> to exclude booting windows being one criteria for our policy mechanism
> please don't even start to justify things with that ridiculous security
> policy even indirectly.
> 
> > IMA seems to be only protecting against only making sure
> > existing binaries are not modifed but it does not seem to prevent against
> > installation of new binaries and these binaries take advantage of kexec
> > system call to load an unsigned kernel. 
> 
> I believe you can combine IMA with EVM signed security attributes where
> the EVM signing key is offline, and the verification key is in the
> kernel.
> 
> The combination of IMA and EVM gets very close to being able to sign
> executables offline and be able to update them.

[ Again CCing lkml and IMA/EVM folks ]

After little reading, my understanding is EVM also does not support
offline signing. 

http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page

Given the fact EVM protects IMA data (security.ima), which is generated
inline, I am not sure how EVM can sign images offline.

I might have misunderstood things, please correct me if that's not the
case.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote:
> On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> > 
> > > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
> > >
> > > [..]
> > >> > >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> > >> > >> and it is conceivable to have ELF note sections with signatures for
> > >> > >> executables.
> > >> > >
> > >> > > Can you please tell more about what is EMA and IMA. I did quick google
> > >> > > and could not find much.
> > >> > 
> > >> > That should have been EVM and IMA.  Look under security/integrity/.  I
> > >> > don't know much about them but they appear to be security modules with a
> > >> > focus on verifying checksum or perhaps encrypted hashes of executables
> > >> > are consistent.
> > >> 
> > >> I will do some quick search there and I see if I can understand something.
> > >> 
> > >
> > > Ok, I quickly went through following paper.
> > >
> > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
> > >
> > > So it looks like that IMA can store the hashes of files and at execute
> > > time ensure those hashes are unchanged to protect against the possibility
> > > of modification of files.

IMA-appraisal originally was hashed based, but Dmitry Kasatkin added
digital signature support.  Both have been upstreamed.

> > > But what about creation of a new program which can call kexec_load()
> > > and execute an unsigned kernel. Doesn't look like that will be
> > > prevented using IMA.

Assuming the IMA policy syntax is updated to require 'security.ima' to
contain a digital signature, then it is only a question of protecting
the _ima and _evm keyrings. (Dmitry has such a patch waiting to be
reviewed.)  So the new program would have to be vetted by someone
trusted.

> > > Whole idea behind UEFI secure boot seems to be that all signing happens
> > > outside the running system and now only signed code can run with higher
> > > priviliges.
> > 
> > No.  UEFI secure boot has absolutely nothing todo with this.
> > 
> > UEFI secure boot is about not being able to hijack the code EFI runs
> > directly.  Full stop.
> > 
> > Some people would like to implment a security policy that says
> > you can't boot an untrusted version of windows from linux if you have
> > booted with UEFI secure boot, so they don't get their bootloader
> > signatures revoked by microsoft.
> > 
> > A security model relying on Microsoft's key is totally uniteresting to
> > me.  Either signing at the UEFI level is of no use or Microsofts key
> > will fall again to the combined assult of every cracker and every
> > governmental dirty cyber ops division attacking it.  Not to mention that
> > Microsoft has little incentive to keep linux booting.
> > 
> > I think it is reasonable to be able to support a policy where we can't
> > boot unsigned versions of Microsoft windows.  However beyond being able
> > to exclude booting windows being one criteria for our policy mechanism
> > please don't even start to justify things with that ridiculous security
> > policy even indirectly.
> > 
> > > IMA seems to be only protecting against only making sure
> > > existing binaries are not modifed but it does not seem to prevent against
> > > installation of new binaries and these binaries take advantage of kexec
> > > system call to load an unsigned kernel. 

The IMA/IMA-appraisal policy dictates what needs to be appraised.  The
default ima-appraisal policy appraises all files owned by root.
 
> > I believe you can combine IMA with EVM signed security attributes where
> > the EVM signing key is offline, and the verification key is in the
> > kernel.
> > 
> > The combination of IMA and EVM gets very close to being able to sign
> > executables offline and be able to update them.
> 
> [ Again CCing lkml and IMA/EVM folks ]
> 
> After little reading, my understanding is EVM also does not support
> offline signing. 
> 
> http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page
> 
> Given the fact EVM protects IMA data (security.ima), which is generated
> inline, I am not sure how EVM can sign images offline.
> 
> I might have misunderstood things, please correct me if that's not the
> case.
> 
> Thanks
> Vivek
> 

IMA-appraisal verifies the integrity of file data, while EVM verifies
the integrity of the file metadata, such as LSM and IMA-appraisal
labels.  Both 'security.ima' and 'security.evm' can contain digital
signatures.

thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:

[..]
> IMA-appraisal verifies the integrity of file data, while EVM verifies
> the integrity of the file metadata, such as LSM and IMA-appraisal
> labels.  Both 'security.ima' and 'security.evm' can contain digital
> signatures.

But the private key for creating these digital signature needs to be
on the target system?

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
> On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
> 
> [..]
> > IMA-appraisal verifies the integrity of file data, while EVM verifies
> > the integrity of the file metadata, such as LSM and IMA-appraisal
> > labels.  Both 'security.ima' and 'security.evm' can contain digital
> > signatures.
> 
> But the private key for creating these digital signature needs to be
> on the target system?
> 
> Thanks
> Vivek

Absolutely not.  The public key needs to be added to the _ima or _evm
keyrings.  Roberto Sassu modified dracut and later made equivalent
changes to systemd.  Both have been upstreamed.  Dmitry has a package
that labels the filesystem called ima-evm-utils, which supports hash
(IMA), hmac(EVM) and digital signatures(both).

We're hoping that distro's would label all immutable files, not only elf
executables, with digital signatures and mutable files with a hash.

thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote:
> On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
> > On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
> > 
> > [..]
> > > IMA-appraisal verifies the integrity of file data, while EVM verifies
> > > the integrity of the file metadata, such as LSM and IMA-appraisal
> > > labels.  Both 'security.ima' and 'security.evm' can contain digital
> > > signatures.
> > 
> > But the private key for creating these digital signature needs to be
> > on the target system?
> > 
> > Thanks
> > Vivek
> 
> Absolutely not.  The public key needs to be added to the _ima or _evm
> keyrings.  Roberto Sassu modified dracut and later made equivalent
> changes to systemd.  Both have been upstreamed.

Putting public key in _ima or _evm keyring is not the problem. This is
just the verification part.

> Dmitry has a package
> that labels the filesystem called ima-evm-utils, which supports hash
> (IMA), hmac(EVM) and digital signatures(both).
> 
> We're hoping that distro's would label all immutable files, not only elf
> executables, with digital signatures and mutable files with a hash.

So this labeling (digital signing) can happen at build time?

I suspect you need labeling to happen at system install time? If yes,
installer does not have the private key to sign anything.

IOW, if distro sign a file, they will most likely put signatures in
ELF header (something along the lines of signing PE/COFF binaries). But
I think you need digital signatures to be put in security.ima which are
stored in xattrs and xattrs are not generated till you put file in
question on target file system.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-10-25 at 14:55 -0400, Vivek Goyal wrote:
> On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote:
> > On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
> > > On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
> > > 
> > > [..]
> > > > IMA-appraisal verifies the integrity of file data, while EVM verifies
> > > > the integrity of the file metadata, such as LSM and IMA-appraisal
> > > > labels.  Both 'security.ima' and 'security.evm' can contain digital
> > > > signatures.
> > > 
> > > But the private key for creating these digital signature needs to be
> > > on the target system?
> > > 
> > > Thanks
> > > Vivek
> > 
> > Absolutely not.  The public key needs to be added to the _ima or _evm
> > keyrings.  Roberto Sassu modified dracut and later made equivalent
> > changes to systemd.  Both have been upstreamed.
> 
> Putting public key in _ima or _evm keyring is not the problem. This is
> just the verification part.
> 
> > Dmitry has a package
> > that labels the filesystem called ima-evm-utils, which supports hash
> > (IMA), hmac(EVM) and digital signatures(both).
> > 
> > We're hoping that distro's would label all immutable files, not only elf
> > executables, with digital signatures and mutable files with a hash.
> 
> So this labeling (digital signing) can happen at build time?

There is nothing inherently preventing it from happening at build time.
Elana Reshetova gave a talk at LSS 2012 on modifying RPM
http://lwn.net/Articles/518265/. 

> I suspect you need labeling to happen at system install time? If yes,
> installer does not have the private key to sign anything.

The installed system needs to be labeled, but how that occurs is
dependent on your environment (eg. flash, rpm based install).  Neither
of these mechanisms would require the build private key.

On a running system, the package installer, after verifying the package
integrity, would install each file with the associated 'security.ima'
extended attribute.  The 'security.evm' digital signature would be
installed with an HMAC, calculated using a system unique key. 

> IOW, if distro sign a file, they will most likely put signatures in
> ELF header (something along the lines of signing PE/COFF binaries). 

Rusty was definitely against putting the signature in the ELF header for
kernel modules.  Why would this be any different?

> But
> I think you need digital signatures to be put in security.ima which are
> stored in xattrs and xattrs are not generated till you put file in
> question on target file system.
> 
> Thanks
> Vivek

The 'security.ima' digital signature would be created as part of the
build process and stored as an extended attribute with the file, like
other metadata.  On install, the file, extended attributes and other
metadata would be copied to the target file system.

Mimi
 



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Matthew Garrett]

On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:

> On a running system, the package installer, after verifying the package
> integrity, would install each file with the associated 'security.ima'
> extended attribute.  The 'security.evm' digital signature would be
> installed with an HMAC, calculated using a system unique key. 

The idea isn't to prevent /sbin/kexec from being modified after 
installation - it's to prevent it from being possible to install a 
system that has a modified /sbin/kexec. Leaving any part of this up to 
the package installer means that it doesn't solve the problem we're 
trying to solve here. It must be impossible for the kernel to launch any 
/sbin/kexec that hasn't been signed by a trusted key that's been built 
into the kernel, and it must be impossible for anything other than 
/sbin/kexec to make the kexec system call.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Eric W. Biederman]

Matthew Garrett <mjg@redhat.com> writes:

> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
>
>> On a running system, the package installer, after verifying the package
>> integrity, would install each file with the associated 'security.ima'
>> extended attribute.  The 'security.evm' digital signature would be
>> installed with an HMAC, calculated using a system unique key. 
>
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec. Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

The 'security.capability' attribute modulo weirdness with the security
bounding set gives us the necessary tools to allow /sbin/kexec to make
the system call.

The primary trick with this is to limit the installer in such as way
that we can trust the installer even on a system on which root has been
compromised.

Trusting the installer is the same class of problem as trusting
/sbin/kexec, and to me a much more interesting problem as it keeps
critical system files from being tampered with.

It sounds like there are some tricky details to work through but this
direction of system integrity looks like it is worth pursuing,
regardless of how we handle a signed /sbin/kexec.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> 
> > On a running system, the package installer, after verifying the package
> > integrity, would install each file with the associated 'security.ima'
> > extended attribute.  The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key. 
> 
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec. Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

I am kind of lost now so just trying to summarize whatever I have
learned so far from this thread.

- So say we can sign /sbin/kexec at build time and distros can do that.
- Verify the signature at exec time using kernel keyring and if
  verification happens successfully, say process gains extra capability.
- Use this new capability to determine whether kexec_load() will be
  successful or not.

Even if we can do all this, it still has the issue of being able to
stop the process in user space and replace the code at run time
and be able to launch unsigned kernel.

So until and unless we have a good solution to verify application's
integrity/authneticity at the time of kexec_load() system call we
still have the problem. And I don't think we have come up with a
solution for that yet (until and unless I missed something).
  
Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote:
> On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> > 
> > > On a running system, the package installer, after verifying the package
> > > integrity, would install each file with the associated 'security.ima'
> > > extended attribute.  The 'security.evm' digital signature would be
> > > installed with an HMAC, calculated using a system unique key. 
> > 
> > The idea isn't to prevent /sbin/kexec from being modified after 
> > installation - it's to prevent it from being possible to install a 
> > system that has a modified /sbin/kexec. Leaving any part of this up to 
> > the package installer means that it doesn't solve the problem we're 
> > trying to solve here. It must be impossible for the kernel to launch any 
> > /sbin/kexec that hasn't been signed by a trusted key that's been built 
> > into the kernel, and it must be impossible for anything other than 
> > /sbin/kexec to make the kexec system call.
> 
> I am kind of lost now so just trying to summarize whatever I have
> learned so far from this thread.

Thanks for summarizing.

> - So say we can sign /sbin/kexec at build time and distros can do that.
> - Verify the signature at exec time using kernel keyring and if
>   verification happens successfully, say process gains extra capability.
> - Use this new capability to determine whether kexec_load() will be
>   successful or not.
> 
> Even if we can do all this, it still has the issue of being able to
> stop the process in user space and replace the code at run time
> and be able to launch unsigned kernel.
> 
> So until and unless we have a good solution to verify application's
> integrity/authneticity at the time of kexec_load() system call we
> still have the problem. And I don't think we have come up with a
> solution for that yet (until and unless I missed something).
>   
> Thanks
> Vivek
> 

Agreed, you need a new LSM/integrity hook.

thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Oct 26, 2012 at 02:37:29PM -0400, Mimi Zohar wrote:
> On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote:
> > On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> > > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> > > 
> > > > On a running system, the package installer, after verifying the package
> > > > integrity, would install each file with the associated 'security.ima'
> > > > extended attribute.  The 'security.evm' digital signature would be
> > > > installed with an HMAC, calculated using a system unique key. 
> > > 
> > > The idea isn't to prevent /sbin/kexec from being modified after 
> > > installation - it's to prevent it from being possible to install a 
> > > system that has a modified /sbin/kexec. Leaving any part of this up to 
> > > the package installer means that it doesn't solve the problem we're 
> > > trying to solve here. It must be impossible for the kernel to launch any 
> > > /sbin/kexec that hasn't been signed by a trusted key that's been built 
> > > into the kernel, and it must be impossible for anything other than 
> > > /sbin/kexec to make the kexec system call.
> > 
> > I am kind of lost now so just trying to summarize whatever I have
> > learned so far from this thread.
> 
> Thanks for summarizing.
> 
> > - So say we can sign /sbin/kexec at build time and distros can do that.
> > - Verify the signature at exec time using kernel keyring and if
> >   verification happens successfully, say process gains extra capability.
> > - Use this new capability to determine whether kexec_load() will be
> >   successful or not.
> > 
> > Even if we can do all this, it still has the issue of being able to
> > stop the process in user space and replace the code at run time
> > and be able to launch unsigned kernel.

Thinking more about it. Can we just keep track whether a process was
ptraced or not and disallow kexec_load() syscall if it was ptraced.
(I am assuming that ptrace is the only way to change process code/data).

So binaries can be signed offline. Signature verification can take place
using kernel keyring at exec() time. And we can keep track of ptraced
processes and disallow calling kexec_load() for such processes. If this
is implementable, this should take care of following requirement raised
by matthew.

************************************************************************
It must be impossible for the kernel to launch any /sbin/kexec that hasn't
been signed by a trusted key that's been built into the kernel, and it
must be impossible for anything other than /sbin/kexec to make the kexec
system call.
*************************************************************************

Thoughts?

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:

[..]
> > 
> > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > - Verify the signature at exec time using kernel keyring and if
> > >   verification happens successfully, say process gains extra capability.
> > > - Use this new capability to determine whether kexec_load() will be
> > >   successful or not.
> > > 
> > > Even if we can do all this, it still has the issue of being able to
> > > stop the process in user space and replace the code at run time
> > > and be able to launch unsigned kernel.
> 
> Thinking more about it. Can we just keep track whether a process was
> ptraced or not and disallow kexec_load() syscall if it was ptraced.
> (I am assuming that ptrace is the only way to change process code/data).
> 
> So binaries can be signed offline. Signature verification can take place
> using kernel keyring at exec() time. And we can keep track of ptraced
> processes and disallow calling kexec_load() for such processes. If this
> is implementable, this should take care of following requirement raised
> by matthew.
> 
> ************************************************************************
> It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> been signed by a trusted key that's been built into the kernel, and it
> must be impossible for anything other than /sbin/kexec to make the kexec
> system call.
> *************************************************************************
> 
> Thoughts?

Eric responded but my mistake he responded to only me. So I will quickly 
put his idea here.

[start quote]

You can't ptrace a process that has a capability you don't.

That should be enforced in security/commoncap/

[end quote]

This looks like a good idea. Upon verification signed binaries will be
assigned special capability and then no unsigned binary should be able
to ptrace signed/verified processes

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> 
> [..]
> > > 
> > > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > > - Verify the signature at exec time using kernel keyring and if
> > > >   verification happens successfully, say process gains extra capability.
> > > > - Use this new capability to determine whether kexec_load() will be
> > > >   successful or not.
> > > > 
> > > > Even if we can do all this, it still has the issue of being able to
> > > > stop the process in user space and replace the code at run time
> > > > and be able to launch unsigned kernel.
> > 
> > Thinking more about it. Can we just keep track whether a process was
> > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > (I am assuming that ptrace is the only way to change process code/data).
> > 
> > So binaries can be signed offline. Signature verification can take place
> > using kernel keyring at exec() time. And we can keep track of ptraced
> > processes and disallow calling kexec_load() for such processes. If this
> > is implementable, this should take care of following requirement raised
> > by matthew.
> > 
> > ************************************************************************
> > It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> > been signed by a trusted key that's been built into the kernel, and it
> > must be impossible for anything other than /sbin/kexec to make the kexec
> > system call.
> > *************************************************************************
> > 
> > Thoughts?
> 
> Eric responded but my mistake he responded to only me. So I will quickly 
> put his idea here.
> 
> [start quote]
> 
> You can't ptrace a process that has a capability you don't.
> 
> That should be enforced in security/commoncap/
> 
> [end quote]
> 
> This looks like a good idea. Upon verification signed binaries will be
> assigned special capability and then no unsigned binary should be able
> to ptrace signed/verified processes

That's a good generic solution, which I'm all in favor of, but it
doesn't resolve the latter half of Matthrew's requirement "and it must
be impossible for anything other than /sbin/kexec to make the kexec
system call."

thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote:
> On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> > 
> > [..]
> > > > 
> > > > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > > > - Verify the signature at exec time using kernel keyring and if
> > > > >   verification happens successfully, say process gains extra capability.
> > > > > - Use this new capability to determine whether kexec_load() will be
> > > > >   successful or not.
> > > > > 
> > > > > Even if we can do all this, it still has the issue of being able to
> > > > > stop the process in user space and replace the code at run time
> > > > > and be able to launch unsigned kernel.
> > > 
> > > Thinking more about it. Can we just keep track whether a process was
> > > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > > (I am assuming that ptrace is the only way to change process code/data).
> > > 
> > > So binaries can be signed offline. Signature verification can take place
> > > using kernel keyring at exec() time. And we can keep track of ptraced
> > > processes and disallow calling kexec_load() for such processes. If this
> > > is implementable, this should take care of following requirement raised
> > > by matthew.
> > > 
> > > ************************************************************************
> > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> > > been signed by a trusted key that's been built into the kernel, and it
> > > must be impossible for anything other than /sbin/kexec to make the kexec
> > > system call.
> > > *************************************************************************
> > > 
> > > Thoughts?
> > 
> > Eric responded but my mistake he responded to only me. So I will quickly 
> > put his idea here.
> > 
> > [start quote]
> > 
> > You can't ptrace a process that has a capability you don't.
> > 
> > That should be enforced in security/commoncap/
> > 
> > [end quote]
> > 
> > This looks like a good idea. Upon verification signed binaries will be
> > assigned special capability and then no unsigned binary should be able
> > to ptrace signed/verified processes
> 
> That's a good generic solution, which I'm all in favor of, but it
> doesn't resolve the latter half of Matthrew's requirement "and it must
> be impossible for anything other than /sbin/kexec to make the kexec
> system call."

Only those executables which have extended capability
(say CAP_SIGNATURES_VERIFIED) will be able to call kexec_load() syscall.
Only signed executables will get this capability upon signature verification
(using keys in kernel keyring only).

so any xyz executable will not be able to call kexec_load() until and
unless it is signed with keys kernel trusts. This is similar to signed
module verification.

So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you think?

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Matthew Garrett]

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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?

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Balbir Singh]

On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote:
> On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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.

Yes I have seen this. IIUC, it says that build libc with -enable-static-nss
and then individual programs need to statically build against the nss
modules program will use.

I think building libc with -enable-static-nss part will be unacceptable
for general server as other programs would like to make use of the
existing nss functionality.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Balbir Singh]

On Fri, Nov 2, 2012 at 8:06 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote:
>> On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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.
>
> Yes I have seen this. IIUC, it says that build libc with -enable-static-nss
> and then individual programs need to statically build against the nss
> modules program will use.
>
> I think building libc with -enable-static-nss part will be unacceptable
> for general server as other programs would like to make use of the
> existing nss functionality.

No, use that library for static linking only for programs that need to
be signed (kexec-tools), until the base OS gets signature support. Why
does the same library need to be used for general sever programs? The
built library would be used only on the build system.

I also like HPA's suggestion on using klibc, but I am not sure what it
would take to port the tools to use klibc

Balbir

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[H. Peter Anvin]

On 11/02/2012 07:29 AM, Balbir Singh wrote:
> 
> 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.
> 

You can build something with klibc... a static klibc binary can easily
be smaller than a dynamic glibc binary.

	-hpa



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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?

It needs to be checked but /sbin/kexec should not use any functions that
trigger nss switch.  No user or password or host name lookup should be
happening.

This is one part in hardening /sbin/kexec to deal with hostile root
users.  We need to check crazy things like do the files we open on /proc
actually point to /proc after we have opened them.

I believe glibc has some code which triggers for suid root applications
that we should ensure gets triggered that avoid trusting things like
LD_LIBRARY_PATH and company.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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?
> 
> It needs to be checked but /sbin/kexec should not use any functions that
> trigger nss switch.  No user or password or host name lookup should be
> happening.

I also think that we don't call routines which trigger nss switch but
be probably can't rely on that as somebody might introduce it in
future. So we need more robust mechanism to prevent it than just code
inspection.

> 
> This is one part in hardening /sbin/kexec to deal with hostile root
> users.  We need to check crazy things like do the files we open on /proc
> actually point to /proc after we have opened them.

Can you please explain it more. How can one fiddle with /proc. Also
what's the solution then.

> 
> I believe glibc has some code which triggers for suid root applications
> that we should ensure gets triggered that avoid trusting things like
> LD_LIBRARY_PATH and company.

I guess linking statically with uClibc or klibc (as hpa said), might turn
out to be better option to avoid all the issues w.r.t shared objects
and all the tricky environment variables.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
>> 
>> It needs to be checked but /sbin/kexec should not use any functions that
>> trigger nss switch.  No user or password or host name lookup should be
>> happening.
>
> I also think that we don't call routines which trigger nss switch but
> be probably can't rely on that as somebody might introduce it in
> future. So we need more robust mechanism to prevent it than just code
> inspection.

The fact that we shouldn't use those routines is enough to let us
walk down a path where they are not used.  Either with a static glibc
linked told to use no nss modules (--enable-static-nss ?), or with
another more restricted libc.

>> This is one part in hardening /sbin/kexec to deal with hostile root
>> users.  We need to check crazy things like do the files we open on /proc
>> actually point to /proc after we have opened them.
>
> Can you please explain it more. How can one fiddle with /proc. Also
> what's the solution then.

The solution is to just fstat the files and verify the filesystem from
which they came after the files have been opened.

The issue is that an evil root user may have mounted something else on /proc.

>> I believe glibc has some code which triggers for suid root applications
>> that we should ensure gets triggered that avoid trusting things like
>> LD_LIBRARY_PATH and company.
>
> I guess linking statically with uClibc or klibc (as hpa said), might turn
> out to be better option to avoid all the issues w.r.t shared objects
> and all the tricky environment variables.

Linking with a more restricted libc will solve most if not all shared
object issues.

We still need to audit our environment variable issue.  How we interpret
them and how our restricted libc automatically interprets them.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
> >> 
> >> It needs to be checked but /sbin/kexec should not use any functions that
> >> trigger nss switch.  No user or password or host name lookup should be
> >> happening.
> >
> > I also think that we don't call routines which trigger nss switch but
> > be probably can't rely on that as somebody might introduce it in
> > future. So we need more robust mechanism to prevent it than just code
> > inspection.
> 
> The fact that we shouldn't use those routines is enough to let us
> walk down a path where they are not used.  Either with a static glibc
> linked told to use no nss modules (--enable-static-nss ?), or with
> another more restricted libc.

Is there anything wrong with using uClibc? Trying to link again
customized glibc (with --enable-static-nss) sounds just extra work for
build environments. Are there know restricted libc or we need to create
one with passing more compile time options to libc.

Instead of doing more work in an attempt to create restricted libc,
it might be easier to just link against any already available
restricted library.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[H. Peter Anvin]

Yes, it is unlikely you can pare thibgs down more than klibc.

Vivek Goyal <vgoyal@redhat.com> wrote:

>On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
>> >> 
>> >> It needs to be checked but /sbin/kexec should not use any
>functions that
>> >> trigger nss switch.  No user or password or host name lookup
>should be
>> >> happening.
>> >
>> > I also think that we don't call routines which trigger nss switch
>but
>> > be probably can't rely on that as somebody might introduce it in
>> > future. So we need more robust mechanism to prevent it than just
>code
>> > inspection.
>> 
>> The fact that we shouldn't use those routines is enough to let us
>> walk down a path where they are not used.  Either with a static glibc
>> linked told to use no nss modules (--enable-static-nss ?), or with
>> another more restricted libc.
>
>Is there anything wrong with using uClibc? Trying to link again
>customized glibc (with --enable-static-nss) sounds just extra work for
>build environments. Are there know restricted libc or we need to create
>one with passing more compile time options to libc.
>
>Instead of doing more work in an attempt to create restricted libc,
>it might be easier to just link against any already available
>restricted library.
>
>Thanks
>Vivek

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
> >> 
> >> It needs to be checked but /sbin/kexec should not use any functions that
> >> trigger nss switch.  No user or password or host name lookup should be
> >> happening.
> >
> > I also think that we don't call routines which trigger nss switch but
> > be probably can't rely on that as somebody might introduce it in
> > future. So we need more robust mechanism to prevent it than just code
> > inspection.
> 
> The fact that we shouldn't use those routines is enough to let us
> walk down a path where they are not used.  Either with a static glibc
> linked told to use no nss modules (--enable-static-nss ?), or with
> another more restricted libc.

I installed glibc-static and built kexec-tools using gcc "-static" option.
It built just fine and infact kdump is working with it.

Size of new kexec binary is around 1.4MB.

Did not get any warning w.r.t nss, so I am assuming we are not calling
any relevant functions.

I did try building my own libc using --enable-static-nss but it does not
seem to have built static versions of libnss*. Will look more into it
and try linking kexec with this new glibc and see if that works.

Also tried playing with klibc and uclibc a bit but can't get anything
going quickly.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
>> >> 
>> >> It needs to be checked but /sbin/kexec should not use any functions that
>> >> trigger nss switch.  No user or password or host name lookup should be
>> >> happening.
>> >
>> > I also think that we don't call routines which trigger nss switch but
>> > be probably can't rely on that as somebody might introduce it in
>> > future. So we need more robust mechanism to prevent it than just code
>> > inspection.
>> 
>> The fact that we shouldn't use those routines is enough to let us
>> walk down a path where they are not used.  Either with a static glibc
>> linked told to use no nss modules (--enable-static-nss ?), or with
>> another more restricted libc.
>
> I installed glibc-static and built kexec-tools using gcc "-static" option.
> It built just fine and infact kdump is working with it.
>
> Size of new kexec binary is around 1.4MB.
>
> Did not get any warning w.r.t nss, so I am assuming we are not calling
> any relevant functions.
>
> I did try building my own libc using --enable-static-nss but it does not
> seem to have built static versions of libnss*. Will look more into it
> and try linking kexec with this new glibc and see if that works.
>
> Also tried playing with klibc and uclibc a bit but can't get anything
> going quickly.

Sounds good.  It has been about a year since I looked but kexec built
uclibc just fine last time I tried it.

Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:

[..]

Thnking more about executable signature verification, I have another question.

While verifyign the signature, we will have to read the whole executable
in memory. That sounds bad as we are in kernel mode and will not be killed
and if sombody is trying to execute a malformed exceptionally large
executable, system will start killing other processess. We can potentially
lock all the memory in kernel just by trying to execute a signed huge
executable. Not good.

I was looking at IMA and they seem to be using kernel_read() for reading
page in and update digest. IIUC, that means page is read from disk,
brought in cache and if needed will be read back from disk. But that
means hacker can try to do some timing tricks and try to replace disk image
after signature verification and run unsigned program.

So how do we go about it. Neither of the approaches sound appealing
to me.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> 
> [..]
> 
> Thnking more about executable signature verification, I have another question.
> 
> While verifyign the signature, we will have to read the whole executable
> in memory. That sounds bad as we are in kernel mode and will not be killed
> and if sombody is trying to execute a malformed exceptionally large
> executable, system will start killing other processess. We can potentially
> lock all the memory in kernel just by trying to execute a signed huge
> executable. Not good.
> 

Also, even if we try to read in whole executable, can't an hacker modify
pages in swap disk and then they will be faulted back in and bingo hacker
is running its unsigned code. (assuming root has been compromised otherwise
why do we have to do all this exercise).

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
>> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
>> 
>> [..]
>> 
>> Thnking more about executable signature verification, I have another question.
>> 
>> While verifyign the signature, we will have to read the whole executable
>> in memory. That sounds bad as we are in kernel mode and will not be killed
>> and if sombody is trying to execute a malformed exceptionally large
>> executable, system will start killing other processess. We can potentially
>> lock all the memory in kernel just by trying to execute a signed huge
>> executable. Not good.
>> 
>
> Also, even if we try to read in whole executable, can't an hacker modify
> pages in swap disk and then they will be faulted back in and bingo hacker
> is running its unsigned code. (assuming root has been compromised otherwise
> why do we have to do all this exercise).

You make a decent case for an implicit mlockall(MCL_FUTURE) being
required of signed executables, that are going to be granted privileges
based on signature verification.

As for size if the executable won't fit in memory, there is no point in
checking the signature.

It should be fairly straight forward to make the signature checking
process preemptable and killable.

Of course this is all hand waving at this point.

Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> >> 
> >> [..]
> >> 
> >> Thnking more about executable signature verification, I have another question.
> >> 
> >> While verifyign the signature, we will have to read the whole executable
> >> in memory. That sounds bad as we are in kernel mode and will not be killed
> >> and if sombody is trying to execute a malformed exceptionally large
> >> executable, system will start killing other processess. We can potentially
> >> lock all the memory in kernel just by trying to execute a signed huge
> >> executable. Not good.
> >> 
> >
> > Also, even if we try to read in whole executable, can't an hacker modify
> > pages in swap disk and then they will be faulted back in and bingo hacker
> > is running its unsigned code. (assuming root has been compromised otherwise
> > why do we have to do all this exercise).
> 
> You make a decent case for an implicit mlockall(MCL_FUTURE) being
> required of signed executables, that are going to be granted privileges
> based on signature verification.

implicity lockall for signed executables sounds reasonable to avoid the
swap hack.

> 
> As for size if the executable won't fit in memory, there is no point in
> checking the signature.

Well I am worried about malformed executables. One can sign a huge
executable (which is never meant to run successfully) and cause all
kind of memory issues. 

Can we first look at the signature, decrypt it using certificates in
kernel ring, and if we find out that executable was signed by any
of the certificates, only then we go on to read in whole executable
and try to calculate the digest. May be at the time of signing we can put
 a string, say "LINUX", along with digest and then sing/encrypt it. Upon
decryption we can check if LINUX is there and if yes, we know it was
signed by the certifcate loaded in kernel and then go on to load the
full executable and calculate digest.

Not sure if above is doable or not but if it is, it might reduce the
risk significantly as we will not try to integrity verify executables
not signed by genuine certificates.

> 
> It should be fairly straight forward to make the signature checking
> process preemptable and killable.

hmm..., not sure how to do this. Will have to read more code to understand
process killing and see what can I do this while I am in kernel mode
and I possibly might have done kernel memory allocations using
vmalloc()/kmalloc() etc.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
>> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
>> >> 
>> >> [..]
>> >> 
>> >> Thnking more about executable signature verification, I have another question.
>> >> 
>> >> While verifyign the signature, we will have to read the whole executable
>> >> in memory. That sounds bad as we are in kernel mode and will not be killed
>> >> and if sombody is trying to execute a malformed exceptionally large
>> >> executable, system will start killing other processess. We can potentially
>> >> lock all the memory in kernel just by trying to execute a signed huge
>> >> executable. Not good.
>> >> 
>> >
>> > Also, even if we try to read in whole executable, can't an hacker modify
>> > pages in swap disk and then they will be faulted back in and bingo hacker
>> > is running its unsigned code. (assuming root has been compromised otherwise
>> > why do we have to do all this exercise).
>> 
>> You make a decent case for an implicit mlockall(MCL_FUTURE) being
>> required of signed executables, that are going to be granted privileges
>> based on signature verification.
>
> implicity lockall for signed executables sounds reasonable to avoid the
> swap hack.
>
>> 
>> As for size if the executable won't fit in memory, there is no point in
>> checking the signature.
>
> Well I am worried about malformed executables. One can sign a huge
> executable (which is never meant to run successfully) and cause all
> kind of memory issues. 

Good point what to do with executables with invalid sigantures.  From
another reply it sounded like one of the bits of IMA/EVM had already
addressed part of that.

> Can we first look at the signature, decrypt it using certificates in
> kernel ring, and if we find out that executable was signed by any
> of the certificates, only then we go on to read in whole executable
> and try to calculate the digest. May be at the time of signing we can put
>  a string, say "LINUX", along with digest and then sing/encrypt it. Upon
> decryption we can check if LINUX is there and if yes, we know it was
> signed by the certifcate loaded in kernel and then go on to load the
> full executable and calculate digest.

> Not sure if above is doable or not but if it is, it might reduce the
> risk significantly as we will not try to integrity verify executables
> not signed by genuine certificates.

Known plaintext in the signed blob should allow that.  I would be very
careful with that because it sounds like the kind of thing that opens
you up to plain-text attacks, but that is mostly my parania and lack of
experience speaking.

>> It should be fairly straight forward to make the signature checking
>> process preemptable and killable.
>
> hmm..., not sure how to do this. Will have to read more code to understand
> process killing and see what can I do this while I am in kernel mode
> and I possibly might have done kernel memory allocations using
> vmalloc()/kmalloc() etc.

Well basically it is matter of using the killable version of waits
returning an error code as you unwind, and eventually either
force_sig(SIGKILL) or do_exit().

There are a lot of times where you can support SIGKILL and just cause
the process to exit where you can't handle signals.


Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Wed, 2012-11-14 at 21:09 -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
> >> Vivek Goyal <vgoyal@redhat.com> writes:
> >> 
> >> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
> >> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> >> >> 
> >> >> [..]
> >> >> 
> >> >> Thnking more about executable signature verification, I have another question.
> >> >> 
> >> >> While verifyign the signature, we will have to read the whole executable
> >> >> in memory. That sounds bad as we are in kernel mode and will not be killed
> >> >> and if sombody is trying to execute a malformed exceptionally large
> >> >> executable, system will start killing other processess. We can potentially
> >> >> lock all the memory in kernel just by trying to execute a signed huge
> >> >> executable. Not good.
> >> >> 
> >> >
> >> > Also, even if we try to read in whole executable, can't an hacker modify
> >> > pages in swap disk and then they will be faulted back in and bingo hacker
> >> > is running its unsigned code. (assuming root has been compromised otherwise
> >> > why do we have to do all this exercise).
> >> 
> >> You make a decent case for an implicit mlockall(MCL_FUTURE) being
> >> required of signed executables, that are going to be granted privileges
> >> based on signature verification.
> >
> > implicity lockall for signed executables sounds reasonable to avoid the
> > swap hack.
> >
> >> 
> >> As for size if the executable won't fit in memory, there is no point in
> >> checking the signature.
> >
> > Well I am worried about malformed executables. One can sign a huge
> > executable (which is never meant to run successfully) and cause all
> > kind of memory issues. 
> 
> Good point what to do with executables with invalid sigantures.  From
> another reply it sounded like one of the bits of IMA/EVM had already
> addressed part of that.

With IMA-appraisal enabled (enforcing mode), it would not be executed.

> > Can we first look at the signature, decrypt it using certificates in
> > kernel ring, and if we find out that executable was signed by any
> > of the certificates, only then we go on to read in whole executable
> > and try to calculate the digest. May be at the time of signing we can put
> >  a string, say "LINUX", along with digest and then sing/encrypt it. Upon
> > decryption we can check if LINUX is there and if yes, we know it was
> > signed by the certifcate loaded in kernel and then go on to load the
> > full executable and calculate digest.
> 
> > Not sure if above is doable or not but if it is, it might reduce the
> > risk significantly as we will not try to integrity verify executables
> > not signed by genuine certificates.
> 
> Known plaintext in the signed blob should allow that.  I would be very
> careful with that because it sounds like the kind of thing that opens
> you up to plain-text attacks, but that is mostly my parania and lack of
> experience speaking.

Although IMA (measurement and attestation), IMA-appraisal (local
integrity enforcement), and IMA auditing (logging hashes) can be enabled
individually, if any of these functions are enabled, then assuming the
file is in the IMA policy, the file will be hashed.  Remember if all
else fails, measurement and attestation is your last line of defense,
for detecting if your system has been compromised.

Mimi

> >> It should be fairly straight forward to make the signature checking
> >> process preemptable and killable.
> >
> > hmm..., not sure how to do this. Will have to read more code to understand
> > process killing and see what can I do this while I am in kernel mode
> > and I possibly might have done kernel memory allocations using
> > vmalloc()/kmalloc() etc.
> 
> Well basically it is matter of using the killable version of waits
> returning an error code as you unwind, and eventually either
> force_sig(SIGKILL) or do_exit().
> 
> There are a lot of times where you can support SIGKILL and just cause
> the process to exit where you can't handle signals.
> 
> 
> Eric
> 




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-11-08 at 14:40 -0500, Vivek Goyal wrote:
> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> 
> [..]
> 
> Thnking more about executable signature verification, I have another question.
> 
> While verifyign the signature, we will have to read the whole executable
> in memory. That sounds bad as we are in kernel mode and will not be killed
> and if sombody is trying to execute a malformed exceptionally large
> executable, system will start killing other processess. We can potentially
> lock all the memory in kernel just by trying to execute a signed huge
> executable. Not good.
> 
> I was looking at IMA and they seem to be using kernel_read() for reading
> page in and update digest. IIUC, that means page is read from disk,
> brought in cache and if needed will be read back from disk. But that
> means hacker can try to do some timing tricks and try to replace disk image
> after signature verification and run unsigned program.

For the reason you mentioned, the signature verification is deferred to
bprm, after the executable has been locked from modification.  Any
subsequent changes to the file would cause the file to be re-appraised.

The goal of EVM/IMA-appraisal is to detect file tampering and enforce
file data/metadata integrity.  If EVM/IMA-appraisal fail, then as a last
resort, we fall back and rely on IMA measurement/attestation at least to
detect it.

Mimi

> So how do we go about it. Neither of the approaches sound appealing
> to me.
> 
> Thanks
> Vivek




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote:
> On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> > 
> > [..]
> > > > 
> > > > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > > > - Verify the signature at exec time using kernel keyring and if
> > > > >   verification happens successfully, say process gains extra capability.
> > > > > - Use this new capability to determine whether kexec_load() will be
> > > > >   successful or not.
> > > > > 
> > > > > Even if we can do all this, it still has the issue of being able to
> > > > > stop the process in user space and replace the code at run time
> > > > > and be able to launch unsigned kernel.
> > > 
> > > Thinking more about it. Can we just keep track whether a process was
> > > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > > (I am assuming that ptrace is the only way to change process code/data).
> > > 
> > > So binaries can be signed offline. Signature verification can take place
> > > using kernel keyring at exec() time. And we can keep track of ptraced
> > > processes and disallow calling kexec_load() for such processes. If this
> > > is implementable, this should take care of following requirement raised
> > > by matthew.
> > > 
> > > ************************************************************************
> > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> > > been signed by a trusted key that's been built into the kernel, and it
> > > must be impossible for anything other than /sbin/kexec to make the kexec
> > > system call.
> > > *************************************************************************
> > > 
> > > Thoughts?
> > 
> > Eric responded but my mistake he responded to only me. So I will quickly 
> > put his idea here.
> > 
> > [start quote]
> > 
> > You can't ptrace a process that has a capability you don't.
> > 
> > That should be enforced in security/commoncap/
> > 
> > [end quote]
> > 
> > This looks like a good idea. Upon verification signed binaries will be
> > assigned special capability and then no unsigned binary should be able
> > to ptrace signed/verified processes
> 
> That's a good generic solution, which I'm all in favor of, but it
> doesn't resolve the latter half of Matthrew's requirement "and it must
> be impossible for anything other than /sbin/kexec to make the kexec
> system call."

I think what matthew might have meant that anything other than signed
trusted executable should not be able to call kexec_load(). Matthew?

And if one wants only /sbin/kexec to call it, then just sign that
one so no other executable will be able to call kexec_load(). Though
I don't think that's the requirement here. Requirement is that only
trusted executables should be able to call kexec_load().

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Matthew Garrett]

On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:

> And if one wants only /sbin/kexec to call it, then just sign that
> one so no other executable will be able to call kexec_load(). Though
> I don't think that's the requirement here. Requirement is that only
> trusted executables should be able to call kexec_load().

Where "trusted executables" means "signed by a key that's present in the 
system firmware or in the kernel that's signed with a key that's present 
in the system firmware", sure.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Khalid Aziz]

On Thu, 2012-11-01 at 14:57 +0000, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:
> 
> > And if one wants only /sbin/kexec to call it, then just sign that
> > one so no other executable will be able to call kexec_load(). Though
> > I don't think that's the requirement here. Requirement is that only
> > trusted executables should be able to call kexec_load().
> 
> Where "trusted executables" means "signed by a key that's present in the 
> system firmware or in the kernel that's signed with a key that's present 
> in the system firmware", sure.
> 

This is starting to sound too restrictive (even though I understand the
rationale behind the restrictions). Does this allow for a custom
userspace application that among other things also can kexec_load() a
new kernel and boot it, for example a customer unique health monitoring
app that reboots the system if things are not looking right on the
running system? How would a customer go about getting that userspace
binary signed and re-signed every time they update their app? There is
the option of turning the whole SecureBoot thing off for a system like
that but let us assume customer wants to leave that on or does not have
the option to turn it off?

--
Khalid


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Matthew Garrett]

On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> On Thu, 2012-11-01 at 14:57 +0000, Matthew Garrett wrote:
> > On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:
> > 
> > > And if one wants only /sbin/kexec to call it, then just sign that
> > > one so no other executable will be able to call kexec_load(). Though
> > > I don't think that's the requirement here. Requirement is that only
> > > trusted executables should be able to call kexec_load().
> > 
> > Where "trusted executables" means "signed by a key that's present in the 
> > system firmware or in the kernel that's signed with a key that's present 
> > in the system firmware", sure.
> > 
> 
> This is starting to sound too restrictive (even though I understand the
> rationale behind the restrictions). Does this allow for a custom
> userspace application that among other things also can kexec_load() a
> new kernel and boot it, for example a customer unique health monitoring
> app that reboots the system if things are not looking right on the
> running system?

Only if it's signed with a key that the kernel trusts.

> How would a customer go about getting that userspace binary signed and 
> re-signed every time they update their app? There is the option of 
> turning the whole SecureBoot thing off for a system like that but let 
> us assume customer wants to leave that on or does not have the option 
> to turn it off?

There's ongoing work for providing mechanisms for trusting user keys. If 
you want Secure Boot turned on, you don't want any untrusted code 
running in your kernel. If you're happy with untrusted code in your 
kernel, why are you using Secure Boot?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Khalid Aziz]

On Thu, 2012-11-01 at 16:23 +0000, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> > How would a customer go about getting that userspace binary signed and 
> > re-signed every time they update their app? There is the option of 
> > turning the whole SecureBoot thing off for a system like that but let 
> > us assume customer wants to leave that on or does not have the option 
> > to turn it off?
> 
> There's ongoing work for providing mechanisms for trusting user keys. If 
> you want Secure Boot turned on, you don't want any untrusted code 
> running in your kernel. If you're happy with untrusted code in your 
> kernel, why are you using Secure Boot?
> 

I would argue code written by a customer to run on their own systems is
inherently trusted code and does not invalidate need/desire for Secure
Boot. So the customer will still need some way to get their binary
signed very painlessly just so they could use their own binary on their
own system, simply because of a heavily locked down system design by
Linux community.

--
Khalid


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote:
> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> 
> > On a running system, the package installer, after verifying the package
> > integrity, would install each file with the associated 'security.ima'
> > extended attribute.  The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key. 
> 
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec.

Understood.

>  Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, 

With Dmitry's patch "5e0d1a4 ima: added policy support for security.ima
type", or something similar, we can force 'security.ima' to a specific
type, in this case, a digital signature.  With that patch, this
shouldn't be a problem.

> and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

Permission is a MAC issue. :)

thanks,

Mimi



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Matthew Garrett]

On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote:
> On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote:
> > and it must be impossible for anything other than 
> > /sbin/kexec to make the kexec system call.
> 
> Permission is a MAC issue. :)

It's a MAC issue that has to be implemented in the kernel. We can't 
depend on userspace loading any kind of policy.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump with signed images

[Mimi Zohar]

On Fri, 2012-10-26 at 19:19 +0100, Matthew Garrett wrote:
> On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote:
> > On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote:
> > > and it must be impossible for anything other than 
> > > /sbin/kexec to make the kexec system call.
> > 
> > Permission is a MAC issue. :)
> 
> It's a MAC issue that has to be implemented in the kernel. We can't 
> depend on userspace loading any kind of policy.

Still a MAC issue, that problably could be addressed by capabilities.  I
suggest you post this issue on the LSM mailing list.  Please cc: Serge,
as the capabilities maintainer.

thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Mon, Oct 22, 2012 at 02:07:56PM -0700, Eric W. Biederman wrote:
>
> [..]
>> > Can we pass all argument in one kexec segment and let associated image
>> > format handlers parse the arguments.
>> 
>> The issue is can we pass trusted arguments?  Any kind of firmware
>> callback ACPI, EFI, openfirmware etc needs to be in the trusted
>> parameter set so it must come from a trusted location.
>> 
>
> I think parameters will include something like read only one and second
> kernel should be able to verify it. It should not be an executable code
> of any form. (like acpi_rsdp).  I think this is similar to that we don't
> sign/verify kernel command line passed in a bootloader. 

I wasn't talking about the kernel command line.

>> Unless we can trust the /sbin/kexec binary we can't trust pointers
>> to executable code passed to us that we can not verify are safe.
>
> Given the fact we allow user to specify command line, even if we sign
> /sbin/kexec, we have no way to trust it. IMO here we just need to make
> sure that input parameters/arguments can't lead one to execute arbitrary
> code.

The x86 kernel boot protocol specifies a parameter block where the
address of the initrd etc is passed.  If we don't pass the acpi
parameter block via the command line it will come in that parameter
block.  How shrug.

>> >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
>> >> and it is conceivable to have ELF note sections with signatures for
>> >> executables.
>> >
>> > Can you please tell more about what is EMA and IMA. I did quick google
>> > and could not find much.
>> 
>> That should have been EVM and IMA.  Look under security/integrity/.  I
>> don't know much about them but they appear to be security modules with a
>> focus on verifying checksum or perhaps encrypted hashes of executables
>> are consistent.
>
> I will do some quick search there and I see if I can understand something.
>
> [..]
>> It just occurred to me there is a 4th approach we can take that seems
>> interesting.
>> 
>> Have a system call where you pass in a signature of yourself, that will
>> allow you to increase your set of capabilities.  I am a good binary here
>> is proof.  I initially that it might be a complement to sys_kexec_load
>> just for the kexec case but there is no reason to limit it.
>
> If one presents its own signature, then anybody can copy and present
> that signature. There needs to be a mechanism to verify that you 
> actually have the signature you are presenting (i mean digest of
> executable).
>
> So above does not address that how that new system call will verify the
> signature/hash of process invoking system call.

Of course it would.  A signature by it's very definition is a signed
digest.  You can present your own signature and the process that
presents that signature can be verified against the signature.

>> > - What happens to purgatory code. It is unsigned piece of code which
>> >   runs in kernel?
>> 
>> The purgatory code would need to be signed.  Which is why it is
>> important to enable composition of signed pieces of code.
>
> purgatory code is modified dynamically upon every invocation of kexec.
> That means there needs to be a mechanism to sign it after we are done
> with purgatory modification. But there are no signing keys available
> on the system. All the signing happens externally during build time. So
> we don't have the option of signing purgatory at run time.

Hogwash.

The only significant modification we make to purgatory is relocation
processing.  That relocation processing is a convinience, not a
necessity.  Potentially we could move the relocation processing into
purgatory itself.

To making signing work how we process and deal with purgatory would need
to be changed a bit, but fundmanetally signing purgatory or a couple
of specialized versions of purgatory is totally doable.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Tue, Oct 23, 2012 at 08:51:53AM -0700, Eric W. Biederman wrote:

[..]
> > purgatory code is modified dynamically upon every invocation of kexec.
> > That means there needs to be a mechanism to sign it after we are done
> > with purgatory modification. But there are no signing keys available
> > on the system. All the signing happens externally during build time. So
> > we don't have the option of signing purgatory at run time.
> 
> Hogwash.
> 
> The only significant modification we make to purgatory is relocation
> processing.  That relocation processing is a convinience, not a
> necessity.  Potentially we could move the relocation processing into
> purgatory itself.

Apart from relocations, we also set some variable values.

- Like entry point of kernel.
- Like address of backup region etc.

And all this information is dynamic and varies based on where memory for
second kernel was reserved. So until and unless we figure out a way to
solve that problem, we can't sign purgatory at build time.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote:

[..]
> > If we are ok with the idea of passing executables and initramfs to
> > kernel, then kernel can do the placement. That means fields "mem and
> > memsz fields of kexec_segment will be free. We can possibly overload
> > memsz field and pass flags to represent segment type. This will happen
> > only if user chooses kernel as bootloader functionality.
> 
> Which sounds nice initially but I don't think the notion of the kernel
> being a general purpose bootloader holds up to well.  It doesn't provide
> an easy place to put all of the weird cases.
> 
> If we are going to pass in a file it probably makes sense to do a
> variation of kexec_load that passes in a file descriptor, a filename
> could work but I don't think we want those races.

Can we use execve() style filenames. I am not sure what races are you
referring to.

> 
> But then we get how do we pass in a different kernel command line and
> an initrd.  Things that were simple start quickly becoming complex.

Can we take more than one filename arguments. Maybe an array of filename
arguements. And another array of arguments.

SYSCALL_DEFINE2(kexec2,
		const char __user *const __user *, filenamev
		const char __user *const __user *, argv)

This will allow passing filenames of both kernel and initrd and also
allow passing arguments. Arguments will also include command line.

Not asking user space to read in the file will help avoid loading
one extra copy of kernel in memory.

One difference here is though that we will have to allocate kernel memory
for full kernel image and full initd and if images are big, it can lock
down lot of kernel memory and in fact can trigger OOM on many processes.
I guess that's an issue with existing kexec() interface too, so nothing
new here.

This is like re-designing the kexec/kdump and I really wish there is
an easier way to handle the case signed kernels.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote:
>
> [..]
>> > If we are ok with the idea of passing executables and initramfs to
>> > kernel, then kernel can do the placement. That means fields "mem and
>> > memsz fields of kexec_segment will be free. We can possibly overload
>> > memsz field and pass flags to represent segment type. This will happen
>> > only if user chooses kernel as bootloader functionality.
>> 
>> Which sounds nice initially but I don't think the notion of the kernel
>> being a general purpose bootloader holds up to well.  It doesn't provide
>> an easy place to put all of the weird cases.
>> 
>> If we are going to pass in a file it probably makes sense to do a
>> variation of kexec_load that passes in a file descriptor, a filename
>> could work but I don't think we want those races.
>
> Can we use execve() style filenames. I am not sure what races are you
> referring to.

Files being renamed between the time we pick them and the time we use
them.  Classic programming practice uses file descriptors to allow
verifying the file you thought you had was the file you actually have.

>> But then we get how do we pass in a different kernel command line and
>> an initrd.  Things that were simple start quickly becoming complex.
>
> Can we take more than one filename arguments. Maybe an array of filename
> arguements. And another array of arguments.
>
> SYSCALL_DEFINE2(kexec2,
> 		const char __user *const __user *, filenamev
> 		const char __user *const __user *, argv)

The name would have to be kexec_load2 or perhaps kexec_load_file.

> This will allow passing filenames of both kernel and initrd and also
> allow passing arguments. Arguments will also include command line.
>
> Not asking user space to read in the file will help avoid loading
> one extra copy of kernel in memory.

There is that.  Although the difference between the page cache and in
an executables memory isn't particularly signficant.

> One difference here is though that we will have to allocate kernel memory
> for full kernel image and full initd and if images are big, it can lock
> down lot of kernel memory and in fact can trigger OOM on many processes.
> I guess that's an issue with existing kexec() interface too, so nothing
> new here.
>
> This is like re-designing the kexec/kdump and I really wish there is
> an easier way to handle the case signed kernels.

Yes.  Which is why either a signed puragtory or a signed /sbin/kexec
look very attractive.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[H. Peter Anvin]

On 10/22/2012 02:15 PM, Eric W. Biederman wrote:
>>
>> This is like re-designing the kexec/kdump and I really wish there is
>> an easier way to handle the case signed kernels.
> 
> Yes.  Which is why either a signed puragtory or a signed /sbin/kexec
> look very attractive.
> 

Signed purgatory sounds like The Right Thing.  Doing relocation in
purgatory should be quite trivial; I'd be happy to work with people if
they need pointers how to do it.

	-hpa



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Fri, Nov 02, 2012 at 02:36:11PM -0700, H. Peter Anvin wrote:
> On 10/22/2012 02:15 PM, Eric W. Biederman wrote:
> >>
> >> This is like re-designing the kexec/kdump and I really wish there is
> >> an easier way to handle the case signed kernels.
> > 
> > Yes.  Which is why either a signed puragtory or a signed /sbin/kexec
> > look very attractive.
> > 
> 
> Signed purgatory sounds like The Right Thing.  Doing relocation in
> purgatory should be quite trivial; I'd be happy to work with people if
> they need pointers how to do it.

So we sign purgatory and do the relocations in kernel later after
signature verification?

I have few questions though.

- We modify purgatory (update symbol values) in user space. That allows
  us to build single purgatory and chagne its behavior based on user
  options to kexec-tools (like 16bit vs 32bit entry, updating location
  of backup region etc). In fact purgatory to kernel jump location is
  decided at run time and purgatory is updated accordingly. That means
  we can't sign the purgatory.

  So apart from relocation, user space modification of purgatory code
  is also an issue. 

- Even if we come up with a way to avoid that, so will we not sign
  /sbin/kexec in that case? What happens to other unsigned segments
  loaded by /sbin/kexec. (boot_params, command line, elf headers etc).
  Can these be trusted without any signature.

So I am not sure that just signing the purgatory will solve the issue.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Fri, Nov 02, 2012 at 02:36:11PM -0700, H. Peter Anvin wrote:
>> On 10/22/2012 02:15 PM, Eric W. Biederman wrote:
>> >>
>> >> This is like re-designing the kexec/kdump and I really wish there is
>> >> an easier way to handle the case signed kernels.
>> > 
>> > Yes.  Which is why either a signed puragtory or a signed /sbin/kexec
>> > look very attractive.
>> > 
>> 
>> Signed purgatory sounds like The Right Thing.  Doing relocation in
>> purgatory should be quite trivial; I'd be happy to work with people if
>> they need pointers how to do it.
>
> So we sign purgatory and do the relocations in kernel later after
> signature verification?
>
> I have few questions though.
>
> - We modify purgatory (update symbol values) in user space. That allows
>   us to build single purgatory and chagne its behavior based on user
>   options to kexec-tools (like 16bit vs 32bit entry, updating location
>   of backup region etc). In fact purgatory to kernel jump location is
>   decided at run time and purgatory is updated accordingly. That means
>   we can't sign the purgatory.
>
>   So apart from relocation, user space modification of purgatory code
>   is also an issue. 
>
> - Even if we come up with a way to avoid that, so will we not sign
>   /sbin/kexec in that case? What happens to other unsigned segments
>   loaded by /sbin/kexec. (boot_params, command line, elf headers etc).
>   Can these be trusted without any signature.
>
> So I am not sure that just signing the purgatory will solve the issue.

The oddball part to add to this theory is that to sign purgatory may
imply moving more functionality into purgatory.  To the possible silly
point where we move most of kexec-tools into purgatory and do the work
in-between kernels (ick).

Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec