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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks
Vivek



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux