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

[Vivek Goyal]

On Mon, Oct 22, 2012 at 02:07:56PM -0700, Eric W. Biederman wrote:

[..]
> > Can we pass all argument in one kexec segment and let associated image
> > format handlers parse the arguments.
> 
> The issue is can we pass trusted arguments?  Any kind of firmware
> callback ACPI, EFI, openfirmware etc needs to be in the trusted
> parameter set so it must come from a trusted location.
> 

I think parameters will include something like read only one and second
kernel should be able to verify it. It should not be an executable code
of any form. (like acpi_rsdp).  I think this is similar to that we don't
sign/verify kernel command line passed in a bootloader. 
 
> Unless we can trust the /sbin/kexec binary we can't trust pointers
> to executable code passed to us that we can not verify are safe.

Given the fact we allow user to specify command line, even if we sign
/sbin/kexec, we have no way to trust it. IMO here we just need to make
sure that input parameters/arguments can't lead one to execute arbitrary
code.

[..]
> >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> >> and it is conceivable to have ELF note sections with signatures for
> >> executables.
> >
> > Can you please tell more about what is EMA and IMA. I did quick google
> > and could not find much.
> 
> That should have been EVM and IMA.  Look under security/integrity/.  I
> don't know much about them but they appear to be security modules with a
> focus on verifying checksum or perhaps encrypted hashes of executables
> are consistent.

I will do some quick search there and I see if I can understand something.

[..]
> It just occurred to me there is a 4th approach we can take that seems
> interesting.
> 
> Have a system call where you pass in a signature of yourself, that will
> allow you to increase your set of capabilities.  I am a good binary here
> is proof.  I initially that it might be a complement to sys_kexec_load
> just for the kexec case but there is no reason to limit it.

If one presents its own signature, then anybody can copy and present
that signature. There needs to be a mechanism to verify that you 
actually have the signature you are presenting (i mean digest of
executable).

So above does not address that how that new system call will verify the
signature/hash of process invoking system call.

[..]
> > - What happens to purgatory code. It is unsigned piece of code which
> >   runs in kernel?
> 
> The purgatory code would need to be signed.  Which is why it is
> important to enable composition of signed pieces of code.

purgatory code is modified dynamically upon every invocation of kexec.
That means there needs to be a mechanism to sign it after we are done
with purgatory modification. But there are no signing keys available
on the system. All the signing happens externally during build time. So
we don't have the option of signing purgatory at run time.

Thanks
Vivek