On Thu, Oct 18, 2012 at 01:22:01PM -0600, Khalid Aziz wrote: [..] > Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes > life even more difficult. Matthew Garret had earlier sent out patches to > support SecureBoot on Linux and one of the things those patches did was > to disable kexec completely. That is a drastic measure and ok as a short > term solution but we need to come up with something better. If > SecureBoot does not go away, we will have to do something in kexec-tools > or even kernel to validate kernel code being loaded for kexec/kdump and > the purgatory code as well. This will require interfacing with UEFI key > checking mechanism. That is going to be ugly. CCing Eric and Matthew Garret and hpa. Ok, I will split this thread in two parts. Lets us quickly discuss the UEFI secure boot also as it is happening soon. I was thinking that how about supporting in kernel bootloader. That is, kernel acts as a boot loader. User passes the kernel, initrd and commandline from user space using kexec system call and kernel parses it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs, backup region, elf header region etc). At the time of kexec -e, we just follow th regular path and jump to second kernel. At the time of loading, kernel can verify the signature of incoming bzImage and reject it if signatures don't match. Matthew mentioned that kernel signing certificate will be available inside the running kernel, so verifying PE/COFF bzImage should be easy. We don't have to worry about initramfs verification as it runs in user space. There is one side issue of acpi_rsdp. Because second kernel executes the code specified by acpi_rsdp, it is unsafe to let user specify that location. Matthew metioned that figure a way out to pass acpi_rsdp using boot params and drop it from command line. Looking for thoughts and ideas on how to support kdump with UEFI secureboot. (This is assuming that kdump already works with UEFI with parameters "noefi" and "acpi_rsdp" in non secure boot mode). Thanks Vivek
