By checking I mean something quite rock-solid, i. e., trying to analyse loader's configuration or available kernel files and matching to uname's output clearly isn't an option.

  • dmesg or cat /proc/cmdline ? – SHW Jul 5 '16 at 8:36
  • such a deep question. I'd even say smth like "? or ?" – poige Jul 5 '16 at 8:56
  • I don't have kexec at my disposal to check. Hence asking to check either dmesg or cat /proc/cmdline ? – SHW Jul 5 '16 at 11:09
  • Such an excuse! ) – poige Jul 6 '16 at 11:39
  • @poige if a simple question with deep implications can't be answered it's most likely just that there's a gaping hole in the security itself. as it is, without any question, in this case. – Florian Heigl Jul 22 '18 at 17:06

In the general case, no, it's not possible, because nothing of the previous state can be trusted, and cannot be distinguished from a regular reboot.

Just say for a example you have a system that does NOT wipe RAM at boot (memory wipe on boot is required by some secure boot specs etc); The initial boot process and every normal reboot will generally happen at the same offsets, and wipe over everything from the previous boot over time. The kernel itself will almost always be loaded at the same address.

Now consider kexec instead of a normal reboot, and realize that everything should wind up at the same offsets, and be mostly indistinguishable.

Are there special cases where kexec CAN be detected? YES!

  • Kdump explicitly loads the new kernel at a different address, and hopes to preserve the previous kernel's memory for capture of error state.
  • If BIOS and kernel initialize hardware differently it (obviously) might be noted since there would be changes on each boot with switch "usual/kexec".
  • As a specific example of this, the EFI frame buffer is definitely altered by the kernel during boot, and never returns to the original state on kexec.
  • The corollary of this, is that if you don't control the boot of the kexec'd kernel, and it touches the hardware, there is pretty much no way to later decide if it was a real boot or a kexec boot.

As a demo, I booted a VM with a kernel, captured dmesg, then immediately did a hard kexec on it, captured dmesg again. Here's the diff between the two runs of dmesg: https://gist.github.com/robbat2/7609be2715591eac8ace3f46e852c549

  • > This only lets you detect the FIRST reboot with kexec — why you emphasised FIRST? If you boot normally state would return to BIOS's and it can be detected. So each time you know whether it wasn't BIOS boot. ;) – poige Feb 16 '18 at 14:33
  • @poige I updated my answer because this comment box was too short. – robbat2 Feb 20 '18 at 5:04
  • Still unsure why. kexec looks same no matter whether they're few in row or just single. In case you boot w/o kexec dmesg would be different. So that's why I see no point in this emphasising – poige Feb 21 '18 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.