From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
bhe@redhat.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, Vivek Goyal <vgoyal@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
bauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 0/3] extend kexec_file_load system call
Date: Thu, 14 Jul 2016 09:54:47 +0800 [thread overview]
Message-ID: <20160714015447.GB3121@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20160713173804.GA25723@porco>
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 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 expect future arm64 Linux kernels to function with today's DTBs, and
> > the existing boot protocol. The kexec_file_load syscall already has
> > enough information for the kernel to inject the initrd and bootargs
> > properties into a DTB.
> >
> > In practice on x86 today, kexec_file_load only supports booting to a
> > Linux kernel, because the in-kernel purgatory only implements the x86
> > Linux boot protocol. Analagously, for arm64 I think that the first
> > kernel should use its internal copy of the boot DTB, with /chosen fixed
> > up appropriately, assuming the next kernel is an arm64 Linux image.
> >
> > If booting another OS, the only parts of the DTB I would expect to
> > change are the properties under chosen, as everything else *should* be
> > OS-independent. However the other OS may have a completely different
> > boot protocol, might not even take a DTB, and will likely need a
> > compeltely different purgatory implementation. So just allowing the DTB
> > to be altered isn't sufficient for that case.
> >
> > There might be cases where we want a different DTB, but as far as I can
> > tell we have nothing analagous on x86 today. If we do need this, we
> > should have an idea of what real case(s) were trying to solve.
>
> What I had in my mind was:
>
> - Kdump
> As Russel said, we definitely need to modify dtb.
> In addition to bootargs and initrd proerties (FYI, in my arm64
> implementation for arm64, eflcorehdr info is also passed as DT
> property), we may want to remove unnecessary devices and
> even add a dedicated storage device for storing a core dump image.
> - Say, booting BE kernel on ACPI LE kernel
> In this case, there is no useful dtb in the kernel.
>
> Have said that, as Mark said, we may be able to use normal kexec_load
> system call if we don't need a "secure" kexec.
>
> BTW, why doesn't the current kexec_load have ability of verifying
> a signature of initramfs image? Is IMA/EVM expected to be used
> at runtime?
I believe there are some limitations for verify signatures in kexec_load.
First kexec-tools need to be trusted, but there's no way to sign and
verify signature of shared libraries. There maybe other limitations I
can not remember which are also reasons why Vivek moved to current
file based syscall.
Thanks
Dave
next prev parent reply other threads:[~2016-07-14 1:55 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 1:41 [RFC 0/3] extend kexec_file_load system call AKASHI Takahiro
2016-07-12 1:41 ` [RFC 1/3] syscall: add kexec_file_load to generic unistd.h AKASHI Takahiro
2016-07-12 1:42 ` [RFC 2/3] kexec: add dtb info to struct kimage AKASHI Takahiro
2016-07-12 1:42 ` [RFC 3/3] kexec: extend kexec_file_load system call AKASHI Takahiro
2016-07-15 13:09 ` Vivek Goyal
2016-07-15 13:19 ` Mark Rutland
2016-07-18 2:30 ` Dave Young
2016-07-18 10:07 ` Mark Rutland
2016-07-19 0:55 ` Dave Young
2016-07-19 10:52 ` Mark Rutland
2016-07-19 12:24 ` Vivek Goyal
2016-07-19 12:47 ` Mark Rutland
2016-07-19 13:26 ` Vivek Goyal
2016-07-20 11:41 ` David Laight
2016-07-21 9:21 ` Russell King - ARM Linux
2016-07-18 2:33 ` Dave Young
2016-07-27 0:24 ` [PATCH v2 " Thiago Jung Bauermann
2016-08-05 20:46 ` Thiago Jung Bauermann
2016-07-12 13:25 ` [RFC 0/3] " Eric W. Biederman
2016-07-12 13:58 ` Thiago Jung Bauermann
2016-07-12 14:02 ` Vivek Goyal
2016-07-12 23:45 ` Stewart Smith
2016-07-13 13:27 ` Vivek Goyal
2016-07-12 14:02 ` Arnd Bergmann
2016-07-12 14:18 ` Vivek Goyal
2016-07-12 14:24 ` Arnd Bergmann
2016-07-12 14:50 ` Mark Rutland
2016-07-13 2:36 ` Dave Young
2016-07-13 8:01 ` Arnd Bergmann
2016-07-13 8:23 ` Stewart Smith
2016-07-13 9:41 ` Mark Rutland
2016-07-13 13:13 ` Arnd Bergmann
2016-07-13 18:45 ` Thiago Jung Bauermann
2016-07-13 19:59 ` Arnd Bergmann
2016-07-14 2:18 ` Thiago Jung Bauermann
2016-07-14 8:29 ` Arnd Bergmann
2016-07-15 1:44 ` Thiago Jung Bauermann
2016-07-15 7:31 ` Arnd Bergmann
2016-07-15 13:26 ` Vivek Goyal
2016-07-15 13:33 ` Mark Rutland
2016-07-15 15:29 ` Thiago Jung Bauermann
2016-07-15 15:47 ` Mark Rutland
2016-07-15 13:42 ` Russell King - ARM Linux
2016-07-15 20:26 ` Arnd Bergmann
2016-07-15 21:03 ` Thiago Jung Bauermann
2016-07-22 0:09 ` Thiago Jung Bauermann
2016-07-22 0:53 ` Jeremy Kerr
2016-07-22 2:54 ` Michael Ellerman
2016-07-22 20:41 ` Thiago Jung Bauermann
2016-07-15 8:49 ` Russell King - ARM Linux
2016-07-15 13:03 ` Vivek Goyal
2016-07-13 9:34 ` Mark Rutland
2016-07-13 17:38 ` AKASHI Takahiro
2016-07-13 17:58 ` Mark Rutland
2016-07-13 19:57 ` Arnd Bergmann
2016-07-14 12:42 ` Mark Rutland
2016-07-14 1:54 ` Dave Young [this message]
2016-07-14 1:50 ` Dave Young
2016-07-12 16:25 ` Thiago Jung Bauermann
2016-07-12 20:58 ` Petr Tesarik
2016-07-12 21:22 ` Eric W. Biederman
2016-07-12 21:36 ` Eric W. Biederman
2016-07-12 21:53 ` Petr Tesarik
2016-07-12 22:18 ` Russell King - ARM Linux
2016-07-13 4:59 ` Stewart Smith
2016-07-13 7:36 ` Russell King - ARM Linux
2016-07-13 7:47 ` Ard Biesheuvel
2016-07-13 8:09 ` Russell King - ARM Linux
2016-07-13 8:20 ` Stewart Smith
2016-07-13 7:55 ` Stewart Smith
2016-07-13 8:26 ` Russell King - ARM Linux
2016-07-13 8:36 ` Dave Young
2016-07-13 8:57 ` Petr Tesarik
2016-07-13 13:03 ` Vivek Goyal
2016-07-13 17:40 ` Russell King - ARM Linux
2016-07-13 18:22 ` Vivek Goyal
2016-07-18 12:46 ` Balbir Singh
2016-07-18 13:26 ` Vivek Goyal
2016-07-18 13:38 ` Vivek Goyal
2016-07-20 3:45 ` Balbir Singh
2016-07-20 8:35 ` Russell King - ARM Linux
2016-07-20 11:12 ` Arnd Bergmann
2016-07-20 15:50 ` Thiago Jung Bauermann
2016-07-20 12:46 ` Vivek Goyal
2016-07-20 12:27 ` Vivek Goyal
2016-07-12 23:41 ` Stewart Smith
2016-07-13 13:25 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160714015447.GB3121@dhcp-128-65.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=arnd@arndb.de \
--cc=bauerman@linux.vnet.ibm.com \
--cc=bhe@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=takahiro.akashi@linaro.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).