Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2574316imm; Thu, 16 Aug 2018 11:45:01 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwB0TO6XMJU1VtxszTli6l9yg/ZeDH3xLHIulg2C0TWm+ggYrZKRbkcEj/9YRIN0JXozyuo X-Received: by 2002:a65:498c:: with SMTP id r12-v6mr30588475pgs.112.1534445101081; Thu, 16 Aug 2018 11:45:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534445101; cv=none; d=google.com; s=arc-20160816; b=yhWosrwON2jA59VLe2jqCXlHARb57KeQfsFYx8mXhej3ox47POR7pUpkAx4LCsci5e CJyFI7g2NtTZFGmJHjkN4lp+4qOg4Fm1e9Mv2693M+z4a3D0iGlf1VUcuY5FHRQOsINS VEMzSD40FswypAaE+VQl/6e04BlkY3LpY64duhLU87nC9uWOxxQbOcQ2bjybBvwvB6Fu oAcv/keuRsowJHYFPH8ofBnjJM2MFN/RlDbZqXMj6xq0NKjeYm/A8bh91ip0gYUNQBho S8im+3EH/xWWUFevY1AWMMkQ4Vdyz0XrG5Kf58LKRR9GoDbHvlKZ5jBWBQyU7YWprDVg T2fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=fhC1x4QVGFNanx0xDUYnBONMX53anxUpUH7HcDSIZRQ=; b=W1ngyDffKK6+nxUwLyAFf1YByz6AALDUDScBt165oqQa729qs25jPYvZN9tp5cWRbW BbVPG/K9ioE2avJpy7b1Q0+ryEwUpnnYgqy6ojrlODFxffFmBwNohibW05KUGbloXYpo VSdfqEm1mq4jpvTxebZYT/z9y6LYnA8qFUp5Aaiu1PZOUAZljZBpj+vpQVoWZEI3tvMP +JrNVEyMnMfYI4Pz6RIVTvzY54MMqmu9QUhJyA9oEGKFAqVQT7mLupls8nOtKb7rJDlr H3NKiQvEIO0eSe64YXjEYZ5VKdlMeHtDkgFsT0BDMiQwGEUiHODBBODUiONEUksbACfB EE+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=CUKoKenV; 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=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v2-v6si52910pfv.57.2018.08.16.11.44.44; Thu, 16 Aug 2018 11:45:01 -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; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=CUKoKenV; 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=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392150AbeHPS4C (ORCPT + 99 others); Thu, 16 Aug 2018 14:56:02 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:43868 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729847AbeHPS4C (ORCPT ); Thu, 16 Aug 2018 14:56:02 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 6FBA48EE171; Thu, 16 Aug 2018 08:56:42 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GDi7ZiU2t7Q; Thu, 16 Aug 2018 08:56:42 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 97A678EE092; Thu, 16 Aug 2018 08:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1534435002; bh=aoYZPowDpNkzFGb2N+mrmS5Ih8SYCCRzM0hyP5ZUq7M=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=CUKoKenVKBvrEQZRF2EJuBOG57v9LOTOvJatGiDz6L9oBnnfXISjgKEAqwVgzDFUT zqM44vaBX63KigrAEHF/9R7aHFnkIapGJxr4Q9EtloWgoQMYBukZgLGuhiL+3w+q3Y lM2JKUgbFiRuGn1rp06Ycbhn86LQf0ztmVQ8n0iM= Message-ID: <1534435000.3166.9.camel@HansenPartnership.com> Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot From: James Bottomley To: David Howells Cc: Linus Torvalds , 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 , Matthew Garrett Date: Thu, 16 Aug 2018 08:56:40 -0700 In-Reply-To: <30607.1534434597@warthog.procyon.org.uk> References: <1534432615.3166.5.camel@HansenPartnership.com> <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> <20628.1534427487@warthog.procyon.org.uk> <30607.1534434597@warthog.procyon.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote: > James Bottomley wrote: > > > > 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. > > > > So if you build your own kernel and want to load the nVidia module, > > you have the key to sign it. > > I think you have to assume that doing this is beyond most people. As a step by step process, I agree. However, I think we can automate it to the point where you install a package and it says "insert your yubikey" every time you upgrade the kernel >   Further, as a distribution we would prefer people didn't raise bugs > against kernels that we didn't build. Mehmet's patches don't require building a new kernel. They merely require the added key be linked into the Red Hat built bzImage and then the resulting blob be signed. You can still identify that the original bzImage is the Red Hat one. > > If you're a distribution and want third party modules to be loaded > > you can set up a third party signing process using a distro key ... > > I don't see what the big problem is. > > That's the problem is right there.  AIUI, we *don't* want to set up a > third party signing process.  As I said, it potentially comes with > lawyers attached. Right so generate a business pressure to overcome the legal one. To be honest that's what I believe happened at Microsoft: I'm sure their lawyers initially said "no way" to being a third party signing authority until their executives laid out the business cost of being blamed for the first boot virus after having refused to implement ecosystem protection for legal reasons. > > So your lawyers tell you if you sign a third party module for your > > kernel then you could get blamed for the damage it causes? > > There's more to it than that, but I feel I should discuss it with our > legal dept. before airing it here. Sure; if you want me to be involved in the conversation I can do it under NDA or whatever they require. James