lkml.org 
[lkml]   [2012]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Second attempt at kernel secure boot support
    On Mon, Nov 05, 2012 at 09:37:18AM -0600, Chris Friesen wrote:
    > On 11/05/2012 09:31 AM, Jiri Kosina wrote:
    >
    > >I had a naive idea of just putting in-kernel verification of a complete
    > >ELF binary passed to kernel by userspace, and if the signature matches,
    > >jumping to it.
    > >Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other
    > >functionality currently being provided by kexec-tools.
    > >
    > >Bah. This is a real pandora's box.
    >
    > Would it be so bad to statically link kexec?

    statically linking and signing /sbin/kexec is sounding most reasonable so
    far, to me. Even if we do that, there are few more issues queries though.

    - Do we still need a new system call?

    - Who does the kernel signature verification. Is it /sbin/kexec or kernel
    should do that.

    - If kernel is supposed to do kernel signature verification, how the
    signed bzImage is passed to kernel with existing system call.
    Are certificates passed in separate segments. How does kernel
    differentiate between segmets etc.

    - Does signed /sbin/kexec means that it can load any other segments
    like elf header, boot_params and no signature verifiation is needed.


    If we move all the kernel signatuer verification part into /sbin/kexec,
    then we should possibly be able to use existing system call. But I don't
    know what kind of crypto support we shall have to build into kexec-tools
    statically and how much help we can get from static libraries and how
    much work it is.

    Thanks
    Vivek


    \
     
     \ /
      Last update: 2012-11-05 20:02    [W:4.179 / U:0.916 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site