[RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Eric W. Biederman]

Vivek Goyal <vgoyal at redhat.com> writes:

> On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote:
>
> [..]
>> > If we are ok with the idea of passing executables and initramfs to
>> > kernel, then kernel can do the placement. That means fields "mem and
>> > memsz fields of kexec_segment will be free. We can possibly overload
>> > memsz field and pass flags to represent segment type. This will happen
>> > only if user chooses kernel as bootloader functionality.
>> 
>> Which sounds nice initially but I don't think the notion of the kernel
>> being a general purpose bootloader holds up to well.  It doesn't provide
>> an easy place to put all of the weird cases.
>> 
>> If we are going to pass in a file it probably makes sense to do a
>> variation of kexec_load that passes in a file descriptor, a filename
>> could work but I don't think we want those races.
>
> Can we use execve() style filenames. I am not sure what races are you
> referring to.

Files being renamed between the time we pick them and the time we use
them.  Classic programming practice uses file descriptors to allow
verifying the file you thought you had was the file you actually have.

>> But then we get how do we pass in a different kernel command line and
>> an initrd.  Things that were simple start quickly becoming complex.
>
> Can we take more than one filename arguments. Maybe an array of filename
> arguements. And another array of arguments.
>
> SYSCALL_DEFINE2(kexec2,
> 		const char __user *const __user *, filenamev
> 		const char __user *const __user *, argv)

The name would have to be kexec_load2 or perhaps kexec_load_file.

> This will allow passing filenames of both kernel and initrd and also
> allow passing arguments. Arguments will also include command line.
>
> Not asking user space to read in the file will help avoid loading
> one extra copy of kernel in memory.

There is that.  Although the difference between the page cache and in
an executables memory isn't particularly signficant.

> One difference here is though that we will have to allocate kernel memory
> for full kernel image and full initd and if images are big, it can lock
> down lot of kernel memory and in fact can trigger OOM on many processes.
> I guess that's an issue with existing kexec() interface too, so nothing
> new here.
>
> This is like re-designing the kexec/kdump and I really wish there is
> an easier way to handle the case signed kernels.

Yes.  Which is why either a signed puragtory or a signed /sbin/kexec
look very attractive.

Eric