lkml.org 
[lkml]   [2011]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]
    Date
    Rusty Russell <rusty@ozlabs.org> wrote:

    > > > Sure, you now need to re-append that after stripping, but that's not the
    > > > kernel's problem.
    > >
    > > You may also have to remove the signature before passing it to any
    > > binutils tool lest it malfunction on the trailer
    >
    > Well, you're already on your own if you're using non-module-init-tools
    > tools on modules.

    The distributions packaging tools and initramfs tools are things I have to
    contend with, and others will have to contend with.

    > (We'll want to enhance modinfo, at least, to show the signatures).

    Ummm... To show what exactly? And why? The modinfo has to go into the
    signature hash. Further to find the modinfo, you have to parse the ELF - which
    brings us right back to how do you know you can trust it?

    > > I've found that rpmbuild and mkinitrd alter the module files at
    > > various times, so you'd need a bunch of signatures, one for each (may
    > > just be two, but I can't guarantee that). This means the kernel build
    > > process needs to know what transformations are going to be applied to
    > > a module - something that has changed occasionally within the
    > > distribution I use and may vary between distributions (or even just
    > > someone building for themselves).
    >
    > Yes, there may be more than stripped and unstripped. You may need to
    > do fancy things. But now, adding a signature is so easy that it's not a
    > real problem. And we can always have a hook, like:
    >
    > if VARIANTS=`make-module-variants $MOD`; then
    > for m in $VARIANTS; do sign $m >> $MOD; rm $m; done
    > fi

    That's not very practical. That spreads the what-do-we-need-to-calculate
    question over a whole bunch of packages: the kernel, rpmbuild (if RPM-based),
    mkinitramfs and maybe others. I presume you're thinking of trying all the
    possible strip combinations and generating a signature for each? However, if
    someone upgrades their binutils, but not their kernel, say, and then their
    initramfs gets rebuilt for some reason, this may invalidate all their module
    signatures.

    So the number of signatures is:

    strip_combos × binutils_variations × other_factors

    and you have to generate all these at kernel build time because the secret key
    cannot be disseminated to the installed machines that might be affected by
    this.

    (Note that binutils may rearrange the symbol, relocation and section tables in
    different ways for different versions.)

    David
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-12-10 15:11    [W:4.178 / U:0.576 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site