Re: [V2][PATCH 1/2] PKCS#7: Fix kernel panic when referring to the empty AuthorityKeyIdentifier

[Lans Zhang]

On 07/15/2016 10:48 PM, David Howells wrote:

Lans Zhang  wrote:


This fix resolves the following kernel panic if the empty
AuthorityKeyIdentifier employed.


It should be noted that this is only an issue if DEBUG is #defined at the top
of pkcs7_verify.c as the crash happens in a pr_debug() statement.



Yep and your previous analysis is correct.

Let me know if I need to add this comment to commit header.

Cheers,
Jia


David




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

Re: [RFC 0/3] extend kexec_file_load system call

[Arnd Bergmann]

On Friday, July 15, 2016 2:42:10 PM CEST Russell King - ARM Linux wrote:
> 
> On other architectures, DT can also contain open-firmware "functions"
> but I don't think there's much support in the kernel for that - maybe
> the PPC folk can reply on that point.

The open firmware runtime interface are shut down by the time we have
a flattened device tree, so those are not accessible any more. IIRC
SPARC leaves the open firmware interface live, but it doesn't use
fdt, so that's not relevant here.

However, the powerpc specific RTAS runtime services provide a similar
interface to the UEFI runtime support and allow to call into
binary code from the kernel, which gets mapped from a physical
address in the "linux,rtas-base" property in the rtas device node.

Modifying the /rtas node will definitely give you a backdoor into
priviledged code, but modifying only /chosen should not let you get
in through that specific method.

Arnd

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

Re: [RFC 0/3] extend kexec_file_load system call

[Thiago Jung Bauermann]

Am Freitag, 15 Juli 2016, 14:33:47 schrieb Mark Rutland:
> On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote:
> > On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote:
> > > On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann 
wrote:
> > > > Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann:
> > > > > Right, but the question remains whether this helps while you allow
> > > > > the
> > > > > boot loader to modify the dtb. If an attacker gets in and cannot
> > > > > modify
> > > > > the kernel or initid but can modify the DT, a successful attack
> > > > > would
> > > > > be a bit harder than having a modified kernel, but you may still
> > > > > need
> > > > > to treat the system as compromised.
> > > > 
> > > > Yes, and the same question also remains regarding the kernel command
> > > > line.
> > > > 
> > > > We can have the kernel perform sanity checks on the device tree,
> > > > just as the kernel needs to sanity check the command line.
> > > > 
> > > > There's the point that was raised about not wanting to increase the
> > > > attack surface, and that's a valid point. But at least in the way
> > > > Petitboot works today, it needs to modify the device tree and pass
> > > > it to the kernel.
> > > > 
> > > > One thing that is unavoidable to come from userspace is
> > > > /chosen/linux,stdout-path, because it's Petitboot that knows from
> > > > which
> > > > console the user is interacting with. The other modification to set
> > > > properties in vga@0 can be done in the kernel.
> > > > 
> > > > Given that on DTB-based systems /chosen is an important and
> > > > established way to pass information to the operating system being
> > > > booted, I'd like to suggest the following, then:
> > > > 
> > > > Extend the syscall as shown in this RFC from Takahiro AKASHI, but
> > > > instead of accepting a complete DTB from userspace, the syscall
> > > > would accept a DTB containing only a /chosen node. If the DTB
> > > > contains any other node, the syscall fails with EINVAL. The kernel
> > > > can then add the properties in /chosen to the device tree that it
> > > > will pass to the next kernel.
> > > > 
> > > > What do you think?
> > > 
> > > I think that helps, as it makes the problem space correspond to that
> > > of modifying the command line, but I can still come up with countless
> > > attacks based on modifications of the /chosen node and/or the command
> > > line, in fact it's probably easier than any other node.
> > 
> > I don't know anything about DTB. So here comes a very basic question.
> > Does DTB allow passing an executable blob to kernel or pass the
> > location of some unsigned executable code at kernel level. I think from
> > secureboot point of view that would be a concern. Being able to trick
> > kernel to execute an unsigned code at privileged level.
> 
> The DTB itself won't contain executable code.
> 
> However, arbitrary bindings could point kernel at such code. For
> instance, /chosen/linux,uefi-system-table could point the kernel at a
> faked EFI system table, with pointers to malicious code. So
> arbitrary modification of /chosen is not safe.

PowerPC doesn't have UEFI so this option is not a concern in that 
architecture. I'm having a look at what a PowerPC kernel gets from /chosen 
and haven't found anything of concern so far, but I'm still looking.

On the other hand, the kernel command line has the option acpi_rsdp, which 
is used to pass the address of the RSDP. I don't really know much about EFI 
so I'm not sure if it can be used to point to code that the kernel can 
execute, but it does point to tables that contain AML code.

> Bindings describe arbitrary system features (devices, firmware
> interfaces, etc), so in general they might provide mechanisms to execute
> code.

Even bindings in /chosen?

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


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

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

[Petr Tesarik]

On Fri, 15 Jul 2016 11:13:46 -0400
Vivek Goyal  wrote:

> On Fri, Jul 15, 2016 at 04:42:40PM +0200, Petr Tesarik wrote:
> > On Fri, 15 Jul 2016 08:51:14 -0400
> > Vivek Goyal  wrote:
> > 
> > > On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> > > > On Fri, 15 Jul 2016 07:57:22 +0800
> > > > joeyli  wrote:
> > > > 
> > > > > Hi Vivek
> > > > > 
> > > > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> > > > > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > > > > > > This patch adds a new "--fallback-kexec" option to give a chance 
> > > > > > > to
> > > > > > > fallback to old kexec syscall when file based kexec syscall 
> > > > > > > operation
> > > > > > > failed.
> > > > > > 
> > > > > > I think caller should switch to using different interface if need 
> > > > > > be. But
> > > > > > I don't see much point in providing an option for this in 
> > > > > > kexec-tools.
> > > > > > 
> > > > > > Vivek
> > > > > >
> > > > > 
> > > > > OK~ Understood!
> > > > > 
> > > > > Thanks for Baoquan's and your opinion for this patch.
> > > > 
> > > > Is there some sort of diagnostics, so a calling script can determine
> > > > whether kexec failed, because there's no suppor for kexec_file_load(2)
> > > > or for a different reason? 
> > > 
> > > Will we not get -ENOSYS if kexec_file_load() is not implemented?
> > 
> > Sure, the kexec code will see a beautiful ENOSYS in errno, but it
> > merely prints this message on stderr (possibly with a different error
> > string if not linked against glibc):
> > 
> > kexec_file_load failed: Function not implemented
> > 
> > ...and exits with status 255 (same for any other error). Which is, um,
> > not very friendly to automated error handling...
> 
> So what are the options? One should return different error codes as
> returned by glibc? But bash or other script will not have a library
> to translate it. I guess scripts will have to hard code the meaning
> of a particular return code.
> 
> BTW, user can always try kexec_file_load() and if it fails, try older
> version of syscall and that should work for lot of use cases?

Yes, I can blindly retry. Thanks for considering other options.

Petr T

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

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

[Vivek Goyal]

On Fri, Jul 15, 2016 at 04:42:40PM +0200, Petr Tesarik wrote:
> On Fri, 15 Jul 2016 08:51:14 -0400
> Vivek Goyal  wrote:
> 
> > On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> > > On Fri, 15 Jul 2016 07:57:22 +0800
> > > joeyli  wrote:
> > > 
> > > > Hi Vivek
> > > > 
> > > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> > > > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > > > > > This patch adds a new "--fallback-kexec" option to give a chance to
> > > > > > fallback to old kexec syscall when file based kexec syscall 
> > > > > > operation
> > > > > > failed.
> > > > > 
> > > > > I think caller should switch to using different interface if need be. 
> > > > > But
> > > > > I don't see much point in providing an option for this in kexec-tools.
> > > > > 
> > > > > Vivek
> > > > >
> > > > 
> > > > OK~ Understood!
> > > > 
> > > > Thanks for Baoquan's and your opinion for this patch.
> > > 
> > > Is there some sort of diagnostics, so a calling script can determine
> > > whether kexec failed, because there's no suppor for kexec_file_load(2)
> > > or for a different reason? 
> > 
> > Will we not get -ENOSYS if kexec_file_load() is not implemented?
> 
> Sure, the kexec code will see a beautiful ENOSYS in errno, but it
> merely prints this message on stderr (possibly with a different error
> string if not linked against glibc):
> 
> kexec_file_load failed: Function not implemented
> 
> ...and exits with status 255 (same for any other error). Which is, um,
> not very friendly to automated error handling...

So what are the options? One should return different error codes as
returned by glibc? But bash or other script will not have a library
to translate it. I guess scripts will have to hard code the meaning
of a particular return code.

BTW, user can always try kexec_file_load() and if it fails, try older
version of syscall and that should work for lot of use cases?

Vivek

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

Re: [V2][PATCH 1/2] PKCS#7: Fix kernel panic when referring to the empty AuthorityKeyIdentifier

[David Howells]

Lans Zhang  wrote:

> This fix resolves the following kernel panic if the empty
> AuthorityKeyIdentifier employed.

It should be noted that this is only an issue if DEBUG is #defined at the top
of pkcs7_verify.c as the crash happens in a pr_debug() statement.

David

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

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

[Petr Tesarik]

On Fri, 15 Jul 2016 08:51:14 -0400
Vivek Goyal  wrote:

> On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> > On Fri, 15 Jul 2016 07:57:22 +0800
> > joeyli  wrote:
> > 
> > > Hi Vivek
> > > 
> > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> > > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > > > > This patch adds a new "--fallback-kexec" option to give a chance to
> > > > > fallback to old kexec syscall when file based kexec syscall operation
> > > > > failed.
> > > > 
> > > > I think caller should switch to using different interface if need be. 
> > > > But
> > > > I don't see much point in providing an option for this in kexec-tools.
> > > > 
> > > > Vivek
> > > >
> > > 
> > > OK~ Understood!
> > > 
> > > Thanks for Baoquan's and your opinion for this patch.
> > 
> > Is there some sort of diagnostics, so a calling script can determine
> > whether kexec failed, because there's no suppor for kexec_file_load(2)
> > or for a different reason? 
> 
> Will we not get -ENOSYS if kexec_file_load() is not implemented?

Sure, the kexec code will see a beautiful ENOSYS in errno, but it
merely prints this message on stderr (possibly with a different error
string if not linked against glibc):

kexec_file_load failed: Function not implemented

...and exits with status 255 (same for any other error). Which is, um,
not very friendly to automated error handling...

Petr T

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

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote:
> On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote:
> > I think that helps, as it makes the problem space correspond to that
> > of modifying the command line, but I can still come up with countless
> > attacks based on modifications of the /chosen node and/or the command
> > line, in fact it's probably easier than any other node.
> 
> I don't know anything about DTB. So here comes a very basic question. Does
> DTB allow passing an executable blob to kernel or pass the location of
> some unsigned executable code at kernel level.

DT on ARM is a description of the hardware - it can be thought of as a
set of nodes with properties attached.  The properties can describe
anything (we have documentation in Documentation/devicetree/bindings
which describes what we expect the properties to contain.)

On other architectures, DT can also contain open-firmware "functions"
but I don't think there's much support in the kernel for that - maybe
the PPC folk can reply on that point.

It is possible that someone may, at some point, decide to create a
property that points to some executable blob, but I can't think of a
reason why we should ever allow such a monstrosity in mainline kernels.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

Re: [RFC 0/3] extend kexec_file_load system call

[Mark Rutland]

On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote:
> On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote:
> > On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann wrote:
> > > Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann:
> > 
> > > > 
> > > > Right, but the question remains whether this helps while you allow the
> > > > boot loader to modify the dtb. If an attacker gets in and cannot modify
> > > > the kernel or initid but can modify the DT, a successful attack would
> > > > be a bit harder than having a modified kernel, but you may still need
> > > > to treat the system as compromised.
> > > 
> > > Yes, and the same question also remains regarding the kernel command line.
> > > 
> > > We can have the kernel perform sanity checks on the device tree, just as 
> > > the 
> > > kernel needs to sanity check the command line.
> > > 
> > > There's the point that was raised about not wanting to increase the 
> > > attack 
> > > surface, and that's a valid point. But at least in the way Petitboot 
> > > works 
> > > today, it needs to modify the device tree and pass it to the kernel.
> > > 
> > > One thing that is unavoidable to come from userspace is 
> > > /chosen/linux,stdout-path, because it's Petitboot that knows from which 
> > > console the user is interacting with. The other modification to set 
> > > properties in vga@0 can be done in the kernel.
> > > 
> > > Given that on DTB-based systems /chosen is an important and established 
> > > way 
> > > to pass information to the operating system being booted, I'd like to 
> > > suggest the following, then:
> > > 
> > > Extend the syscall as shown in this RFC from Takahiro AKASHI, but instead 
> > > of 
> > > accepting a complete DTB from userspace, the syscall would accept a DTB 
> > > containing only a /chosen node. If the DTB contains any other node, the 
> > > syscall fails with EINVAL. The kernel can then add the properties in 
> > > /chosen 
> > > to the device tree that it will pass to the next kernel.
> > > 
> > > What do you think?
> > 
> > I think that helps, as it makes the problem space correspond to that
> > of modifying the command line, but I can still come up with countless
> > attacks based on modifications of the /chosen node and/or the command
> > line, in fact it's probably easier than any other node.
> 
> I don't know anything about DTB. So here comes a very basic question. Does
> DTB allow passing an executable blob to kernel or pass the location of
> some unsigned executable code at kernel level. I think from secureboot point 
> of
> view that would be a concern. Being able to trick kernel to execute an
> unsigned code at privileged level.

The DTB itself won't contain executable code.

However, arbitrary bindings could point kernel at such code. For
instance, /chosen/linux,uefi-system-table could point the kernel at a
faked EFI system table, with pointers to malicious code. So
arbitrary modification of /chosen is not safe.

Bindings describe arbitrary system features (devices, firmware
interfaces, etc), so in general they might provide mechanisms to execute
code.

Thanks,
Mark.

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

Re: [RFC 0/3] extend kexec_file_load system call

[Vivek Goyal]

On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote:
> On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann wrote:
> > Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann:
> 
> > > 
> > > Right, but the question remains whether this helps while you allow the
> > > boot loader to modify the dtb. If an attacker gets in and cannot modify
> > > the kernel or initid but can modify the DT, a successful attack would
> > > be a bit harder than having a modified kernel, but you may still need
> > > to treat the system as compromised.
> > 
> > Yes, and the same question also remains regarding the kernel command line.
> > 
> > We can have the kernel perform sanity checks on the device tree, just as 
> > the 
> > kernel needs to sanity check the command line.
> > 
> > There's the point that was raised about not wanting to increase the attack 
> > surface, and that's a valid point. But at least in the way Petitboot works 
> > today, it needs to modify the device tree and pass it to the kernel.
> > 
> > One thing that is unavoidable to come from userspace is 
> > /chosen/linux,stdout-path, because it's Petitboot that knows from which 
> > console the user is interacting with. The other modification to set 
> > properties in vga@0 can be done in the kernel.
> > 
> > Given that on DTB-based systems /chosen is an important and established way 
> > to pass information to the operating system being booted, I'd like to 
> > suggest the following, then:
> > 
> > Extend the syscall as shown in this RFC from Takahiro AKASHI, but instead 
> > of 
> > accepting a complete DTB from userspace, the syscall would accept a DTB 
> > containing only a /chosen node. If the DTB contains any other node, the 
> > syscall fails with EINVAL. The kernel can then add the properties in 
> > /chosen 
> > to the device tree that it will pass to the next kernel.
> > 
> > What do you think?
> 
> I think that helps, as it makes the problem space correspond to that
> of modifying the command line, but I can still come up with countless
> attacks based on modifications of the /chosen node and/or the command
> line, in fact it's probably easier than any other node.

I don't know anything about DTB. So here comes a very basic question. Does
DTB allow passing an executable blob to kernel or pass the location of
some unsigned executable code at kernel level. I think from secureboot point of
view that would be a concern. Being able to trick kernel to execute an
unsigned code at privileged level.

Vivek

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

Re: [RFC 3/3] kexec: extend kexec_file_load system call

[Mark Rutland]

On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote:
> On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote:
> 
> [..]
> > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > +SYSCALL_DEFINE6(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > unsigned long, cmdline_len, const char __user *, cmdline_ptr,
> > -   unsigned long, flags)
> > +   unsigned long, flags, const struct kexec_fdset __user *, ufdset)
> 
> Can one add more parameters to existing syscall. Can it break existing
> programs with new kernel? I was of the impression that one can't do that.
> But may be I am missing something.

I think the idea was that we would only look at the new params if a new
flags was set, and otherwise it would behave as the old syscall.

Regardless, I think it makes far more sense to add a kexec_file_load2
syscall if we're going to modify the prototype at all. It's a rather
different proposition to the existing syscall, and needs to be treated
as such.

Thanks,
Mark.

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

Re: [RFC 3/3] kexec: extend kexec_file_load system call

[Vivek Goyal]

On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote:

[..]
> -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> +SYSCALL_DEFINE6(kexec_file_load, int, kernel_fd, int, initrd_fd,
>   unsigned long, cmdline_len, const char __user *, cmdline_ptr,
> - unsigned long, flags)
> + unsigned long, flags, const struct kexec_fdset __user *, ufdset)

Can one add more parameters to existing syscall. Can it break existing
programs with new kernel? I was of the impression that one can't do that.
But may be I am missing something.

Vivek

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

Re: [RFC 0/3] extend kexec_file_load system call

[Vivek Goyal]

On Fri, Jul 15, 2016 at 09:49:25AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 13, 2016 at 03:13:42PM +0200, Arnd Bergmann wrote:
> > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote:
> > > The big question is whether this is a realistic case on a secure boot
> > > system.
> > 
> > What does x86 do here? I assume changes to the command line are also
> > limited.
> 
> They aren't.  You can specify /anything/ even with a fully-signed kernel
> and initrd, which was one of the things I pointed out in my previous
> set of responses.

Yes, kernel command line is not signed. For that matter even initird is
not signed. Just kernel is signed and its signatures are verified. Idea
is an unsigned code should not be able to execute in kernel space.

Vivek

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

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

[Vivek Goyal]

On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> On Fri, 15 Jul 2016 07:57:22 +0800
> joeyli  wrote:
> 
> > Hi Vivek
> > 
> > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > > > This patch adds a new "--fallback-kexec" option to give a chance to
> > > > fallback to old kexec syscall when file based kexec syscall operation
> > > > failed.
> > > 
> > > I think caller should switch to using different interface if need be. But
> > > I don't see much point in providing an option for this in kexec-tools.
> > > 
> > > Vivek
> > >
> > 
> > OK~ Understood!
> > 
> > Thanks for Baoquan's and your opinion for this patch.
> 
> Is there some sort of diagnostics, so a calling script can determine
> whether kexec failed, because there's no suppor for kexec_file_load(2)
> or for a different reason? 

Will we not get -ENOSYS if kexec_file_load() is not implemented?

Vivek

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

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[河合英宏 / KAWAI，HIDEHIRO]

Hi Dave,

Thanks for your reply.

> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Wednesday, July 13, 2016 11:04 AM
> 
> On 07/12/16 at 02:49am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for the comments.
> >
> > > From: Dave Young [mailto:dyo...@redhat.com]
> > > Sent: Monday, July 11, 2016 5:35 PM
> > >
> > > On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
> > > > This patch fixes one of the problems reported by Daniel Walker
> > > > (https://lkml.org/lkml/2015/6/24/44).
> > > >
> > > > If crash_kexec_post_notifiers boot option is specified, other CPUs
> > > > are stopped by smp_send_stop() instead of machine_crash_shutdown()
> > > > in crash_kexec() path.  This behavior change leads two problems.
> > > >
> > > >  Problem 1:
> > > >  octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs
> > > > are  still online and try to stop their watchdog timer.  If
> > > >  smp_send_stop() is called before octeon_generic_shutdown(),
> > > > stopping  watchdog timer will fail because other CPUs have been
> > > > offlined by  smp_send_stop().
> > > >
> > > >panic()
> > > >  if crash_kexec_post_notifiers == 1
> > > >smp_send_stop()
> > > >atomic_notifier_call_chain()
> > > >kmsg_dump()
> > > >  crash_kexec()
> > > >machine_crash_shutdown()
> > > >  octeon_generic_shutdown() // shutdown watchdog for ONLINE
> > > > CPUs
> > > >
> > > >  Problem 2:
> > > >  Most of architectures stop other CPUs in machine_crash_shutdown()
> > > > path, and they also do something needed for kdump.  For example,
> > > > they save registers, disable virtualization extensions, and so on.
> > > >  However, if smp_send_stop() stops other CPUs before
> > > > machine_crash_shutdown(), we miss those operations.
> > > >
> > > > How do we fix these problems?  In the first place, we should stop
> > > > other CPUs as soon as possible when panic() was called, otherwise
> > > > other CPUs may wipe out a clue to the cause of the failure.  So,
> > > > we replace smp_send_stop() with more suitable one for kdump.
> > >
> > > We have been avoiding extra things in panic path, but unfortunately
> > > crash_kexec_post_notifiers were added. I tend to agree the best
> > > place for this stuff is in 2nd kernel or purgatory instead of in 1st 
> > > kernel.
> >
> > Several months ago, I posted a patch set which writes regs to SEL,
> > generate an event to send SNMP message, and start/stop BMC's watchdog
> > timer in purgatory.  This feature requires BMC with KCS (Keyboard
> > Controller Style) I/F, but the most of enterprise grade server would have 
> > it.
> > (http://thread.gmane.org/gmane.linux.kernel.kexec/15382)
> >
> > Doing kmsg_dump things in purgatory wouldn't be suitable (should be
> > done in the 2nd kernel before enabling devices and IRQs?)
> 
> In theory it is doable maybe do something like oldmem_kmsg_dump while 
> /proc/vmcore initializing?

Hmm, I checked the case of using ACPI ERST as a persistent
storage. The feature is initialized by device_initcall():

device_initcall
  erst_init
pstore_register

And vmcore is initialized by fs_initcall() which is called
before device_initcall().  We may be able to change the sequence,
but anyway, these are done in later phase of the kernel initialization.
So, it may get less reliable although it would be doable.

> > > As for this patch I'm not sure it is safe to replace the
> > > smp_send_stop with the kdump friendly function. I'm also not sure if
> > > the kdump friendly function is safe for kdump. Will glad to hear
> > > opinions from other arch experts.
> >
> > This stuff depends on architectures, so I speak only about
> > x86 (the logic doesn't change on other architectures at this time).
> >
> > kdump path with crash_kexec_post_notifiers disabled:
> >  panic()
> >__crash_kexec()
> >  crash_setup_regs()
> >  crash_save_vmcoreinfo()
> >  machine_crash_shutdown()
> >native_machine_crash_shutdown()
> >  panic_smp_send_stop() /* mostly same as original
> > * kdump_nmi_shootdown_cpus()
> > */
> >
> > kdump path with crash_kexec_post_notifiers enabled:
> >  panic()
> >panic_smp_send_stop()
> >__crash_kexec()
> >  crash_setup_regs()
> >  crash_save_vmcoreinfo()
> >  machine_crash_shutdown()
> >native_machine_crash_shutdown()
> >  panic_smp_send_stop() // do nothing
> >
> > The difference is that stopping other CPUs before crash_setup_regs()
> > and crash_save_vmcoreinfo() or not.  Since crash_setup_regs() and
> > crash_save_vmcoreinfo() just save information to some memory area,
> > they wouldn't be affected by panic_smp_send_stop().  This means
> > placing panic_smp_send_stop before __crash_kexec is safe.
> >
> > BTW, I noticed my patch breaks Xen kernel.  I'll fix it in the next
> > version.
> 
> But it does breaks stuff which depends on cpu not being disabled like problem 
> 1 you mentioned in 

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

[Petr Tesarik]

On Fri, 15 Jul 2016 18:28:05 +0800
joeyli  wrote:

> On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> > On Fri, 15 Jul 2016 07:57:22 +0800
> > joeyli  wrote:
> > 
> > > Hi Vivek
> > > 
> > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> > > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > > > > This patch adds a new "--fallback-kexec" option to give a chance to
> > > > > fallback to old kexec syscall when file based kexec syscall operation
> > > > > failed.
> > > > 
> > > > I think caller should switch to using different interface if need be. 
> > > > But
> > > > I don't see much point in providing an option for this in kexec-tools.
> > > > 
> > > > Vivek
> > > >
> > > 
> > > OK~ Understood!
> > > 
> > > Thanks for Baoquan's and your opinion for this patch.
> > 
> > Is there some sort of diagnostics, so a calling script can determine
> > whether kexec failed, because there's no suppor for kexec_file_load(2)
> > or for a different reason? 
> > 
> > Thanks,
> > Petr T
> 
> The calling script needs to use "-s" option to access file based kexec, then
> check the result

This is the part I was asking about. How do I "check the result"? In
other words, what is "the result" if kexec fails because of missing
kernel syscall, and what is "the result" if it fails for any other
reason (e.g. insufficient privileges)?

Or do you suggest that the script always retrius without "-s" after
"kexec -s" fails, just in case loading might work the old way?

Petr T

> and call kexec without -s to access old kexec syscall.
> 
> With this patch is just more convenience.
> 
> 
> Thanks a lot!
> Joey Lee


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

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

[joeyli]

On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> On Fri, 15 Jul 2016 07:57:22 +0800
> joeyli  wrote:
> 
> > Hi Vivek
> > 
> > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > > > This patch adds a new "--fallback-kexec" option to give a chance to
> > > > fallback to old kexec syscall when file based kexec syscall operation
> > > > failed.
> > > 
> > > I think caller should switch to using different interface if need be. But
> > > I don't see much point in providing an option for this in kexec-tools.
> > > 
> > > Vivek
> > >
> > 
> > OK~ Understood!
> > 
> > Thanks for Baoquan's and your opinion for this patch.
> 
> Is there some sort of diagnostics, so a calling script can determine
> whether kexec failed, because there's no suppor for kexec_file_load(2)
> or for a different reason? 
> 
> Thanks,
> Petr T

The calling script needs to use "-s" option to access file based kexec, then
check the result and call kexec without -s to access old kexec syscall.

With this patch is just more convenience.


Thanks a lot!
Joey Lee

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

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 13, 2016 at 03:13:42PM +0200, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote:
> > The big question is whether this is a realistic case on a secure boot
> > system.
> 
> What does x86 do here? I assume changes to the command line are also
> limited.

They aren't.  You can specify /anything/ even with a fully-signed kernel
and initrd, which was one of the things I pointed out in my previous
set of responses.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

[Petr Tesarik]

On Fri, 15 Jul 2016 07:57:22 +0800
joeyli  wrote:

> Hi Vivek
> 
> On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > > This patch adds a new "--fallback-kexec" option to give a chance to
> > > fallback to old kexec syscall when file based kexec syscall operation
> > > failed.
> > 
> > I think caller should switch to using different interface if need be. But
> > I don't see much point in providing an option for this in kexec-tools.
> > 
> > Vivek
> >
> 
> OK~ Understood!
> 
> Thanks for Baoquan's and your opinion for this patch.

Is there some sort of diagnostics, so a calling script can determine
whether kexec failed, because there's no suppor for kexec_file_load(2)
or for a different reason? 

Thanks,
Petr T

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

Re: [RFC 0/3] extend kexec_file_load system call

[Arnd Bergmann]

On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann wrote:
> Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann:

> > 
> > Right, but the question remains whether this helps while you allow the
> > boot loader to modify the dtb. If an attacker gets in and cannot modify
> > the kernel or initid but can modify the DT, a successful attack would
> > be a bit harder than having a modified kernel, but you may still need
> > to treat the system as compromised.
> 
> Yes, and the same question also remains regarding the kernel command line.
> 
> We can have the kernel perform sanity checks on the device tree, just as the 
> kernel needs to sanity check the command line.
> 
> There's the point that was raised about not wanting to increase the attack 
> surface, and that's a valid point. But at least in the way Petitboot works 
> today, it needs to modify the device tree and pass it to the kernel.
> 
> One thing that is unavoidable to come from userspace is 
> /chosen/linux,stdout-path, because it's Petitboot that knows from which 
> console the user is interacting with. The other modification to set 
> properties in vga@0 can be done in the kernel.
> 
> Given that on DTB-based systems /chosen is an important and established way 
> to pass information to the operating system being booted, I'd like to 
> suggest the following, then:
> 
> Extend the syscall as shown in this RFC from Takahiro AKASHI, but instead of 
> accepting a complete DTB from userspace, the syscall would accept a DTB 
> containing only a /chosen node. If the DTB contains any other node, the 
> syscall fails with EINVAL. The kernel can then add the properties in /chosen 
> to the device tree that it will pass to the next kernel.
> 
> What do you think?

I think that helps, as it makes the problem space correspond to that
of modifying the command line, but I can still come up with countless
attacks based on modifications of the /chosen node and/or the command
line, in fact it's probably easier than any other node.

What methods to we have in place for command line changes today on
other architectures?

Arnd

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

Re: IO memory read from /proc/vmcore leads to hang.

[Mahesh Jagannath Salgaonkar]

On 07/12/2016 03:16 AM, Daniel Walker wrote:
> 
> Hi,
> 
> I found found that on my Powerpc machine there is some IO memory which
> will cause the box to hang if I read it. It's a custom device that was
> added to the board for a special purpose.
> 
> I was looking for a way to exclude this memory from the dump, and while
> doing that I found that kexec makes a list of memory segments that go
> into the core file. I was wondering why most of the kexec architecture
> don't appear to exclude device memory like what's listed in /proc/iomem.
> 
> Is there a good reason why that's not the case?

Kexec/Kdump is designed to capture entire old kernel's memory that will
be available in /proc/vmcore. There is a different userspace tool called
'makedumpfile' (https://sourceforge.net/projects/makedumpfile/), which
can be used to exclude certain memory pages from the dump while reading
from /proc/vmcore. See if that helps you.

Thanks,
-Mahesh.

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


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