[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 Fri, Nov 02, 2012 at 02:36:11PM -0700, H. Peter Anvin wrote:
>> On 10/22/2012 02:15 PM, Eric W. Biederman wrote:
>> >>
>> >> 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.
>> > 
>> 
>> Signed purgatory sounds like The Right Thing.  Doing relocation in
>> purgatory should be quite trivial; I'd be happy to work with people if
>> they need pointers how to do it.
>
> So we sign purgatory and do the relocations in kernel later after
> signature verification?
>
> I have few questions though.
>
> - We modify purgatory (update symbol values) in user space. That allows
>   us to build single purgatory and chagne its behavior based on user
>   options to kexec-tools (like 16bit vs 32bit entry, updating location
>   of backup region etc). In fact purgatory to kernel jump location is
>   decided at run time and purgatory is updated accordingly. That means
>   we can't sign the purgatory.
>
>   So apart from relocation, user space modification of purgatory code
>   is also an issue. 
>
> - Even if we come up with a way to avoid that, so will we not sign
>   /sbin/kexec in that case? What happens to other unsigned segments
>   loaded by /sbin/kexec. (boot_params, command line, elf headers etc).
>   Can these be trusted without any signature.
>
> So I am not sure that just signing the purgatory will solve the issue.

The oddball part to add to this theory is that to sign purgatory may
imply moving more functionality into purgatory.  To the possible silly
point where we move most of kexec-tools into purgatory and do the work
in-between kernels (ick).

Eric