antonblanchard / kexec-lite

kexec-lite

A simple kexec for flattened device tree platforms, on PowerPC.

Dependencies

Requires Make, a C toolchain, and the libraries libelf and libfdt.

sudo apt-get install libelf-dev libfdt-dev

kexec-lite's Issues

Design: improvements for integration with different init systems

Currently, kexec -e just does a:

		execlp("shutdown", "shutdown", "-r", "now", NULL);

This makes a couple of assumptions about userspace though:

• that shutdown is present
• that the init system will handle a fairly normal reboot request in a way that kexec expects (ie, ending with a reboot(LINUX_REBOOT_CMD_KEXEC)). This means that the init system needs to (somehow) detect, out-of-band, that we want to do a kexec reboot rather than a normal one.

Neither of these is true for busybox init, hence @mikey 's problems running upstream kexec-lite on petitboot. We have some glue in petitboot to handle this, but that's specific to busybox, and probably not something we want to integrate into kexec-lite as-is.

So, it would be great if we can design a better, lightweight way to tell init to shutdown & kexec. We'd probably need to coordinate with kexec-tools for this too.

kexec_file_load support for device-tree blobs

In Petitboot, we use the --dtb argument to pass a patched devicetree blob that may contain modifications caused by the boot hooks (https://github.com/open-power/petitboot/tree/master/utils/hooks). Some of those modifications may contain an adjustment of what the console device ([linux,]stdout property of the chosen/ node) should be.

The problem is that the new kexec_file_load() method apparently doesn't support this, and from a bit of research that I did (on the ARM64 implementation that I believe we share some commonalities with), it's not completely trivial to do so, because in a secure boot environment, giving complete control over the devicetree blob can be seen as a security opening (even if cmdline is as well and nobody cares about it so far).

Looks like ARM64 opted to allow the next kernel to inherit the devicetree blob from the current kernel (I think in ppc64 they all share the same memory region so that would work for us as well I guess) but before trying to change the entire architecture of how Petitboot implements dtb hooks, I was wanting to double-check that this is everyone's understanding of it as well, and what if any alternatives could be implemented.

tl;dr: kernel lockdown + kexec_file_load() broke Petitboot's ability to pass an alternative console to the next kernel, among other things.

Thanks,

-Klaus

a minor null-ptr dereference issue

initialize_fdt allocates a buffer to read the dtb file, like so:

p = malloc(st.st_size);

But, if p == NULL, kexec does not exit (it does print an error); instead, it moves on with reading of the file.

Request for more information

The readme only mentions "A simple kexec for flattened device tree platforms, on PowerPC."
Can you clarify how it is simpler (what are the problems with kexec) and what the restrictions are?
Why would someone choose kexec-lite over kexec?

Is this supposed to work for all powerpc systems, also embedded ones?

What are the restrictions for other architectures (which meanwhile also support FDT). Is it a matter of implementing support for it, or are there technical limitations why that is not possible?