Received: by 10.213.65.68 with SMTP id h4csp41090imn; Tue, 3 Apr 2018 15:04:21 -0700 (PDT) X-Google-Smtp-Source: AIpwx48/PGMNpn2X0M+6u4n+TeK1M/XeuVjFlcLlNRId/809ClXcgBsJNQMZ36mmZNMBtb2kkZzc X-Received: by 10.167.128.71 with SMTP id y7mr11883431pfm.12.1522793061024; Tue, 03 Apr 2018 15:04:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522793060; cv=none; d=google.com; s=arc-20160816; b=GVX54z75FyNG/b/WR/R4ORgIAysuL1n5Vw0drJk6a5CNMx00s5BG6/Cy0Ibm3MtC0A m/4vOKMPbbU6sBMdv1Ng84CgxGjgGDPk7illjA3lKNyCVOiwJmcjUC434ILkMVeCkXst +NBYkGWxpS+BidEVDDnP2tI3eTYUe2TDlHSYmYpx9BpVo6c2z9b+y/uQj37mH4kKbCzM djLltJ0h4QVRgxg2zQMZ/koR/R2JoofHvyECa+C+oYf6MiG1GCu+VhEkscxfOZ+ljamj 1EXJBM2emDekRENmcaOUd9rk7ydKMqsT8J/bKmV0FfGe++ZspkrfEmBiyotdW110FJgk YN2g== 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 :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=cyEKRlIKlufFJbb4PeUCuTh87rGn/L1CIA1pJSapE28=; b=xlrZu9ZrTHL/Csu1ivqeJNxqPBahUaOvVhyk1CgTMHJkUZOSNSMQdaygUa610jvx54 IKvRb+pt0vtaZhsKDCRYP5RhaNcsl553EtmI37G4OaAfJoV4v/aST1XbHSTcR+9FA3rO ieCdejJdWyKF9Vz+dOZbWLjloA3Kf5N69QJKxFDb5K01kfifOmNG0Mg1axyaeRduN074 FQCXua0PRicYxbMn1G2WtAfUlhosP5VWTQvFG7OOIe6z0yJQ+H801WWIBSH7jnmmJCrF QgrjHQNXoq2kW6YbUvNg5sviteAC340BsyIy6U9SZwwajHyto0L7tWlfC1pKYy0VQl5U dFTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZfdqT1WV; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k26si2584676pgn.502.2018.04.03.15.04.05; Tue, 03 Apr 2018 15:04:20 -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=pass header.i=@google.com header.s=20161025 header.b=ZfdqT1WV; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753819AbeDCVdH (ORCPT + 99 others); Tue, 3 Apr 2018 17:33:07 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:40392 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753473AbeDCVdD (ORCPT ); Tue, 3 Apr 2018 17:33:03 -0400 Received: by mail-it0-f67.google.com with SMTP id u62-v6so13940111ita.5 for ; Tue, 03 Apr 2018 14:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cyEKRlIKlufFJbb4PeUCuTh87rGn/L1CIA1pJSapE28=; b=ZfdqT1WVWSJNwviphPK6RKF68Q3Q3fydCCm70oLGOlwXt66Nw9Fp//yWxlSb8v0AhJ EYnbsasOom+ti790G5NcuTwzgiHj+ZFtKffHHgPo01xfX7U3MbnvEcSmUOYXS8Xl2338 qgGUwB3VkObK8IF+hb7If9ESCrKjZNzZVInGhliNh086QFnkejzHJ/3SeQkjzEt1oXHD IgwMkAbQ1AfUUibLw8gFtp+AbEkYpphgzKOfTPYrAm/wE7vGkBEuElyNeUiW8T1vj+oj Bq9O/iwpVKfZJxrbPkS/xl3Ooc2LCxuD+hfdkpJRo7QhlefaJWNZE7uDIMLLowH7Ye1i dHpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cyEKRlIKlufFJbb4PeUCuTh87rGn/L1CIA1pJSapE28=; b=sZBurha9orW+YKDsiWfAz4q2Y/WUsN11TZA23D7nONjLno3biWx1/nm3TvyIdr5wgm GOGQf/zpgomR6Lf2tdH1lKBS9OKVt/bHAI8ueP7eegpjJa3phGs43go5dA+Ay17DlmdY j7jVD1vWTiLuZExCSFZR+wnck+kvuqkxNeeVvZ5m8DsfxucgjlNvCqHmaIjGnJPzaQOy XuZVCOd+IBW5zjmemu9Qne2WWpGwZ0QXK39o+bEgV1xVKQENnQwCKiobfeU9M2StpuBf H7spumIIDnybNPPrqpsWwxMShdVMPVSSH67Fs1iFvUY+UcRgGgFxJzcswvASkOxTY5Ft QFnw== X-Gm-Message-State: AElRT7FAxmgbUGexpifCnp/W7ZZ6LlNyr25oINZVTmFslBYmj6TjixTP Ankp+eFAZ4gnddDwnFrlc4/zkyAqay/9whQFsbCuBg== X-Received: by 2002:a24:530f:: with SMTP id n15-v6mr6579109itb.123.1522791181838; Tue, 03 Apr 2018 14:33:01 -0700 (PDT) MIME-Version: 1.0 References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> In-Reply-To: From: Matthew Garrett Date: Tue, 03 Apr 2018 21:32:50 +0000 Message-ID: Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Linus Torvalds Cc: luto@kernel.org, David Howells , Ard Biesheuvel , jmorris@namei.org, Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , jforbes@redhat.com, linux-man@vger.kernel.org, jlee@suse.com, LSM List , linux-api@vger.kernel.org, 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 2:26 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett wrote: > > > > Secure Boot ensures that the firmware will only load signed bootloaders. If > > a signed bootloader loads a kernel that's effectively an unsigned > > bootloader, there's no point in using Secure Boot > Bullshit. > I may want to know that I'm running *my* kernel, but once that is the > case, I trust it. If you don't believe that your self-signed kernel is going to be a threat against your security model then great! Don't turn this on when you build it. But if you built a kernel that didn't have this lockdown functionality and got it signed with, say, Red Hat's signing keys, anyone could take Red Hat's bootloader chain and that kernel and subvert the Secure Boot chain on any machine that trusts the third party signing key (ie, basically all of them) > Yes, on x86 hardware at least at some point MS actually had the rule > that it has to be something you can turn off. That rule is apparently > not true on ARM, though. Correct - there's no requirement that it be something you can disable on ARM, but since Microsoft won't sign any third-party code for ARM anyway it makes no difference to this discussion. > If you want lockdown, fine, enable it. But what the F*CK does that > have to do with whether you had secure boot or not? Because a kernel signed with a generally trusted key that doesn't implement any lockdown functionality is effectively a bootloader that will load unsigned material on most machines on the market, which reduces the security of users running those machines with Secure Boot enabled.