Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1436715
| From | Dave Young <dyoung@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC] arm64: kexec_file_load support |
| Date | 2016-07-05 03:30 +0200 |
| Message-ID | <rRnlw-4AT-9@gated-at.bofh.it> (permalink) |
| References | <rPYSe-2uA-7@gated-at.bofh.it> <rQ8Rz-8qk-3@gated-at.bofh.it> <rR61k-2jM-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 07/04/16 at 03:58pm, AKASHI Takahiro wrote:
> Hi,
>
> On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote:
> > Am Freitag, 01 Juli 2016, 14:11:12 schrieb AKASHI Takahiro:
> > > I'm not sure whether there is any demand for kexec_file_load
> > > support on arm64, but anyhow I'm working on this and now
> > > my early prototype code does work fine.
> >
> > It is necessary if you want to support loading only signed kernels, and also
> > if you want IMA to measure the kernel in its event log.
> >
> > > There is, however, one essential issue:
> > > While arm64 kernel requires a device tree blob to be set up
> > > correctly at boot time, the current system call API doesn't
> > > have this parameter.
> > > int kexec_file_load(int kernel_fd, int initrd_fd,
> > > unsigned long cmdline_len, const char
> > > *cmdline_ptr, unsigned long flags);
> > >
> > > Should we invent a new system call, like kexec_file_load2,
> > > and, if so, what kind of interface would be desired?
> >
> > I'm facing the same issue on powerpc. What I'm doing is taking the device
> > tree that was used to boot the current kernel and modifying it as necessary
> > to pass it to the next kernel.
>
> That is exactly what I do.
>
> > I agree that it would be better if we could have a system call where a
> > custom device tree could be passed. One suggestion is:
>
> For powerpc, you might be able to use dtbImage instead of Image
> without changing the kernel interfaces.
> >
> > kexec_file_load2(int fds[], int fd_types[], int nr_fds,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags);
>
> You don't want to simply add one more argument, i.e. dtb_fd, don't you.
>
> I prefer a slightly-simpler interface:
> struct kexec_file_fd {
> enum kexec_file_type;
> int fd;
> }
>
> int kexec_file_load2(struct kexec_file_fd[], int nr_fds, int flags);
>
> Or if you want to keep the compatibility with the existing system call,
>
> int kexec_file_load(int kernel_fd, int initrd_fd,
> unsigned long cmdline_len, const char *cmdline_ptr,
> unsigned long flags,
> int struct kexec_file_fd[], int nr_fds);
>
> Here SYSCALL_DEFINE7() have to be defined, and I'm not sure that we will not
> have a problem in adding a system call with more than 6 arguments.
>
> > Where fds is an array with nr_fds file descriptors and fd_types is an array
> > specifying what each fd in fds is. So for example, if fds[i] is the kernel,
> > then fd_types[i] would have the value KEXEC_FILE_KERNEL_FD. If fds[i] is the
> > device tree blob, fd_types[i], would have the value KEXEC_FILE_DTB and so
> > on. That way, the syscall can be extended for an arbitrary number and types
> > of segments that have to be loaded, just like kexec_load.
> >
> > Another option is to have a struct:
> >
> > kexec_file_load2(struct kexec_file_params *params, unsigned long params_sz);
>
> Wow, we can add any number of new parameters with this interface.
>
> Thanks,
> -Takahiro AKASHI
>
> > Where:
> >
> > struct kexec_file_params {
> > int version; /* allows struct to be extended in the future */
> > int fds[];
> > int fd_types[];
> > int nr_fds;
> > unsigned long cmdline_len;
> > const char *cmdline_ptr;
> > unsigned long flags;
> > };
> >
> > This is even more flexible.
I would like to vote for this one, and use kexec_file_fd fds[] in the struct
Thanks
Dave
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC] arm64: kexec_file_load support AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-01 07:10 +0200
Re: [RFC] arm64: kexec_file_load support Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-01 17:50 +0200
Re: [RFC] arm64: kexec_file_load support AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-04 09:00 +0200
Re: [RFC] arm64: kexec_file_load support Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-05 01:00 +0200
Re: [RFC] arm64: kexec_file_load support AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-05 10:10 +0200
Re: [RFC] arm64: kexec_file_load support Dave Young <dyoung@redhat.com> - 2016-07-05 03:30 +0200
Re: [RFC] arm64: kexec_file_load support AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-05 10:00 +0200
Re: [RFC] arm64: kexec_file_load support Dave Young <dyoung@redhat.com> - 2016-07-07 08:20 +0200
Re: [RFC] arm64: kexec_file_load support Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-08 16:50 +0200
csiph-web