On Fri, Nov 22, 2013 at 10:33 AM, Jiri Kosina <jkosina at suse.cz> wrote: > On Fri, 22 Nov 2013, Geert Uytterhoeven wrote: > >> >> Only arm, i386, ppc, ppc64, sh, and x86_64 support zImage. >> >> It's not clear to me what alpha supports (if it supports anything at all?). >> > >> > Motiviation behind this patchset is secureboot. That is x86 specific >> > only and bzImage is most commonly used format on that platform. So it >> > makes sense to implement bzImage loader first, IMO. >> >> While secureboot(TM) may be x86-centric > > And ARM, right? > >> IIRC actually loading signed kernels and modules didn't originate on >> x86. Anything can have a bootloader that accepts signed kernel images >> only. > > Yes, but if you don't have the whole secure boot security model (i.e. root > is implicitly untrusted), it's all just a game really. > > If you are playing this "signed kernel and modules" game, but have trusted > root, he's free to replace the bootloader by one that wouldn't be > verifying the kernel signature, and reboot into arbitrary kernel. Ignore secureboot completely. Consider a cloud provider who gives their customer a machine where they, the cloud provider, is specifying the kernel and initrd. This is a real thing that people do today. Root on the machine has ZERO control over the kernel, bootloader, and initrd. Check it out, qemu/kvm can do this. But, there is no way to disable kexec if the distro configures it in (well, there is in RHEL at least). I've brought this up before with little useful response from the kexec maintainers. What I'd like is for a kernel trusted by me, the cloud operator, to be able to be kexec'd. I'd rather not have to completely turn off kexec... Make sense how this is useful for things other than secureboot? And we have users who want this. This is not a speculative completely made up maybe some day someone will want this type idea....
