On Fri, Nov 22, 2013 at 07:23:39PM -0800, Eric W. Biederman wrote:
[..]
There is also a huge missing piece of this in that your purgatory is not
checking a hash of the loaded image before jumping too it. Without that
this is a huge regression at least for the kexec on panic case. We
Vivek Goyal vgo...@redhat.com writes:
Hi Eric,
So you want a separate purgatory code and that purgatory should be self
contained and should not share any code with rest of the kernel. No
inclusion of header files, no linking against kernel libraries? That means
even re-implementing sha256
Tested kdump and kexec using --use-kexec2-syscall on kenrel 3.13.0-rc2+,
they work very well.
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to
On Fri, 22 Nov 2013 05:34:03 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
Vivek Goyal vgo...@redhat.com writes:
There is also a huge missing piece of this in that your purgatory is not
checking a hash of the loaded image before jumping too it. Without that
this is a huge
On Mon, Nov 25, 2013 at 11:04:28AM +0100, Michael Holzheu wrote:
On Fri, 22 Nov 2013 05:34:03 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
Vivek Goyal vgo...@redhat.com writes:
There is also a huge missing piece of this in that your purgatory is not
checking a hash of the
On Mon, 25 Nov 2013 10:36:20 -0500
Vivek Goyal vgo...@redhat.com wrote:
On Mon, Nov 25, 2013 at 11:04:28AM +0100, Michael Holzheu wrote:
On Fri, 22 Nov 2013 05:34:03 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
Vivek Goyal vgo...@redhat.com writes:
There is also a huge
On Fri, Nov 22, 2013 at 2:55 AM, Vivek Goyal vgo...@redhat.com wrote:
Before you are done we need an ELF loader. bzImage really is very
uninteresting. To the point I am not at all convinced that an in kernel
loader should support it.
Hi Eric,
Why ELF case is so interesting. I have not use
On Fri, 22 Nov 2013, Geert Uytterhoeven wrote:
Why ELF case is so interesting. I have not use kexec to boot ELF
images in years and have not seen others using it too. In fact bzImage
seems to be the most common kernel image format for x86, most of the distros
ship and use.
So first I
On Fri, Nov 22, 2013 at 10:09:17AM +0100, Geert Uytterhoeven wrote:
On Fri, Nov 22, 2013 at 2:55 AM, Vivek Goyal vgo...@redhat.com wrote:
Before you are done we need an ELF loader. bzImage really is very
uninteresting. To the point I am not at all convinced that an in kernel
loader should
On Fri, Nov 22, 2013 at 02:30:17PM +0100, Jiri Kosina wrote:
On Fri, 22 Nov 2013, Geert Uytterhoeven wrote:
Why ELF case is so interesting. I have not use kexec to boot ELF
images in years and have not seen others using it too. In fact bzImage
seems to be the most common kernel image
On Fri, 22 Nov 2013, Vivek Goyal wrote:
OTOH, does this feature make any sense whatsover on architectures that
don't support secure boot anyway?
I guess if signed modules makes sense, then being able to kexec signed
kernel images should make sense too, in general.
Well, that's really a
On Fri, Nov 22, 2013 at 05:34:03AM -0800, Eric W. Biederman wrote:
[..]
Why ELF case is so interesting. I have not use kexec to boot ELF
images in years and have not seen others using it too. In fact bzImage
seems to be the most common kernel image format for x86, most of the distros
ship
On Fri, 22 Nov 2013, Geert Uytterhoeven wrote:
Only arm, i386, ppc, ppc64, sh, and x86_64 support zImage.
It's not clear to me what alpha supports (if it supports anything at all?).
Motiviation behind this patchset is secureboot. That is x86 specific
only and bzImage is most commonly
On Fri, Nov 22, 2013 at 10:33 AM, Jiri Kosina jkos...@suse.cz wrote:
On Fri, 22 Nov 2013, Geert Uytterhoeven wrote:
Only arm, i386, ppc, ppc64, sh, and x86_64 support zImage.
It's not clear to me what alpha supports (if it supports anything at
all?).
Motiviation behind this patchset
On Fri, 22 Nov 2013, Eric Paris wrote:
Consider a cloud provider who gives their customer a machine where
they, the cloud provider, is specifying the kernel and initrd. This
is a real thing that people do today. Root on the machine has ZERO
control over the kernel, bootloader, and initrd.
On Fri, Nov 22, 2013 at 05:04:04PM +0100, Jiri Kosina wrote:
On Fri, 22 Nov 2013, Eric Paris wrote:
Consider a cloud provider who gives their customer a machine where
they, the cloud provider, is specifying the kernel and initrd. This
is a real thing that people do today. Root on the
On Fri, Nov 22, 2013 at 02:50:43PM +0100, Jiri Kosina wrote:
On Fri, 22 Nov 2013, Vivek Goyal wrote:
OTOH, does this feature make any sense whatsover on architectures that
don't support secure boot anyway?
I guess if signed modules makes sense, then being able to kexec signed
On Fri, Nov 22, 2013 at 7:33 AM, Vivek Goyal vgo...@redhat.com wrote:
On Fri, Nov 22, 2013 at 02:50:43PM +0100, Jiri Kosina wrote:
On Fri, 22 Nov 2013, Vivek Goyal wrote:
OTOH, does this feature make any sense whatsover on architectures that
don't support secure boot anyway?
I guess
On Fri, Nov 22, 2013 at 09:19:46AM -0500, Vivek Goyal wrote:
On Fri, Nov 22, 2013 at 05:34:03AM -0800, Eric W. Biederman wrote:
[..]
Why ELF case is so interesting. I have not use kexec to boot ELF
images in years and have not seen others using it too. In fact bzImage
seems to be the
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 22, 2013 at 05:34:03AM -0800, Eric W. Biederman wrote:
[..]
Why ELF case is so interesting. I have not use kexec to boot ELF
images in years and have not seen others using it too. In fact bzImage
seems to be the most common kernel image
On Thu, Nov 21, 2013 at 08:06:02PM +0100, Geert Uytterhoeven wrote:
On Wed, Nov 20, 2013 at 6:50 PM, Vivek Goyal vgo...@redhat.com wrote:
Now a new system call kexec_file_load() is implemented which takes
kernel fd and initrd fd as parameters. Now kernel should be able
to verify signature
Vivek Goyal vgo...@redhat.com writes:
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to sign /sbin/kexec binary and let that binary do the kernel
signature verification. I had posted RFC
On Wed, Nov 20, 2013 at 6:50 PM, Vivek Goyal vgo...@redhat.com wrote:
Now a new system call kexec_file_load() is implemented which takes
kernel fd and initrd fd as parameters. Now kernel should be able
to verify signature of newly loaded kernel.
Only kernel fd and initrd fd?
What about other
(2013/11/21 2:50), Vivek Goyal wrote:
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to sign /sbin/kexec binary and let that binary do the kernel
signature verification. I had posted RFC
What do you need from ELF?
ebied...@xmission.com wrote:
Vivek Goyal vgo...@redhat.com writes:
Current proposed secureboot implementation disables kexec/kdump
because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to sign /sbin/kexec binary and let that binary do
On Wed, Nov 20, 2013 at 12:50:45PM -0500, Vivek Goyal wrote:
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to sign /sbin/kexec binary and let that binary do the kernel
signature
On Fri, Nov 22, 2013 at 09:55:15AM +0900, HATAYAMA Daisuke wrote:
(2013/11/21 2:50), Vivek Goyal wrote:
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to sign /sbin/kexec binary and let that
On Thu, Nov 21, 2013 at 05:28:38PM -0800, H. Peter Anvin wrote:
What do you need from ELF?
Sorry, I did not understand the question. Is it for me or Eric. I am
assuming you are asking Eric that why ELF is so important?
Thanks
Vivek
___
kexec mailing
Yes.
Vivek Goyal vgo...@redhat.com wrote:
On Thu, Nov 21, 2013 at 05:28:38PM -0800, H. Peter Anvin wrote:
What do you need from ELF?
Sorry, I did not understand the question. Is it for me or Eric. I am
assuming you are asking Eric that why ELF is so important?
Thanks
Vivek
--
Sent from my
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to sign /sbin/kexec binary and let that binary do the kernel
signature verification. I had posted RFC patches for this apparoach
here.
30 matches
Mail list logo
