Received: by 10.213.65.68 with SMTP id h4csp193888imn; Tue, 3 Apr 2018 18:38:04 -0700 (PDT) X-Google-Smtp-Source: AIpwx48NbSlzUvLRbplOQXFCBUiiLuyswhJNABtg1/n7DBiQjHk+LyxeKpX6HPcFMhbolZ4C6S/d X-Received: by 2002:a17:902:820a:: with SMTP id x10-v6mr7263419pln.306.1522805884055; Tue, 03 Apr 2018 18:38:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522805884; cv=none; d=google.com; s=arc-20160816; b=zxnZezf05isjeEs/Hxf9qXKNWWzYjHgNIFlCyepLhlo0KIFPI/mzXiIdBe1xM6Hfdy uxC/LyTnDXw9EPxvz92NyyxAjOMT01/Dp6Mb1YlSOmYJygRKqc6BufNXfm4F50CyHNwM 8DWsIrxU/v7z6rjEt2Cvq/KgjGrSigy6iAEB0d9C5lJ/BqRd2LNChlei2rVjWnzMsdRj hWFnsBB6BoOK253gOcVgC29HvBjg+CCNHXyZ+JdZFYQpZY2D53ZnusPa40eV3gQiEDrq be4rJrK/x+HC/oZpqgelf9rg1+oH49XaDx6y6Jqko8sbT7KpYlPZFtkWBtqeXrt3oUHM XY0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=lzK1VmvIedud77vxp4DY0Fw0OpHYQeduo1pAnL/ol1Q=; b=S97ndsRt3jmxFxOXIMj+uCqDtMK1TKtr5cff45hacXrbN+E9YezybYV2bd8iAwnHQq 1+djgcsqzkW0XOmll7upviSA7MGOI0FOcMCLCnwTV2xBd1Y7LenaCW+Dg1nA3q0jcyeB azCOoTqFHcQS91o2Ng5gadQdA9uNnH0ZgV9xDZFGGb/zqS9ay1i531s2uEf0tO6mQe0O omeWuyBdobRTaI5pT1MoUYaV5qIYlDF0KDDmmLKr53s01hseR1fpP1d0lw/DbhqJtl2l QAv30zyqMuS8tNDEHqzokgjN6tzz+duVTcy+L8o78wGq+FyOWkCgJaYIjxL24RnpWVmq Lbvw== 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 z21-v6si1840002plo.225.2018.04.03.18.37.49; Tue, 03 Apr 2018 18:38:04 -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 S1754719AbeDDBgq (ORCPT + 99 others); Tue, 3 Apr 2018 21:36:46 -0400 Received: from mail-ot0-f195.google.com ([74.125.82.195]:38231 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754079AbeDDBgn (ORCPT ); Tue, 3 Apr 2018 21:36:43 -0400 Received: by mail-ot0-f195.google.com with SMTP id o9-v6so21612843otj.5 for ; Tue, 03 Apr 2018 18:36:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lzK1VmvIedud77vxp4DY0Fw0OpHYQeduo1pAnL/ol1Q=; b=oHMTT+5Q0VCeB4Ci3NAaPZxhHnjGZDKX3mqK1gSueDoGBaBjcztCPTFdI9HIiOx1BP LdIFQON8KP1OIsbn3dbfsxV8juD+EF//FYmqqWMFl9tEatNQyNHjzNDd56YfIjcvIUEq OTuPzbQRH9BlCfdQsaFzYhJkuiGUND6y23aUEq+0fK+Z/haoTLbx5duIJP3DwFjrhUM6 EiD3OyEFEe05bf4U81vHj0GbAnTZ2xO7H8pVEelDKFhCZcDxdzZlAPSYu30O+BVOG/Sj dwzm5IsXP5joR9bpXuRKxj1MuzwFvMbWIQSkESeIA1nwJ1bnBEJOexac99FGVX7XYLOU tyMQ== X-Gm-Message-State: ALQs6tANLgHjYvkEY8/1/pL/cyHiduWP97wA/itU4dZIckF8IDmYCnnZ 1QCRTUvqqvbg3+MTv2+jtNzsN2BMXTynHh7yw3ZKnA== X-Received: by 2002:a9d:2f26:: with SMTP id h35-v6mr8960648otb.61.1522805803101; Tue, 03 Apr 2018 18:36:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.65.9 with HTTP; Tue, 3 Apr 2018 18:36:42 -0700 (PDT) In-Reply-To: References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> From: Justin Forbes Date: Tue, 3 Apr 2018 20:36:42 -0500 Message-ID: Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Linus Torvalds Cc: Matthew Garrett , Andrew Lutomirski , David Howells , Ard Biesheuvel , James Morris , Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-man , joeyli , LSM List , Linux API , Kees Cook , linux-efi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett wrote: >> >> The generic distros have been shipping this policy for the past 5 years. > > .. so apparently it doesn't actually break things? Why not enable it > by default then? > > And if "turn off secure boot" really is the accepted - and actuially > used - workaround for the breakage, then > While there is very little breakage in the *years* we have been shipping this in distro kernels, the accepted and used workaround has always been "turn off secure boot" or sign/import your own keys, depending on the problems encountered. > WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST > PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED? > > Sorry for shouting, but really. We have a thread of just *how* many > email messages that asked for the explanation for this? All we got was > incomprehensible and illogical crap explanations. > > If there actually was a good explanation for the tie-in, it should > have been front-and-center and explained as such. > Honestly, yes, the major distros have been shipping this patch set for years now, and every time it comes to upstream, the same damn arguments emerge. I do not disagree that there are uses for lockdown outside of secure boot, provided you have some other mechanism to verify your chain, I believe chrome OS does. But the tie to secure boot is because that is the use case that users have been using for years, it was discussed at kernel summit quite a while ago, plans went forward there seemed to be agreement, and when it comes time for a pull request, people come out of the woodwork with an expectation that it solves every problem or it doesn't need to exist. What is here is a good starting point. I would expect that if it were merged, others would build upon that and use much of the code already in place to extend it. It is tied to secure boot because that is what has been using this for years as it never seems to get upstream. I am sure that once it does finally land, it can and will be extended to other things, but I don't think I would want to spend a lot of time trying to leverage another external patch set that has been delayed upstream so many times until it actually did land. As for the ties to MS that come up every time, and have here as well, there is no requirement on the MS signature. You can import your own keys if you don't want them involved, I keep a "test key" imported for actually running what I build locally.