lkml.org 
[lkml]   [2015]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Should we automatically generate a module signing key at all?
    From
    On Fri, May 22, 2015 at 7:13 AM, George Spelvin <linux@horizon.com> wrote:
    >
    > 1) Create a tool to canonicalize the kernel and modules,
    > stripping out the signatures before comparing them. This has
    > precedent in the way the prelink tool can un-prelink binaries
    > so that hashes can be verified.

    So I'd obviously prefer this, so that we have just one model for verification.

    I forget the exact details of the signature (and am way too lazy to
    look it up), but for the modules themselves, it's just appended to the
    module contents. So getting rid of the signature is literally just
    truncating the module to the original size.

    For the kernel image, it's a bit nastier, since the public key is just
    inserted into the object file as variables (system_certificate_list:
    "__cert_list_start...__cert_list_end:" and the length in "unsigned
    long system_certificate_list_size"). And because the size of the
    certificate list is variable, you can't just zero it out or anything
    like that to make things compare equal.

    Of course, even just zeroing that out will probably work as long as
    you use the *same* setup (ie kernels with just the one randomly
    generated key will probably have the same certificate size - I say
    "probably" because I didn't check how the encoding might affect it)

    But we might also simply decide to pack the keys differently. I'd
    personally be ok with it being in the initrd, for example, although
    for all I know that might screw up the people who actually want to use
    the BIOS secure booting thing (I don't know how much that verifies).

    Linus


    \
     
     \ /
      Last update: 2015-05-22 23:21    [W:2.760 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site