lkml.org 
[lkml]   [2018]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot
    Date
    Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > > I see that module signing code trusts only builtin keys and
    > > not the keys in secondary_trusted_keys keyring.
    >
    > This, I think, makes sense.
    >
    > It basically says: we don't allow modules that weren't built with the
    > kernel. Adding a new key later and signing a module with it violates
    > that premise.

    At the risk of starting another flamewar...

    The problem with that is that it means you can't load third party modules -
    such as the NVidia driver. That's fine if you absolutely reject the right of
    people to produce third party drivers for the Linux kernel and absolutely
    require that they open and upstream their code if they want in.

    One of the reasons *for* letting modules be loaded using UEFI keys is that
    this allows you to load signed third-party drivers without needing to manually
    re-sign your shim, grub and kernel.

    But this is not something we can ask most ordinary users to do (not least
    because of key material security) - and they would have to at least partially
    repeat the process every time one of those components is upgraded. One of the
    jobs of a distribution is to insulate the ordinary user from this.

    And before anyone says "well, the distribution should just build and sign
    $THIRD_PARTY_MODULE", there are issues with that that potentially come with
    lawyers attached.

    Further, if you want to go down the route of restricting the use of UEFI keys
    to load modules because that might allow someone to run hacked code, then you
    also can't let kexec use UEFI keys because that would then be able to run
    hacked code too.

    As an alternative, though, maybe it would make sense to allow TPM-based keys
    to be used to verify modules. The problem there is that it doesn't prevent
    the signing process from being interfered with on an already-hacked box.

    David

    \
     
     \ /
      Last update: 2018-08-16 15:52    [W:7.805 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site