[RFC 0/3] extend kexec_file_load system call
arnd at arndb.de
Wed Jul 13 23:13:42 AEST 2016
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, Arnd Bergmann wrote:
> > > > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote:
> > > >
> > > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived
> > > > from the raw DTB (which is exposed at /sys/firmware/fdt).
> > > >
> > > > The blob that was handed to the kernel at boot time is exposed at
> > > > /sys/firmware/fdt.
> > >
> > > I believe the blob can be read and passed to kexec kernel in kernel code without
> > > the extra fd.
> > >
> > > 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. From my understanding
> > > it is reasonable but yes I think we should think carefully about the design.
> > Ok, I can see four interesting use cases here:
> > - Using the dtb that the kernel has saved at boot time. Ideally this should not
> > require an additional step of signing it, since the running kernel already
> > trusts it.
> We have sufficient information from the existing kexec_file_load syscall
> prototype to do this in-kernel.
> > - A dtb blob from the file system that was produced along with the kernel image.
> > If we require a signature on the kernel, the the same requirement should be
> > made on the dtb. Whoever signs the kernel can also sign the dtb.
> > The tricky part here is the kernel command line that is part of the dtb
> > and that may need to be modified.
> I suspect that for this case, following the example of the existing
> sycall, we'd allow the kernel to modify bootargs and initrd properties
> after verfiying the signature of the DTB.
> The big question is whether this is a realistic case on a secure boot
What does x86 do here? I assume changes to the command line are also
> > - Modifying the dtb at for any of the reasons I listed: This should always
> > be possible when we do not use secure boot, just like booting an unsigned
> > kernel is.
> This is possible with the existing kexec_load syscall, for the non
> secure boot case.
Ok, let's skip that then.
> > - kboot/petitboot with all of the user space being part of the trusted boot
> > chain: it would be good to allow these to modify the dtb as needed without
> > breaking the trust chain, just like we allow grub or u-boot to modify the dtb
> > before passing it to the kernel.
> It depends on *what* we need to modify here. We can modify the bootargs
> and initrd properties as part of the kexec_file_load syscall, so what
> else would we want to alter?
I guess petitboot can also just use kexec_load() instead of kexec_file_load(),
as long as the initramfs containing petitboot is trusted by the kernel.
More information about the Linuxppc-dev