Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric W. Biederman]

Vivek Goyal  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 functions separately (like user space)?

Call only trivial sharing of code with the rest of the kernel.   But only
as much as say the kernel decompressor has.  

> If code maintenance is a concern, then I think I can reimplement some
> of the functions to calculate sha256 in separate crash files and invoke
> those to reduce code sharing with rest of the kernel. And we should be
> able to link against the kernel and not have to create separate
> relocatable purgatory object and relocate it.

It is both code maintenance and the fact that we have a strong
expectation that where purgatory lives should not be corrupted.
Plus what I have seen there maintenance becomes much simpler if there is
a little bit of C code that lives between the two kernels.  At that
point people don't have to grok assembly to be able to touch anything,
and by simply living their it enforces separation of concerns
from the kernel in a way that is trivial and obvious.

Plus we already have all of the code in userspace to do all of this work
so it is not something you would need to write from scrach merely
something that you would need to adapt.

> IOW, does purgatory still have to be a relocatable object?

Fundamentally purgatory does need to be a relocatable object.

> I think
> user space had no choice but given the fact that we are implementing
> thing in kernel, I should be able to implement my own hash calculation
> and segment verification code and link it to existing kernel and invoke
> these outside purgatory. 

Doing this outside of purgatory and linking to the rest of the kernel is
almost certainly enough to get someone to perform an obvious cleanup
that will undermine the purpose of the code.  Or perhaps it will be
merely a reference to the GOT table behind our backs in the C code
generated by the compiler that will undermine this checking.

Linking to our sanity checks to the rest of the kernel leaves me
profoundly uncomfortable.

> Anyway, we call so many other functions after
> crash to stop cpus, save registers, etc.

There is no other possible place to stop cpus, and save the cpu
registers.  As much as possible that should be the only justification
for the code we run on the kexec on panic code path.

Honestly calling so many other functions on that code path is a good
reason to see about removing them.  In addition to my other reasons
adding the hash calculation on that path will likely confuse issues
more than helping them.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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
> >> >> absolutely need to check that the kernel sitting around in memory has
> >> >> not been corrupted before we let it run very far.
> >> >
> >> > Agreed. This should not be hard. It is just a matter of calcualting
> >> > digest of segments. I will store it in kimge and verify digest again
> >> > before passing control to control page. Will fix it in next version.
> >> 
> >> Nak.  The verification needs to happen in purgatory. 
> >> 
> >> The verification needs to happen in code whose runtime environment is
> >> does not depend on random parts of the kernel.  Anything else is a
> >> regression in maintainability and reliability.
> >> 
> >> It is the wrong direction to add any code to what needs to run in the
> >> known broken environment of the kernel when a panic happens.
> >> 
> >> Which means that you almost certainly need to go to the trouble of
> >> supporting the complexity needed to support purgatory code written in C.
> >> 
> >> (For those just tuning in purgatory is our term for the code that runs
> >> between the kernels to do those things that can not happen a priori).
> >
> > In general, I agree with not using kernel parts after crash.
> >
> > But what protects against that purgatory itself has been scribbled over.
> > IOW, how different purgatory memory is as compared to kernel memory where
> > digest routines are stored. They have got equal probably of being scribbled
> > over and if that's the case one is not better than other?
> >
> > And if they both got equal probability to getting corrupted, then there does
> > not seem to be an advantage in moving digest verification inside
> > purgatory.
> 
> The primary reason is that maintenance of code in the kernel that is
> safe during a crash dump is hard.  That is why we boot a second kernel
> after all.  If the code to do the signature verification resides in
> machine_kexec on the kexec on panic code path in the kernel that has
> called panic it is almost a given that at some point or other someone
> will add an option that will add a weird dependency that makes the code
> unsafe when the kernel is crashing.  I have seen it happen several times
> on the existing kexec on panic code path.  I have seen it on other code
> paths like netconsole.  Which can currently on some kernels I have
> running cause the kernel go go into an endless printk loop if you call
> printk from interrupt context.  So what we really gain by moving the
> verification into purgatory is protection from inappropriate code reuse.
> 
> So having a completely separate piece of code may be a little harder to
> write initially but the code is much simpler and more reliable to
> maintain.  Essentially requiring no maintenance effort.  Further getting
> to the point where purgatory is written in C makes small changes much
> more approachable.

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 functions separately (like user space)?

If code maintenance is a concern, then I think I can reimplement some
of the functions to calculate sha256 in separate crash files and invoke
those to reduce code sharing with rest of the kernel. And we should be
able to link against the kernel and not have to create separate
relocatable purgatory object and relocate it.

IOW, does purgatory still have to be a relocatable object? I think
user space had no choice but given the fact that we are implementing
thing in kernel, I should be able to implement my own hash calculation
and segment verification code and link it to existing kernel and invoke
these outside purgatory. Anyway, we call so many other functions after
crash to stop cpus, save registers, etc.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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
   absolutely need to check that the kernel sitting around in memory has
   not been corrupted before we let it run very far.
  
   Agreed. This should not be hard. It is just a matter of calcualting
   digest of segments. I will store it in kimge and verify digest again
   before passing control to control page. Will fix it in next version.
  
  Nak.  The verification needs to happen in purgatory. 
  
  The verification needs to happen in code whose runtime environment is
  does not depend on random parts of the kernel.  Anything else is a
  regression in maintainability and reliability.
  
  It is the wrong direction to add any code to what needs to run in the
  known broken environment of the kernel when a panic happens.
  
  Which means that you almost certainly need to go to the trouble of
  supporting the complexity needed to support purgatory code written in C.
  
  (For those just tuning in purgatory is our term for the code that runs
  between the kernels to do those things that can not happen a priori).
 
  In general, I agree with not using kernel parts after crash.
 
  But what protects against that purgatory itself has been scribbled over.
  IOW, how different purgatory memory is as compared to kernel memory where
  digest routines are stored. They have got equal probably of being scribbled
  over and if that's the case one is not better than other?
 
  And if they both got equal probability to getting corrupted, then there does
  not seem to be an advantage in moving digest verification inside
  purgatory.
 
 The primary reason is that maintenance of code in the kernel that is
 safe during a crash dump is hard.  That is why we boot a second kernel
 after all.  If the code to do the signature verification resides in
 machine_kexec on the kexec on panic code path in the kernel that has
 called panic it is almost a given that at some point or other someone
 will add an option that will add a weird dependency that makes the code
 unsafe when the kernel is crashing.  I have seen it happen several times
 on the existing kexec on panic code path.  I have seen it on other code
 paths like netconsole.  Which can currently on some kernels I have
 running cause the kernel go go into an endless printk loop if you call
 printk from interrupt context.  So what we really gain by moving the
 verification into purgatory is protection from inappropriate code reuse.
 
 So having a completely separate piece of code may be a little harder to
 write initially but the code is much simpler and more reliable to
 maintain.  Essentially requiring no maintenance effort.  Further getting
 to the point where purgatory is written in C makes small changes much
 more approachable.

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 functions separately (like user space)?

If code maintenance is a concern, then I think I can reimplement some
of the functions to calculate sha256 in separate crash files and invoke
those to reduce code sharing with rest of the kernel. And we should be
able to link against the kernel and not have to create separate
relocatable purgatory object and relocate it.

IOW, does purgatory still have to be a relocatable object? I think
user space had no choice but given the fact that we are implementing
thing in kernel, I should be able to implement my own hash calculation
and segment verification code and link it to existing kernel and invoke
these outside purgatory. Anyway, we call so many other functions after
crash to stop cpus, save registers, etc.

Thanks
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric W. Biederman]

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 functions separately (like user space)?

Call only trivial sharing of code with the rest of the kernel.   But only
as much as say the kernel decompressor has.  

 If code maintenance is a concern, then I think I can reimplement some
 of the functions to calculate sha256 in separate crash files and invoke
 those to reduce code sharing with rest of the kernel. And we should be
 able to link against the kernel and not have to create separate
 relocatable purgatory object and relocate it.

It is both code maintenance and the fact that we have a strong
expectation that where purgatory lives should not be corrupted.
Plus what I have seen there maintenance becomes much simpler if there is
a little bit of C code that lives between the two kernels.  At that
point people don't have to grok assembly to be able to touch anything,
and by simply living their it enforces separation of concerns
from the kernel in a way that is trivial and obvious.

Plus we already have all of the code in userspace to do all of this work
so it is not something you would need to write from scrach merely
something that you would need to adapt.

 IOW, does purgatory still have to be a relocatable object?

Fundamentally purgatory does need to be a relocatable object.

 I think
 user space had no choice but given the fact that we are implementing
 thing in kernel, I should be able to implement my own hash calculation
 and segment verification code and link it to existing kernel and invoke
 these outside purgatory. 

Doing this outside of purgatory and linking to the rest of the kernel is
almost certainly enough to get someone to perform an obvious cleanup
that will undermine the purpose of the code.  Or perhaps it will be
merely a reference to the GOT table behind our backs in the C code
generated by the compiler that will undermine this checking.

Linking to our sanity checks to the rest of the kernel leaves me
profoundly uncomfortable.

 Anyway, we call so many other functions after
 crash to stop cpus, save registers, etc.

There is no other possible place to stop cpus, and save the cpu
registers.  As much as possible that should be the only justification
for the code we run on the kexec on panic code path.

Honestly calling so many other functions on that code path is a good
reason to see about removing them.  In addition to my other reasons
adding the hash calculation on that path will likely confuse issues
more than helping them.

Eric

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Baoquan He]

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 sign /sbin/kexec binary and let that binary do the kernel
> signature verification. I had posted RFC patches for this apparoach
> here.
> 
> https://lkml.org/lkml/2013/9/10/560
> 
> Later we had discussion at Plumbers and most of the people thought
> that signing and trusting /sbin/kexec is becoming complex. So a 
> better idea might be let kernel do the signature verification of
> new kernel being loaded. This calls for implementing a new system call
> and moving lot of user space code in kernel.
> 
> kexec_load() system call allows loading a kexec/kdump kernel and jump
> to that kernel at right time. Though a lot of processing is done in
> user space which prepares a list of segments/buffers to be loaded and
> kexec_load() works on that list of segments. It does not know what's
> contained in those segments.
> 
> 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. 
> 
> This is an early RFC patchset. I have not done signature handling
> part yet. This is more of a minimal patch to show how new system
> call and functionality will look like. Right now it can only handle
> bzImage with 64bit entry point on x86_64. No EFI, no x86_32  or any
> other architecture. Rest of the things can be added slowly as need
> arises. In first iteration, I have tried to address most common use case
> for us.
> 
> Any feedback is welcome.
> 
> Vivek Goyal (6):
>   kexec: Export vmcoreinfo note size properly
>   kexec: Move segment verification code in a separate function
>   resource: Provide new functions to walk through resources
>   kexec: A new system call, kexec_file_load, for in kernel kexec
>   kexec-bzImage: Support for loading bzImage using 64bit entry
>   kexec: Support for Kexec on panic using new system call
> 
>  arch/x86/include/asm/crash.h |9 +
>  arch/x86/include/asm/kexec-bzimage.h |   12 +
>  arch/x86/include/asm/kexec.h |   43 ++
>  arch/x86/kernel/Makefile |2 +
>  arch/x86/kernel/crash.c  |  585 +++
>  arch/x86/kernel/kexec-bzimage.c  |  420 +++
>  arch/x86/kernel/machine_kexec_64.c   |   60 +++-
>  arch/x86/kernel/purgatory_entry_64.S |  119 ++
>  arch/x86/syscalls/syscall_64.tbl |1 +
>  include/linux/ioport.h   |6 +
>  include/linux/kexec.h|   57 +++
>  include/linux/syscalls.h |3 +
>  include/uapi/linux/kexec.h   |4 +
>  kernel/kexec.c   |  731 
> ++
>  kernel/ksysfs.c  |2 +-
>  kernel/resource.c|  108 +-
>  kernel/sys_ni.c  |1 +
>  17 files changed, 2074 insertions(+), 89 deletions(-)
>  create mode 100644 arch/x86/include/asm/crash.h
>  create mode 100644 arch/x86/include/asm/kexec-bzimage.h
>  create mode 100644 arch/x86/kernel/kexec-bzimage.c
>  create mode 100644 arch/x86/kernel/purgatory_entry_64.S
> 
> -- 
> 1.7.7.6
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Baoquan He]

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 sign /sbin/kexec binary and let that binary do the kernel
 signature verification. I had posted RFC patches for this apparoach
 here.
 
 https://lkml.org/lkml/2013/9/10/560
 
 Later we had discussion at Plumbers and most of the people thought
 that signing and trusting /sbin/kexec is becoming complex. So a 
 better idea might be let kernel do the signature verification of
 new kernel being loaded. This calls for implementing a new system call
 and moving lot of user space code in kernel.
 
 kexec_load() system call allows loading a kexec/kdump kernel and jump
 to that kernel at right time. Though a lot of processing is done in
 user space which prepares a list of segments/buffers to be loaded and
 kexec_load() works on that list of segments. It does not know what's
 contained in those segments.
 
 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. 
 
 This is an early RFC patchset. I have not done signature handling
 part yet. This is more of a minimal patch to show how new system
 call and functionality will look like. Right now it can only handle
 bzImage with 64bit entry point on x86_64. No EFI, no x86_32  or any
 other architecture. Rest of the things can be added slowly as need
 arises. In first iteration, I have tried to address most common use case
 for us.
 
 Any feedback is welcome.
 
 Vivek Goyal (6):
   kexec: Export vmcoreinfo note size properly
   kexec: Move segment verification code in a separate function
   resource: Provide new functions to walk through resources
   kexec: A new system call, kexec_file_load, for in kernel kexec
   kexec-bzImage: Support for loading bzImage using 64bit entry
   kexec: Support for Kexec on panic using new system call
 
  arch/x86/include/asm/crash.h |9 +
  arch/x86/include/asm/kexec-bzimage.h |   12 +
  arch/x86/include/asm/kexec.h |   43 ++
  arch/x86/kernel/Makefile |2 +
  arch/x86/kernel/crash.c  |  585 +++
  arch/x86/kernel/kexec-bzimage.c  |  420 +++
  arch/x86/kernel/machine_kexec_64.c   |   60 +++-
  arch/x86/kernel/purgatory_entry_64.S |  119 ++
  arch/x86/syscalls/syscall_64.tbl |1 +
  include/linux/ioport.h   |6 +
  include/linux/kexec.h|   57 +++
  include/linux/syscalls.h |3 +
  include/uapi/linux/kexec.h   |4 +
  kernel/kexec.c   |  731 
 ++
  kernel/ksysfs.c  |2 +-
  kernel/resource.c|  108 +-
  kernel/sys_ni.c  |1 +
  17 files changed, 2074 insertions(+), 89 deletions(-)
  create mode 100644 arch/x86/include/asm/crash.h
  create mode 100644 arch/x86/include/asm/kexec-bzimage.h
  create mode 100644 arch/x86/kernel/kexec-bzimage.c
  create mode 100644 arch/x86/kernel/purgatory_entry_64.S
 
 -- 
 1.7.7.6
 
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Michael Holzheu]

On Mon, 25 Nov 2013 10:36:20 -0500
Vivek Goyal  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  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 regression at least for the kexec on panic case.  We
> > > >> absolutely need to check that the kernel sitting around in memory has
> > > >> not been corrupted before we let it run very far.
> > > >
> > > > Agreed. This should not be hard. It is just a matter of calcualting
> > > > digest of segments. I will store it in kimge and verify digest again
> > > > before passing control to control page. Will fix it in next version.
> > > 
> > > Nak.  The verification needs to happen in purgatory. 
> > > 
> > > The verification needs to happen in code whose runtime environment is
> > > does not depend on random parts of the kernel.  Anything else is a
> > > regression in maintainability and reliability.
> > 
> > Hello Vivek,
> > 
> > Just to be sure that you have not forgotten the following s390 detail:
> > 
> > On s390 we first call purgatory with parameter "0" for doing the
> > checksum test. If this fails, we can have as backup solution our
> > traditional stand-alone dump. In case tha checksum test was ok,
> > we call purgatory a second time with parameter "1" which then
> > starts kdump.
> > 
> > Could you please ensure that this mechanism also works after
> > your rework.
> 
> Hi Michael,
> 
> All that logic in in arch dependent portion of s390? If yes, I am not
> touching any arch dependent part of s390 yet and only doing implementation
> of x86.

Yes, part of s390 architecture code (kernel and kexec purgatory).

kernel:
---
arch/s390/kernel/machine_kexec.c:
 kdump_csum_valid() -> rc = start_kdump(0);
 __do_machine_kdump() -> start_kdump(1)

kexec tools:

purgatory/arch/s390/setup-s390.S
  cghi %r2,0
  je verify_checksums

> Generic changes should be usable by s390 and you should be able to do
> same thing there. Though we are still detating whether segment checksum
> verification logic should be part of purgatory or core kernel.

Yes, that was my concern. If you move the purgatory checksum logic to
the kernel we probably have to consider our s390 checksum test.

Thanks!
Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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  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 regression at least for the kexec on panic case.  We
> > >> absolutely need to check that the kernel sitting around in memory has
> > >> not been corrupted before we let it run very far.
> > >
> > > Agreed. This should not be hard. It is just a matter of calcualting
> > > digest of segments. I will store it in kimge and verify digest again
> > > before passing control to control page. Will fix it in next version.
> > 
> > Nak.  The verification needs to happen in purgatory. 
> > 
> > The verification needs to happen in code whose runtime environment is
> > does not depend on random parts of the kernel.  Anything else is a
> > regression in maintainability and reliability.
> 
> Hello Vivek,
> 
> Just to be sure that you have not forgotten the following s390 detail:
> 
> On s390 we first call purgatory with parameter "0" for doing the
> checksum test. If this fails, we can have as backup solution our
> traditional stand-alone dump. In case tha checksum test was ok,
> we call purgatory a second time with parameter "1" which then
> starts kdump.
> 
> Could you please ensure that this mechanism also works after
> your rework.

Hi Michael,

All that logic in in arch dependent portion of s390? If yes, I am not
touching any arch dependent part of s390 yet and only doing implementation
of x86.

Generic changes should be usable by s390 and you should be able to do
same thing there. Though we are still detating whether segment checksum
verification logic should be part of purgatory or core kernel.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Michael Holzheu]

On Fri, 22 Nov 2013 05:34:03 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:

> Vivek Goyal  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 regression at least for the kexec on panic case.  We
> >> absolutely need to check that the kernel sitting around in memory has
> >> not been corrupted before we let it run very far.
> >
> > Agreed. This should not be hard. It is just a matter of calcualting
> > digest of segments. I will store it in kimge and verify digest again
> > before passing control to control page. Will fix it in next version.
> 
> Nak.  The verification needs to happen in purgatory. 
> 
> The verification needs to happen in code whose runtime environment is
> does not depend on random parts of the kernel.  Anything else is a
> regression in maintainability and reliability.

Hello Vivek,

Just to be sure that you have not forgotten the following s390 detail:

On s390 we first call purgatory with parameter "0" for doing the
checksum test. If this fails, we can have as backup solution our
traditional stand-alone dump. In case tha checksum test was ok,
we call purgatory a second time with parameter "1" which then
starts kdump.

Could you please ensure that this mechanism also works after
your rework.

Best Regards,
Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Michael Holzheu]

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 regression at least for the kexec on panic case.  We
  absolutely need to check that the kernel sitting around in memory has
  not been corrupted before we let it run very far.
 
  Agreed. This should not be hard. It is just a matter of calcualting
  digest of segments. I will store it in kimge and verify digest again
  before passing control to control page. Will fix it in next version.
 
 Nak.  The verification needs to happen in purgatory. 
 
 The verification needs to happen in code whose runtime environment is
 does not depend on random parts of the kernel.  Anything else is a
 regression in maintainability and reliability.

Hello Vivek,

Just to be sure that you have not forgotten the following s390 detail:

On s390 we first call purgatory with parameter 0 for doing the
checksum test. If this fails, we can have as backup solution our
traditional stand-alone dump. In case tha checksum test was ok,
we call purgatory a second time with parameter 1 which then
starts kdump.

Could you please ensure that this mechanism also works after
your rework.

Best Regards,
Michael

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 loaded image before jumping too it.  Without that
   this is a huge regression at least for the kexec on panic case.  We
   absolutely need to check that the kernel sitting around in memory has
   not been corrupted before we let it run very far.
  
   Agreed. This should not be hard. It is just a matter of calcualting
   digest of segments. I will store it in kimge and verify digest again
   before passing control to control page. Will fix it in next version.
  
  Nak.  The verification needs to happen in purgatory. 
  
  The verification needs to happen in code whose runtime environment is
  does not depend on random parts of the kernel.  Anything else is a
  regression in maintainability and reliability.
 
 Hello Vivek,
 
 Just to be sure that you have not forgotten the following s390 detail:
 
 On s390 we first call purgatory with parameter 0 for doing the
 checksum test. If this fails, we can have as backup solution our
 traditional stand-alone dump. In case tha checksum test was ok,
 we call purgatory a second time with parameter 1 which then
 starts kdump.
 
 Could you please ensure that this mechanism also works after
 your rework.

Hi Michael,

All that logic in in arch dependent portion of s390? If yes, I am not
touching any arch dependent part of s390 yet and only doing implementation
of x86.

Generic changes should be usable by s390 and you should be able to do
same thing there. Though we are still detating whether segment checksum
verification logic should be part of purgatory or core kernel.

Thanks
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Michael Holzheu]

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 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
absolutely need to check that the kernel sitting around in memory has
not been corrupted before we let it run very far.
   
Agreed. This should not be hard. It is just a matter of calcualting
digest of segments. I will store it in kimge and verify digest again
before passing control to control page. Will fix it in next version.
   
   Nak.  The verification needs to happen in purgatory. 
   
   The verification needs to happen in code whose runtime environment is
   does not depend on random parts of the kernel.  Anything else is a
   regression in maintainability and reliability.
  
  Hello Vivek,
  
  Just to be sure that you have not forgotten the following s390 detail:
  
  On s390 we first call purgatory with parameter 0 for doing the
  checksum test. If this fails, we can have as backup solution our
  traditional stand-alone dump. In case tha checksum test was ok,
  we call purgatory a second time with parameter 1 which then
  starts kdump.
  
  Could you please ensure that this mechanism also works after
  your rework.
 
 Hi Michael,
 
 All that logic in in arch dependent portion of s390? If yes, I am not
 touching any arch dependent part of s390 yet and only doing implementation
 of x86.

Yes, part of s390 architecture code (kernel and kexec purgatory).

kernel:
---
arch/s390/kernel/machine_kexec.c:
 kdump_csum_valid() - rc = start_kdump(0);
 __do_machine_kdump() - start_kdump(1)

kexec tools:

purgatory/arch/s390/setup-s390.S
  cghi %r2,0
  je verify_checksums

 Generic changes should be usable by s390 and you should be able to do
 same thing there. Though we are still detating whether segment checksum
 verification logic should be part of purgatory or core kernel.

Yes, that was my concern. If you move the purgatory checksum logic to
the kernel we probably have to consider our s390 checksum test.

Thanks!
Michael

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric W. Biederman]

Vivek Goyal  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 format for x86, most of the 
>> > distros
>> > ship and use.
>> 
>> ELF is interesting because it is the minimal file format that does
>> everything you need.   So especially for a proof of concept ELF needs to
>> come first.  There is an extra virtual address field in the ELF segment
>> header but otherwise ELF does not have any unnecessary fields.
>> 
>> ELF is interesting because it is the native kernel file format on all
>> architectures linux supports including x86.
>> 
>> ELF is interesting because producing an ELF image in practice requires
>> a trivial amount of tooling so it is a good general purpose format to
>> support.
>
> Ok. I will have a look at ELF loader too. I was hoping to keep only one
> loader in initial patch. But looks like that's not acceptable.

Thank you.  We really need an ELF loader to see that we have handled the
general case and to see that we have a solution that is portable to
non-x86.

> [..]
>> >> 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
>> >> absolutely need to check that the kernel sitting around in memory has
>> >> not been corrupted before we let it run very far.
>> >
>> > Agreed. This should not be hard. It is just a matter of calcualting
>> > digest of segments. I will store it in kimge and verify digest again
>> > before passing control to control page. Will fix it in next version.
>> 
>> Nak.  The verification needs to happen in purgatory. 
>> 
>> The verification needs to happen in code whose runtime environment is
>> does not depend on random parts of the kernel.  Anything else is a
>> regression in maintainability and reliability.
>> 
>> It is the wrong direction to add any code to what needs to run in the
>> known broken environment of the kernel when a panic happens.
>> 
>> Which means that you almost certainly need to go to the trouble of
>> supporting the complexity needed to support purgatory code written in C.
>> 
>> (For those just tuning in purgatory is our term for the code that runs
>> between the kernels to do those things that can not happen a priori).
>
> In general, I agree with not using kernel parts after crash.
>
> But what protects against that purgatory itself has been scribbled over.
> IOW, how different purgatory memory is as compared to kernel memory where
> digest routines are stored. They have got equal probably of being scribbled
> over and if that's the case one is not better than other?
>
> And if they both got equal probability to getting corrupted, then there does
> not seem to be an advantage in moving digest verification inside
> purgatory.

The primary reason is that maintenance of code in the kernel that is
safe during a crash dump is hard.  That is why we boot a second kernel
after all.  If the code to do the signature verification resides in
machine_kexec on the kexec on panic code path in the kernel that has
called panic it is almost a given that at some point or other someone
will add an option that will add a weird dependency that makes the code
unsafe when the kernel is crashing.  I have seen it happen several times
on the existing kexec on panic code path.  I have seen it on other code
paths like netconsole.  Which can currently on some kernels I have
running cause the kernel go go into an endless printk loop if you call
printk from interrupt context.  So what we really gain by moving the
verification into purgatory is protection from inappropriate code reuse.

So having a completely separate piece of code may be a little harder to
write initially but the code is much simpler and more reliable to
maintain.  Essentially requiring no maintenance effort.  Further getting
to the point where purgatory is written in C makes small changes much
more approachable.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Greg KH]

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 most common kernel image format for x86, most of the 
> > > distros
> > > ship and use.
> > 
> > ELF is interesting because it is the minimal file format that does
> > everything you need.   So especially for a proof of concept ELF needs to
> > come first.  There is an extra virtual address field in the ELF segment
> > header but otherwise ELF does not have any unnecessary fields.
> > 
> > ELF is interesting because it is the native kernel file format on all
> > architectures linux supports including x86.
> > 
> > ELF is interesting because producing an ELF image in practice requires
> > a trivial amount of tooling so it is a good general purpose format to
> > support.
> 
> Ok. I will have a look at ELF loader too. I was hoping to keep only one
> loader in initial patch. But looks like that's not acceptable.

I totally disagree.  I think what you have done now is fine.  If it
works for bzImage, it's a good sense that this is usable as-is.

And, if someone else cares about signed elf images, hey, let them
implement the loader for it :)

Either way, the syscall interface wouldn't change, which is the
important thing to get right, so you should be fine for now.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Kees Cook]

On Fri, Nov 22, 2013 at 7:33 AM, Vivek Goyal  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 if signed modules makes sense, then being able to kexec signed
>> > kernel images should make sense too, in general.
>>
>> Well, that's really a grey zone, I'd say.
>>
>> In a non-secureboot environment, if you are root, you are able to issue
>> reboot into a completely different, self-made kernel anyway, independent
>> on whether signed modules are used or not.
>
> That's a good poing. Frankly speaking I don't know if there is a good
> use case to allow loading signed kernels only or not.
>
> Kees mentioned that he would like to know where the kernel came from
> and whether it came from trusted disk or not. So he does seem to have
> a use case where he wants to launch only trusted kernel or deny execution.

Correct. Though to clarify, Chrome OS doesn't use UEFI SecureBoot: we
have a different solution that uses dm-verity to give us a trusted
read-only root filesystem. As long as things live on that filesystem,
we trust them. (This is why finit_module was added, and why I wanted
to make sure kexec used fd instead of "just" a memory blob.)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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
> > kernel images should make sense too, in general.
> 
> Well, that's really a grey zone, I'd say.
> 
> In a non-secureboot environment, if you are root, you are able to issue 
> reboot into a completely different, self-made kernel anyway, independent 
> on whether signed modules are used or not.

That's a good poing. Frankly speaking I don't know if there is a good
use case to allow loading signed kernels only or not.

Kees mentioned that he would like to know where the kernel came from
and whether it came from trusted disk or not. So he does seem to have
a use case where he wants to launch only trusted kernel or deny execution.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 machine has ZERO
> > control over the kernel, bootloader, and initrd.  Check it out,
> > qemu/kvm can do this.  But, there is no way to disable kexec if the
> > distro configures it in (well, there is in RHEL at least).  
> 
> If that root can load LKMs, access /dev/mem, or whatever else, there is 
> not really a point disabling kexec anyway, is the same thing can be 
> implemented (although with more hassle, of course) through these channels 
> as well.

I am assuming that in above scenario, kernel will run in locked down
mode (something what matthew implemented for secureboot). Where /dev/mem
write access will be disabled and only signed modules will be loaded.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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.  Check it out,
> qemu/kvm can do this.  But, there is no way to disable kexec if the
> distro configures it in (well, there is in RHEL at least).  

If that root can load LKMs, access /dev/mem, or whatever else, there is 
not really a point disabling kexec anyway, is the same thing can be 
implemented (although with more hassle, of course) through these channels 
as well.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric Paris]

On Fri, Nov 22, 2013 at 10:33 AM, Jiri Kosina  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 is secureboot. That is x86 specific
>> > only and bzImage is most commonly used format on that platform. So it
>> > makes sense to implement bzImage loader first, IMO.
>>
>> While secureboot(TM) may be x86-centric
>
> And ARM, right?
>
>> IIRC actually loading signed kernels and modules didn't originate on
>> x86. Anything can have a bootloader that accepts signed kernel images
>> only.
>
> Yes, but if you don't have the whole secure boot security model (i.e. root
> is implicitly untrusted), it's all just a game really.
>
> If you are playing this "signed kernel and modules" game, but have trusted
> root, he's free to replace the bootloader by one that wouldn't be
> verifying the kernel signature, and reboot into arbitrary kernel.

Ignore secureboot completely.

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.  Check it out,
qemu/kvm can do this.  But, there is no way to disable kexec if the
distro configures it in (well, there is in RHEL at least).  I've
brought this up before with little useful response from the kexec
maintainers.  What I'd like is for a kernel trusted by me, the cloud
operator, to be able to be kexec'd.  I'd rather not have to completely
turn off kexec...

Make sense how this is useful for things other than secureboot?  And
we have users who want this.  This is not a speculative completely
made up maybe some day someone will want this type idea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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 used format on that platform. So it
> > makes sense to implement bzImage loader first, IMO.
> 
> While secureboot(TM) may be x86-centric

And ARM, right?

> IIRC actually loading signed kernels and modules didn't originate on 
> x86. Anything can have a bootloader that accepts signed kernel images 
> only.

Yes, but if you don't have the whole secure boot security model (i.e. root 
is implicitly untrusted), it's all just a game really.

If you are playing this "signed kernel and modules" game, but have trusted 
root, he's free to replace the bootloader by one that wouldn't be 
verifying the kernel signature, and reboot into arbitrary kernel.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Geert Uytterhoeven]

On Fri, Nov 22, 2013 at 2:43 PM, Vivek Goyal  wrote:
>> Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
>> s390, sh, and x86_64 support ELF.
>
> How many of them use ELF to boot in real world? Also one can easily
> add ELF loader. I am just not able to see why ELF loader should be
> a requirement for this patchset.

Many bootloaders support ELF.

>> 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 used format on that platform. So it
> makes sense to implement bzImage loader first, IMO.

While secureboot(TM) may be x86-centric, IIRC actually loading signed kernels
and modules didn't originate on x86. Anything can have a bootloader that
accepts signed kernel images only.

Even without the signing, I like the simplicity of the new syscall, moving
some bookkeeping to and keeping some info in the kernel (e.g. the kernel
no longer needs to export system RAM chunks and device tree or
bootinfo).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 and use.
> 
> ELF is interesting because it is the minimal file format that does
> everything you need.   So especially for a proof of concept ELF needs to
> come first.  There is an extra virtual address field in the ELF segment
> header but otherwise ELF does not have any unnecessary fields.
> 
> ELF is interesting because it is the native kernel file format on all
> architectures linux supports including x86.
> 
> ELF is interesting because producing an ELF image in practice requires
> a trivial amount of tooling so it is a good general purpose format to
> support.

Ok. I will have a look at ELF loader too. I was hoping to keep only one
loader in initial patch. But looks like that's not acceptable.

[..]
> >> 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
> >> absolutely need to check that the kernel sitting around in memory has
> >> not been corrupted before we let it run very far.
> >
> > Agreed. This should not be hard. It is just a matter of calcualting
> > digest of segments. I will store it in kimge and verify digest again
> > before passing control to control page. Will fix it in next version.
> 
> Nak.  The verification needs to happen in purgatory. 
> 
> The verification needs to happen in code whose runtime environment is
> does not depend on random parts of the kernel.  Anything else is a
> regression in maintainability and reliability.
> 
> It is the wrong direction to add any code to what needs to run in the
> known broken environment of the kernel when a panic happens.
> 
> Which means that you almost certainly need to go to the trouble of
> supporting the complexity needed to support purgatory code written in C.
> 
> (For those just tuning in purgatory is our term for the code that runs
> between the kernels to do those things that can not happen a priori).

In general, I agree with not using kernel parts after crash.

But what protects against that purgatory itself has been scribbled over.
IOW, how different purgatory memory is as compared to kernel memory where
digest routines are stored. They have got equal probably of being scribbled
over and if that's the case one is not better than other?

And if they both got equal probability to getting corrupted, then there does
not seem to be an advantage in moving digest verification inside purgatory.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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 grey zone, I'd say.

In a non-secureboot environment, if you are root, you are able to issue 
reboot into a completely different, self-made kernel anyway, independent 
on whether signed modules are used or not.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 format for x86, most of the 
> > > distros
> > > ship and use.
> > >
> > > So first I did the loader for the common use case. There is no reason
> > > that one can't write another loader for ELF images. It just bloats
> > > the code. Hence I thought that other image loaders can follow slowly. I am
> > > not sure why do you say that bzImage is uninteresting.
> > 
> > Welcome to the non-x86-centric world ;-)
> > 
> > Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, 
> > ppc64,
> > s390, sh, and x86_64 support ELF.
> > 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?).
> 
> 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.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

On Fri, Nov 22, 2013 at 10:09:17AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 22, 2013 at 2:55 AM, Vivek Goyal  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 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 did the loader for the common use case. There is no reason
> > that one can't write another loader for ELF images. It just bloats
> > the code. Hence I thought that other image loaders can follow slowly. I am
> > not sure why do you say that bzImage is uninteresting.
> 
> Welcome to the non-x86-centric world ;-)
> 
> Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
> s390, sh, and x86_64 support ELF.

How many of them use ELF to boot in real world? Also one can easily
add ELF loader. I am just not able to see why ELF loader should be
a requirement for this patchset.

> 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 used format on that platform. So it
makes sense to implement bzImage loader first, IMO.

One should be able to add support for more image loaders later as need
arises across different architectures.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric W. Biederman]

Vivek Goyal  writes:

> On Thu, Nov 21, 2013 at 03:07:04PM -0800, Eric W. Biederman 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 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.

ELF is interesting because it is the minimal file format that does
everything you need.   So especially for a proof of concept ELF needs to
come first.  There is an extra virtual address field in the ELF segment
header but otherwise ELF does not have any unnecessary fields.

ELF is interesting because it is the native kernel file format on all
architectures linux supports including x86.

ELF is interesting because producing an ELF image in practice requires
a trivial amount of tooling so it is a good general purpose format to
support.

> So first I did the loader for the common use case. There is no reason 
> that one can't write another loader for ELF images. It just bloats
> the code. Hence I thought that other image loaders can follow slowly. I am
> not sure why do you say that bzImage is uninteresting. 

If you boot anything that isn't a linux kernel bzImage on x86 bzImage is
not the solution you are using.  Furthermore because bzImage is a bunch
of hacks thrown together bzImage keeps evolving in weird and strange
ways.  The complexity of supporting bzImage only grows through the
years.

At the end of the day we will probably need to support bzImage in some
form (possibly just going so far as in userspace extracting the embedded
ELF image) as there are support benefits of only having one blob you
sling around.

But let's first start with the sane general case before worring about x86
legacy weirdness.

For a long term stable ABI to support booting things other than the
linux kernel bzImage is not my first choice.

>> 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
>> absolutely need to check that the kernel sitting around in memory has
>> not been corrupted before we let it run very far.
>
> Agreed. This should not be hard. It is just a matter of calcualting
> digest of segments. I will store it in kimge and verify digest again
> before passing control to control page. Will fix it in next version.

Nak.  The verification needs to happen in purgatory. 

The verification needs to happen in code whose runtime environment is
does not depend on random parts of the kernel.  Anything else is a
regression in maintainability and reliability.

It is the wrong direction to add any code to what needs to run in the
known broken environment of the kernel when a panic happens.

Which means that you almost certainly need to go to the trouble of
supporting the complexity needed to support purgatory code written in C.

(For those just tuning in purgatory is our term for the code that runs
between the kernels to do those things that can not happen a priori).

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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 did the loader for the common use case. There is no reason
> > that one can't write another loader for ELF images. It just bloats
> > the code. Hence I thought that other image loaders can follow slowly. I am
> > not sure why do you say that bzImage is uninteresting.
> 
> Welcome to the non-x86-centric world ;-)
> 
> Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
> s390, sh, and x86_64 support ELF.
> 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?).

OTOH, does this feature make any sense whatsover on architectures that 
don't support secure boot anyway?

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Geert Uytterhoeven]

On Fri, Nov 22, 2013 at 2:55 AM, Vivek Goyal  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 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 did the loader for the common use case. There is no reason
> that one can't write another loader for ELF images. It just bloats
> the code. Hence I thought that other image loaders can follow slowly. I am
> not sure why do you say that bzImage is uninteresting.

Welcome to the non-x86-centric world ;-)

Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
s390, sh, and x86_64 support ELF.
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?).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Geert Uytterhoeven]

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 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 did the loader for the common use case. There is no reason
 that one can't write another loader for ELF images. It just bloats
 the code. Hence I thought that other image loaders can follow slowly. I am
 not sure why do you say that bzImage is uninteresting.

Welcome to the non-x86-centric world ;-)

Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
s390, sh, and x86_64 support ELF.
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?).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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 did the loader for the common use case. There is no reason
  that one can't write another loader for ELF images. It just bloats
  the code. Hence I thought that other image loaders can follow slowly. I am
  not sure why do you say that bzImage is uninteresting.
 
 Welcome to the non-x86-centric world ;-)
 
 Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
 s390, sh, and x86_64 support ELF.
 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?).

OTOH, does this feature make any sense whatsover on architectures that 
don't support secure boot anyway?

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric W. Biederman]

Vivek Goyal vgo...@redhat.com writes:

 On Thu, Nov 21, 2013 at 03:07:04PM -0800, Eric W. Biederman 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 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.

ELF is interesting because it is the minimal file format that does
everything you need.   So especially for a proof of concept ELF needs to
come first.  There is an extra virtual address field in the ELF segment
header but otherwise ELF does not have any unnecessary fields.

ELF is interesting because it is the native kernel file format on all
architectures linux supports including x86.

ELF is interesting because producing an ELF image in practice requires
a trivial amount of tooling so it is a good general purpose format to
support.

 So first I did the loader for the common use case. There is no reason 
 that one can't write another loader for ELF images. It just bloats
 the code. Hence I thought that other image loaders can follow slowly. I am
 not sure why do you say that bzImage is uninteresting. 

If you boot anything that isn't a linux kernel bzImage on x86 bzImage is
not the solution you are using.  Furthermore because bzImage is a bunch
of hacks thrown together bzImage keeps evolving in weird and strange
ways.  The complexity of supporting bzImage only grows through the
years.

At the end of the day we will probably need to support bzImage in some
form (possibly just going so far as in userspace extracting the embedded
ELF image) as there are support benefits of only having one blob you
sling around.

But let's first start with the sane general case before worring about x86
legacy weirdness.

For a long term stable ABI to support booting things other than the
linux kernel bzImage is not my first choice.

 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
 absolutely need to check that the kernel sitting around in memory has
 not been corrupted before we let it run very far.

 Agreed. This should not be hard. It is just a matter of calcualting
 digest of segments. I will store it in kimge and verify digest again
 before passing control to control page. Will fix it in next version.

Nak.  The verification needs to happen in purgatory. 

The verification needs to happen in code whose runtime environment is
does not depend on random parts of the kernel.  Anything else is a
regression in maintainability and reliability.

It is the wrong direction to add any code to what needs to run in the
known broken environment of the kernel when a panic happens.

Which means that you almost certainly need to go to the trouble of
supporting the complexity needed to support purgatory code written in C.

(For those just tuning in purgatory is our term for the code that runs
between the kernels to do those things that can not happen a priori).

Eric
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 support it.
 
  Hi Eric,
 
  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 did the loader for the common use case. There is no reason
  that one can't write another loader for ELF images. It just bloats
  the code. Hence I thought that other image loaders can follow slowly. I am
  not sure why do you say that bzImage is uninteresting.
 
 Welcome to the non-x86-centric world ;-)
 
 Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
 s390, sh, and x86_64 support ELF.

How many of them use ELF to boot in real world? Also one can easily
add ELF loader. I am just not able to see why ELF loader should be
a requirement for this patchset.

 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 used format on that platform. So it
makes sense to implement bzImage loader first, IMO.

One should be able to add support for more image loaders later as need
arises across different architectures.

Thanks
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 format for x86, most of the 
   distros
   ship and use.
  
   So first I did the loader for the common use case. There is no reason
   that one can't write another loader for ELF images. It just bloats
   the code. Hence I thought that other image loaders can follow slowly. I am
   not sure why do you say that bzImage is uninteresting.
  
  Welcome to the non-x86-centric world ;-)
  
  Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, 
  ppc64,
  s390, sh, and x86_64 support ELF.
  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?).
 
 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.

Thanks
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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 grey zone, I'd say.

In a non-secureboot environment, if you are root, you are able to issue 
reboot into a completely different, self-made kernel anyway, independent 
on whether signed modules are used or not.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 and use.
 
 ELF is interesting because it is the minimal file format that does
 everything you need.   So especially for a proof of concept ELF needs to
 come first.  There is an extra virtual address field in the ELF segment
 header but otherwise ELF does not have any unnecessary fields.
 
 ELF is interesting because it is the native kernel file format on all
 architectures linux supports including x86.
 
 ELF is interesting because producing an ELF image in practice requires
 a trivial amount of tooling so it is a good general purpose format to
 support.

Ok. I will have a look at ELF loader too. I was hoping to keep only one
loader in initial patch. But looks like that's not acceptable.

[..]
  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
  absolutely need to check that the kernel sitting around in memory has
  not been corrupted before we let it run very far.
 
  Agreed. This should not be hard. It is just a matter of calcualting
  digest of segments. I will store it in kimge and verify digest again
  before passing control to control page. Will fix it in next version.
 
 Nak.  The verification needs to happen in purgatory. 
 
 The verification needs to happen in code whose runtime environment is
 does not depend on random parts of the kernel.  Anything else is a
 regression in maintainability and reliability.
 
 It is the wrong direction to add any code to what needs to run in the
 known broken environment of the kernel when a panic happens.
 
 Which means that you almost certainly need to go to the trouble of
 supporting the complexity needed to support purgatory code written in C.
 
 (For those just tuning in purgatory is our term for the code that runs
 between the kernels to do those things that can not happen a priori).

In general, I agree with not using kernel parts after crash.

But what protects against that purgatory itself has been scribbled over.
IOW, how different purgatory memory is as compared to kernel memory where
digest routines are stored. They have got equal probably of being scribbled
over and if that's the case one is not better than other?

And if they both got equal probability to getting corrupted, then there does
not seem to be an advantage in moving digest verification inside purgatory.

Thanks
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Geert Uytterhoeven]

On Fri, Nov 22, 2013 at 2:43 PM, Vivek Goyal vgo...@redhat.com wrote:
 Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
 s390, sh, and x86_64 support ELF.

 How many of them use ELF to boot in real world? Also one can easily
 add ELF loader. I am just not able to see why ELF loader should be
 a requirement for this patchset.

Many bootloaders support ELF.

 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 used format on that platform. So it
 makes sense to implement bzImage loader first, IMO.

While secureboot(TM) may be x86-centric, IIRC actually loading signed kernels
and modules didn't originate on x86. Anything can have a bootloader that
accepts signed kernel images only.

Even without the signing, I like the simplicity of the new syscall, moving
some bookkeeping to and keeping some info in the kernel (e.g. the kernel
no longer needs to export system RAM chunks and device tree or
bootinfo).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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 used format on that platform. So it
  makes sense to implement bzImage loader first, IMO.
 
 While secureboot(TM) may be x86-centric

And ARM, right?

 IIRC actually loading signed kernels and modules didn't originate on 
 x86. Anything can have a bootloader that accepts signed kernel images 
 only.

Yes, but if you don't have the whole secure boot security model (i.e. root 
is implicitly untrusted), it's all just a game really.

If you are playing this signed kernel and modules game, but have trusted 
root, he's free to replace the bootloader by one that wouldn't be 
verifying the kernel signature, and reboot into arbitrary kernel.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric Paris]

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 is secureboot. That is x86 specific
  only and bzImage is most commonly used format on that platform. So it
  makes sense to implement bzImage loader first, IMO.

 While secureboot(TM) may be x86-centric

 And ARM, right?

 IIRC actually loading signed kernels and modules didn't originate on
 x86. Anything can have a bootloader that accepts signed kernel images
 only.

 Yes, but if you don't have the whole secure boot security model (i.e. root
 is implicitly untrusted), it's all just a game really.

 If you are playing this signed kernel and modules game, but have trusted
 root, he's free to replace the bootloader by one that wouldn't be
 verifying the kernel signature, and reboot into arbitrary kernel.

Ignore secureboot completely.

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.  Check it out,
qemu/kvm can do this.  But, there is no way to disable kexec if the
distro configures it in (well, there is in RHEL at least).  I've
brought this up before with little useful response from the kexec
maintainers.  What I'd like is for a kernel trusted by me, the cloud
operator, to be able to be kexec'd.  I'd rather not have to completely
turn off kexec...

Make sense how this is useful for things other than secureboot?  And
we have users who want this.  This is not a speculative completely
made up maybe some day someone will want this type idea
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Jiri Kosina]

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.  Check it out,
 qemu/kvm can do this.  But, there is no way to disable kexec if the
 distro configures it in (well, there is in RHEL at least).  

If that root can load LKMs, access /dev/mem, or whatever else, there is 
not really a point disabling kexec anyway, is the same thing can be 
implemented (although with more hassle, of course) through these channels 
as well.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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 machine has ZERO
  control over the kernel, bootloader, and initrd.  Check it out,
  qemu/kvm can do this.  But, there is no way to disable kexec if the
  distro configures it in (well, there is in RHEL at least).  
 
 If that root can load LKMs, access /dev/mem, or whatever else, there is 
 not really a point disabling kexec anyway, is the same thing can be 
 implemented (although with more hassle, of course) through these channels 
 as well.

I am assuming that in above scenario, kernel will run in locked down
mode (something what matthew implemented for secureboot). Where /dev/mem
write access will be disabled and only signed modules will be loaded.

Thanks
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Vivek Goyal]

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
  kernel images should make sense too, in general.
 
 Well, that's really a grey zone, I'd say.
 
 In a non-secureboot environment, if you are root, you are able to issue 
 reboot into a completely different, self-made kernel anyway, independent 
 on whether signed modules are used or not.

That's a good poing. Frankly speaking I don't know if there is a good
use case to allow loading signed kernels only or not.

Kees mentioned that he would like to know where the kernel came from
and whether it came from trusted disk or not. So he does seem to have
a use case where he wants to launch only trusted kernel or deny execution.

Thanks
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Kees Cook]

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 if signed modules makes sense, then being able to kexec signed
  kernel images should make sense too, in general.

 Well, that's really a grey zone, I'd say.

 In a non-secureboot environment, if you are root, you are able to issue
 reboot into a completely different, self-made kernel anyway, independent
 on whether signed modules are used or not.

 That's a good poing. Frankly speaking I don't know if there is a good
 use case to allow loading signed kernels only or not.

 Kees mentioned that he would like to know where the kernel came from
 and whether it came from trusted disk or not. So he does seem to have
 a use case where he wants to launch only trusted kernel or deny execution.

Correct. Though to clarify, Chrome OS doesn't use UEFI SecureBoot: we
have a different solution that uses dm-verity to give us a trusted
read-only root filesystem. As long as things live on that filesystem,
we trust them. (This is why finit_module was added, and why I wanted
to make sure kexec used fd instead of just a memory blob.)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Greg KH]

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 most common kernel image format for x86, most of the 
   distros
   ship and use.
  
  ELF is interesting because it is the minimal file format that does
  everything you need.   So especially for a proof of concept ELF needs to
  come first.  There is an extra virtual address field in the ELF segment
  header but otherwise ELF does not have any unnecessary fields.
  
  ELF is interesting because it is the native kernel file format on all
  architectures linux supports including x86.
  
  ELF is interesting because producing an ELF image in practice requires
  a trivial amount of tooling so it is a good general purpose format to
  support.
 
 Ok. I will have a look at ELF loader too. I was hoping to keep only one
 loader in initial patch. But looks like that's not acceptable.

I totally disagree.  I think what you have done now is fine.  If it
works for bzImage, it's a good sense that this is usable as-is.

And, if someone else cares about signed elf images, hey, let them
implement the loader for it :)

Either way, the syscall interface wouldn't change, which is the
important thing to get right, so you should be fine for now.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

[Eric W. Biederman]

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 format for x86, most of the 
  distros
  ship and use.
 
 ELF is interesting because it is the minimal file format that does
 everything you need.   So especially for a proof of concept ELF needs to
 come first.  There is an extra virtual address field in the ELF segment
 header but otherwise ELF does not have any unnecessary fields.
 
 ELF is interesting because it is the native kernel file format on all
 architectures linux supports including x86.
 
 ELF is interesting because producing an ELF image in practice requires
 a trivial amount of tooling so it is a good general purpose format to
 support.

 Ok. I will have a look at ELF loader too. I was hoping to keep only one
 loader in initial patch. But looks like that's not acceptable.

Thank you.  We really need an ELF loader to see that we have handled the
general case and to see that we have a solution that is portable to
non-x86.

 [..]
  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
  absolutely need to check that the kernel sitting around in memory has
  not been corrupted before we let it run very far.
 
  Agreed. This should not be hard. It is just a matter of calcualting
  digest of segments. I will store it in kimge and verify digest again
  before passing control to control page. Will fix it in next version.
 
 Nak.  The verification needs to happen in purgatory. 
 
 The verification needs to happen in code whose runtime environment is
 does not depend on random parts of the kernel.  Anything else is a
 regression in maintainability and reliability.
 
 It is the wrong direction to add any code to what needs to run in the
 known broken environment of the kernel when a panic happens.
 
 Which means that you almost certainly need to go to the trouble of
 supporting the complexity needed to support purgatory code written in C.
 
 (For those just tuning in purgatory is our term for the code that runs
 between the kernels to do those things that can not happen a priori).

 In general, I agree with not using kernel parts after crash.

 But what protects against that purgatory itself has been scribbled over.
 IOW, how different purgatory memory is as compared to kernel memory where
 digest routines are stored. They have got equal probably of being scribbled
 over and if that's the case one is not better than other?

 And if they both got equal probability to getting corrupted, then there does
 not seem to be an advantage in moving digest verification inside
 purgatory.

The primary reason is that maintenance of code in the kernel that is
safe during a crash dump is hard.  That is why we boot a second kernel
after all.  If the code to do the signature verification resides in
machine_kexec on the kexec on panic code path in the kernel that has
called panic it is almost a given that at some point or other someone
will add an option that will add a weird dependency that makes the code
unsafe when the kernel is crashing.  I have seen it happen several times
on the existing kexec on panic code path.  I have seen it on other code
paths like netconsole.  Which can currently on some kernels I have
running cause the kernel go go into an endless printk loop if you call
printk from interrupt context.  So what we really gain by moving the
verification into purgatory is protection from inappropriate code reuse.

So having a completely separate piece of code may be a little harder to
write initially but the code is much simpler and more reliable to
maintain.  Essentially requiring no maintenance effort.  Further getting
to the point where purgatory is written in C makes small changes much
more approachable.

Eric

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/