Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2559551imm; Thu, 16 Aug 2018 11:28:30 -0700 (PDT) X-Google-Smtp-Source: AA+uWPySvsefb42vQp+kT/trNqbF4vwS7Vge3XTJ3TtcV2OkmdsF7Ov2HPPNrQoi7HuCxAGYfwVF X-Received: by 2002:a17:902:b486:: with SMTP id y6-v6mr29914452plr.27.1534444110251; Thu, 16 Aug 2018 11:28:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534444110; cv=none; d=google.com; s=arc-20160816; b=F95pH9SEM9vw2R56dXQ6aMsCEnv1Y55lWEqJpkzZV1jz94VJ+P0OCANErxM/8ROTOg PN2J7qpAvEIrK/wi3Fn3Tr/MTJRRh3t0WxbfoT2QFdu9tq3dH0JpBM4U9jfIWhfrV+k6 o5auWIz8RB3cx/5wRf1eFZvb9p+YQXB0ThMYpiUFkaOJgLUhypvVxpx48uGfqXTCeF0O tgsd0kgGsIAw46Fqx8TiHsxQQ7AVX4kcJ/2Z12oo+c/jLbcslloizWOXREK+KU9KPi8K EwDsJyIdBvqH8KMK4lvWaOL2z+u7x/08MYobiD3OmotC7ahnz3jYKGHp5P1FV3pzQ6d/ psTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:content-id:mime-version :subject:cc:to:references:in-reply-to:from:organization :arc-authentication-results; bh=D0j+toVE8lf1gqixhhnzyO9zVDgHxd+cuJeOXNbRIXU=; b=fBFkGb4SGMQqkrqodE1WuRMSitpg2zxqaXd4rHmL/Qtj2ZB+d5TpgtKspNyp1T5keE 2yBKHJjQEEdXgTmSPuZUVJv+KBAYAkl9IJq534p6cvVCUXsmDGfR6oPSGRJvSYQ3cEHy H8g0ciNVs5DbxK5/S+s9iRSqigAgo5mqy37YC6yIq4CfnezoUCyY4DnD3zTzOkxHm31A AeVsZ4xaNDkPbJaAodtfO3GTdU3W9fZemU0yD7EJiJKDAEyoGhbHbqjkiJG8wazlMX5H wAY74Lkplm6HmOAKvvHZINSDRxgkFuwCYIQa0XtsO/QlnsgzlTQWr280VxusC79Q2hMx Q0YA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g13-v6si5832plo.153.2018.08.16.11.28.15; Thu, 16 Aug 2018 11:28:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389442AbeHPQuS (ORCPT + 99 others); Thu, 16 Aug 2018 12:50:18 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39000 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388977AbeHPQuR (ORCPT ); Thu, 16 Aug 2018 12:50:17 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B1FE5406E885; Thu, 16 Aug 2018 13:51:31 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-120-130.rdu2.redhat.com [10.10.120.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 00C5616870; Thu, 16 Aug 2018 13:51:27 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <20180815100053.13609-1-yannik@sembritzki.me> <654fbafb-69da-cd9a-b176-7b03401e71c5@sembritzki.me> <20180815174247.GB29541@redhat.com> <20180815185812.GC29541@redhat.com> <20180815194932.GD29541@redhat.com> To: Linus Torvalds Cc: dhowells@redhat.com, Vivek Goyal , yannik@sembritzki.me, Thomas Gleixner , Ingo Molnar , Peter Anvin , "the arch/x86 maintainers" , Linux Kernel Mailing List , Dave Young , Baoquan He , Justin Forbes , Peter Jones , James Bottomley , Matthew Garrett Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20627.1534427487.1@warthog.procyon.org.uk> Date: Thu, 16 Aug 2018 14:51:27 +0100 Message-ID: <20628.1534427487@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 16 Aug 2018 13:51:31 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 16 Aug 2018 13:51:31 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dhowells@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds 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