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

Thiago Jung Bauermann writes: > Am Freitag, 15 Juli 2016, 18:03:35 schrieb Thiago Jung Bauermann: >> Am Freitag, 15 Juli 2016, 22:26:09 schrieb Arnd Bergmann: >> > However, the powerpc specific RTAS runtime services provide a similar >> > interface to the UEFI

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

Hi Thiago, > So even if not ideal, the solution above is desirable for powerpc. We would > like to preserve the ability of allowing userspace to pass parameters to the > OS via the DTB, even if secure boot is enabled. > > I would like to turn the above into a proposal: > > Extend the syscall

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

Am Freitag, 15 Juli 2016, 18:03:35 schrieb Thiago Jung Bauermann: > Am Freitag, 15 Juli 2016, 22:26:09 schrieb Arnd Bergmann: > > 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,

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

Am Mittwoch, 20 Juli 2016, 13:12:20 schrieb Arnd Bergmann: > On Wednesday, July 20, 2016 8:47:45 PM CEST Michael Ellerman wrote: > > At least for stdout-path, I can't really see how that would > > significantly help an attacker, but I'm all ears if anyone has ideas. > > That's actually an easy

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

On Wed, Jul 20, 2016 at 09:35:30AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > > > IOW, if your kernel forced signature verification, you should not be > > > able to do sig_enforce=0. If you kernel did not have > > >

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

On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > > > > Command line options are not signed. I thought idea behind secureboot > > was to execute only trusted code and command line options don't enforce > > you to execute unsigned code. > > > >> > >> You can

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

On Wednesday, July 20, 2016 8:47:45 PM CEST Michael Ellerman wrote: > At least for stdout-path, I can't really see how that would significantly help > an attacker, but I'm all ears if anyone has ideas. That's actually an easy one that came up before: If an attacker controls a tty device (e.g.

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

Russell King - ARM Linux writes: > On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: >> > IOW, if your kernel forced signature verification, you should not be >> > able to do sig_enforce=0. If you kernel did not have >> > CONFIG_MODULE_SIG_FORCE=y, then

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

On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > > IOW, if your kernel forced signature verification, you should not be > > able to do sig_enforce=0. If you kernel did not have > > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway > > and you are not making

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

> > Command line options are not signed. I thought idea behind secureboot > was to execute only trusted code and command line options don't enforce > you to execute unsigned code. > >> >> You can set module.sig_enforce=0 and open up the system a bit assuming >> that you can

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

On Mon, Jul 18, 2016 at 09:26:29AM -0400, Vivek Goyal wrote: > On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote: > > On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > > > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > > > >  > > > > On Wed, Jul 13,

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

On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote: > On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > > >  > > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > > >  > > > > On Wed, Jul

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

On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > >  > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > >  > > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > > >  >

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

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

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

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

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

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

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

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,

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

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 > > >

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

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.

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

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 >

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

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 > >

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

Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann: > On Wednesday, July 13, 2016 11:18:04 PM CEST Thiago Jung Bauermann wrote: > > Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann: > > > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > > > > Am

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

On Wed, Jul 13, 2016 at 09:57:28PM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 6:58:32 PM CEST Mark Rutland wrote: > > > > > we may want to remove unnecessary devices and even add a dedicated > > > storage device for storing a core dump image. > > > > I suspect that bringing up

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

On Wednesday, July 13, 2016 11:18:04 PM CEST Thiago Jung Bauermann wrote: > Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann: > > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > > > > > For

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

Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann: > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > > > > On Wed, Jul 13, 2016

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

On 07/14/16 at 02:38am, AKASHI Takahiro wrote: > Apologies for the slow response. I'm attending LinuxCon this week. > > On Wed, Jul 13, 2016 at 10:34:47AM +0100, Mark Rutland wrote: > > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > > > But consider we can kexec to a different

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

On 07/13/16 at 10:34am, Mark Rutland wrote: > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > > But consider we can kexec to a different kernel and a different initrd so > > there > > will be use cases to pass a total different dtb as well. > > It depends on what you mean by "a

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

On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > > > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > > > - kboot/petitboot

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

On Wednesday, July 13, 2016 6:58:32 PM CEST Mark Rutland wrote: > > > we may want to remove unnecessary devices and even add a dedicated > > storage device for storing a core dump image. > > I suspect that bringing up a minimal number of devices is better > controlled by a cmdline option. In

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

Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > > - kboot/petitboot with all of the user space being part of the trusted > > > boot> > > > >

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

On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > > Indeed - maybe Eric knows better, but I can't see any situation where > > >

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

On Thu, Jul 14, 2016 at 02:38:06AM +0900, AKASHI Takahiro wrote: > Apologies for the slow response. I'm attending LinuxCon this week. > > On Wed, Jul 13, 2016 at 10:34:47AM +0100, Mark Rutland wrote: > > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > > > But consider we can kexec

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

On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > Indeed - maybe Eric knows better, but I can't see any situation where > > the dtb we load via kexec should ever affect "the bootloader", unless > > the

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

Apologies for the slow response. I'm attending LinuxCon this week. On Wed, Jul 13, 2016 at 10:34:47AM +0100, Mark Rutland wrote: > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > > But consider we can kexec to a different kernel and a different initrd so > > there > > will be use

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

On Wed, Jul 13, 2016 at 09:45:22AM +1000, Stewart Smith wrote: > Vivek Goyal writes: > > On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: > >> Hello Eric, > >> > >> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > >> > AKASHI Takahiro

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

On Wed, Jul 13, 2016 at 09:41:39AM +1000, Stewart Smith wrote: > Petr Tesarik writes: > > On Tue, 12 Jul 2016 13:25:11 -0300 > > Thiago Jung Bauermann wrote: > > > >> Hi Eric, > >> > >> I'm trying to understand your concerns leading to your nack. I

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

On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > > > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > > > On Tue, Jul 12, 2016 at 04:24:10PM +0200,

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

On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote: > > Russell King - ARM Linux writes: > > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > > >> Russell King - ARM

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

On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > > On Tuesday, July 12, 2016 10:18:11 AM CEST

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

On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > But consider we can kexec to a different kernel and a different initrd so > there > will be use cases to pass a total different dtb as well. It depends on what you mean by "a different kernel", and what this implies for the DTB. I

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

On Wed, 13 Jul 2016 09:26:39 +0100 Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote: > > Russell King - ARM Linux writes: > > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > > >>

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

[snip] > Now, going back to the more fundamental issue raised in my first reply, > about the kernel command line. > > On x86, I can see that it _is_ possible for userspace to specify a > command line, and the kernel loading the image provides the command > line to the to-be-kexeced kernel with

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

On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote: > Russell King - ARM Linux writes: > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > >> Russell King - ARM Linux writes: > >> > On Tue, Jul 12, 2016 at 10:58:05PM

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

Arnd Bergmann writes: > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: >> On 07/12/16 at 03:50pm, Mark Rutland wrote: >> > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: >> > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: >> > >> >

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

Ard Biesheuvel writes: > On 13 July 2016 at 09:36, Russell King - ARM Linux > wrote: >> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >>> Russell King - ARM Linux writes: >>> > On Tue, Jul 12, 2016 at

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

On Wed, Jul 13, 2016 at 09:47:56AM +0200, Ard Biesheuvel wrote: > On 13 July 2016 at 09:36, Russell King - ARM Linux > wrote: > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > >> Russell King - ARM Linux writes: > >> > On Tue, Jul

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

On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > /proc/devicetree (aka

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

Russell King - ARM Linux writes: > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >> Russell King - ARM Linux writes: >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> >> I'm not an expert on DTB, so I can't

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

On 13 July 2016 at 09:36, Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >> Russell King - ARM Linux writes: >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> >> I'm not an expert

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

On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > Russell King - ARM Linux writes: > > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > >> I'm not an expert on DTB, so I can't provide an example of code > >> execution, but you have already

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

Russell King - ARM Linux writes: > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> I'm not an expert on DTB, so I can't provide an example of code >> execution, but you have already mentioned the /chosen/linux,stdout-path >> property. If an attacker

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

On 07/12/16 at 03:50pm, Mark Rutland wrote: > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > > into dynamically allocated

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

Vivek Goyal writes: > On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: >> Hello Eric, >> >> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: >> > AKASHI Takahiro writes: >> > > Device tree blob must be passed to

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

Petr Tesarik writes: > On Tue, 12 Jul 2016 13:25:11 -0300 > Thiago Jung Bauermann wrote: > >> Hi Eric, >> >> I'm trying to understand your concerns leading to your nack. I hope you >> don't mind expanding your thoughts on them a bit. >> >> Am

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

On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > I'm not an expert on DTB, so I can't provide an example of code > execution, but you have already mentioned the /chosen/linux,stdout-path > property. If an attacker redirects the bootloader to an insecure > console, they may get

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

On Tue, 12 Jul 2016 16:22:07 -0500 ebied...@xmission.com (Eric W. Biederman) wrote: > Petr Tesarik writes: > > > On Tue, 12 Jul 2016 13:25:11 -0300 > > Thiago Jung Bauermann wrote: >[...] > >> I also don't understand what you mean by code

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

ebied...@xmission.com (Eric W. Biederman) writes: > Petr Tesarik writes: > >> On Tue, 12 Jul 2016 13:25:11 -0300 >> Thiago Jung Bauermann wrote: >> >>> Hi Eric, >>> >>> I'm trying to understand your concerns leading to your nack. I hope you >>>

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

Petr Tesarik writes: > On Tue, 12 Jul 2016 13:25:11 -0300 > Thiago Jung Bauermann wrote: > >> Hi Eric, >> >> I'm trying to understand your concerns leading to your nack. I hope you >> don't mind expanding your thoughts on them a bit. >> >> Am

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

On Tue, 12 Jul 2016 13:25:11 -0300 Thiago Jung Bauermann wrote: > Hi Eric, > > I'm trying to understand your concerns leading to your nack. I hope you > don't mind expanding your thoughts on them a bit. > > Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W.

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

Hi Eric, I'm trying to understand your concerns leading to your nack. I hope you don't mind expanding your thoughts on them a bit. Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro writes: > > Device tree blob must be passed to a

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

On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > into dynamically allocated data structures. After a kexec, the runtime > > >

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

On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > On Open Firmware, the DT is extracted from running firmware and copied > > into dynamically allocated data structures. After a kexec, the runtime > > interface to the firmware is not available, so the flattened DT format > >

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

On Tue, Jul 12, 2016 at 04:02:46PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 8:25:48 AM CEST Eric W. Biederman wrote: > > AKASHI Takahiro writes: > > > > > Device tree blob must be passed to a second kernel on DTB-capable > > > archs, like powerpc and

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

On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: > Hello Eric, > > Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > > AKASHI Takahiro writes: > > > Device tree blob must be passed to a second kernel on DTB-capable > > > archs,

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

On Tuesday, July 12, 2016 8:25:48 AM CEST Eric W. Biederman wrote: > AKASHI Takahiro writes: > > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > > > >

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

Hello Eric, Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro writes: > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > >

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

AKASHI Takahiro writes: > Device tree blob must be passed to a second kernel on DTB-capable > archs, like powerpc and arm64, but the current kernel interface > lacks this support. > > This patch extends kexec_file_load system call by adding an extra > argument to

[RFC 0/3] extend kexec_file_load system call

Device tree blob must be passed to a second kernel on DTB-capable archs, like powerpc and arm64, but the current kernel interface lacks this support. This patch extends kexec_file_load system call by adding an extra argument to this syscall so that an arbitrary number of file descriptors can be