Received: by 10.213.65.68 with SMTP id h4csp103654imn; Tue, 3 Apr 2018 16:29:30 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+ZLpQNWnR3SNXBWuccjxMsBIV3Mt5Fb5SvW9MQKGG/9PRLqMyAln7Y8pOHhj9JZMnQfFpn X-Received: by 2002:a17:902:9696:: with SMTP id n22-v6mr16531835plp.355.1522798170755; Tue, 03 Apr 2018 16:29:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522798170; cv=none; d=google.com; s=arc-20160816; b=FdbX34ffxJ/SfFydxbIYkEgnQhrZJGgaqpnpUZW764qE3tL2nGQK1lQXukPlZTioMC 4NvDyfFxTJlET+S7SX8qDLD1zxSbgACQhjSfbLQ9kaPcN1j1t2r2tlQu6pDzYEqu5h1X 5WXKZKfLjZW1v6u0hrSv/FQCUf9VXtg62+Y2uaHgcQwOZa1JudzCIsyn0w1HRXpOCRl3 KDZ99GDDb8uD0P5Kr7ysvFXq5KirAc6T5Hww41/yO0eQwJMo98TYlYGbzmFE/oNZ15OR eaJH5XqnTiPn2DL6IFjgZ5WEgW0qf4Y3OUfWZnNAAdJvzDeFFeAMoR0geakB43c0hlCq MJmg== 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=zT10w7QBYHzO7AYVURKoSrZ68bRc1BhIoAgCL0FvXcg=; b=1H9vqu9XRhppC21bfjcQlpgqQ2rhF9GPoQWv1iaEnGyOfjI1OcL9yLTgndW/sfQ5MG 3MXy98BLxpbr6ixuNhhlwIbdDh1HcuoSW1cNpBdOwgMkP5Xhzc4jO1SaVLWXEHbko9zR c9lGr1DrdIsV6LjDadBBcE4LjfV8oHsSo92vmiauQeOAgzqblAR2ooE31x0///vEtlUO HEfNK2mIBYuZsnqxc1bpfymvqfPYughTIWSGl60K+LNLHEw+RG4l6py4Y8p4z7owPgIO dbm8tSw/VL/7ckOPWA8X/wGceirmm114XHXZvitLt/N86bv9MVmuvVy/FIL0mJCv+kcy vbzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=LQ726aLF; 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 s19si1103785pgv.479.2018.04.03.16.29.16; Tue, 03 Apr 2018 16:29: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; dkim=pass header.i=@google.com header.s=20161025 header.b=LQ726aLF; 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 S1755450AbeDCWv0 (ORCPT + 99 others); Tue, 3 Apr 2018 18:51:26 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:40385 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753691AbeDCWvX (ORCPT ); Tue, 3 Apr 2018 18:51:23 -0400 Received: by mail-io0-f193.google.com with SMTP id e79so23992494ioi.7 for ; Tue, 03 Apr 2018 15:51:23 -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=zT10w7QBYHzO7AYVURKoSrZ68bRc1BhIoAgCL0FvXcg=; b=LQ726aLFA20+EnaJO4iiGiRZC81SLcq7nis3Mft5rwcz/9W5LK1VCE98/oCenXLodg tp/AkMJsgzY26UGUZrwwN28gPNvCqpIGYR4NfIXQGkpu8gxWlPfECBxuG6rtD1Z6NXN/ v6+uViJsPSushRUnAVU61pocOr1S12ft2fuYAB+vbNnXzvTtyEdU7SSTzeHCQ8jhjqNz K9/TOqCSAHsT08JmIBRwm08/PDs/9UtUpcVqbTvf/7ayl+ZO4HE2QY5nLpIdLT3cQ2vM oVu5muZcLLb5QCfQxVKqqTx6jsNHRX4ThZdNMi3VW9OgmlOasZMbJbkjsIxc4jfK2ttq Jysg== 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=zT10w7QBYHzO7AYVURKoSrZ68bRc1BhIoAgCL0FvXcg=; b=B19vlxMPLsXAzSyvSqBhQCIJZ0oPq4Bn20/NRT5cqyROqtuaXtGQrHSjPe/WK+DEWM CRtQiZc9e169AgRX3ZxVjoLrgku7DpisQW1tRhNK0M3ky0NjenbK2nBTgC8kEsuZgHOB jgmqH2vcb4BfoOrGhhzMVhuKvFUgynCPFgu0GQR1wyWCHCjleNsnplTHBzNMTuN70VSa kd7yyILn0iXeSIS30gLCuQSIzHnfjFAdaRoKPlmxGXHkq2l4Cqlrhls+MgFUUfxPIJ+k q/7pNjRlgAT/oOrLHrxrx3ZcIK9TObNCBXEx8lfa4B1E6HUEw4uKRtD31nylfNlcFJXy Ilxg== X-Gm-Message-State: ALQs6tC1DPgg/ELjprUn5L5DQ+y8MpwnNl/fTIFyi5mZzkgRj0Hl2VGq zLM8Oxn6beRsGYL1xq7Olcgj8Il2c5nUulrNhmmwDA== X-Received: by 10.107.34.197 with SMTP id i188mr14106818ioi.287.1522795882622; Tue, 03 Apr 2018 15:51:22 -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> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> In-Reply-To: From: Matthew Garrett Date: Tue, 03 Apr 2018 22:51:11 +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 3:46 PM Linus Torvalds wrote: > For example, I love signed kernel modules. The fact that I love them > has absolutely zero to do with secure boot, though. There is > absolutely no linkage between the two issues: I use (self-)signed > kernel modules simply because I think it's a good thing in general. > The same thing is true of some lockdown patch. Maybe it's a good thing > in general. But whether it's a good thing is _entirely_ independent of > any secure boot issue. I can see using secure boot without it, but I > can very much also see using lockdown without secure boot. > The two things are simply entirely orthogonal. They have _zero_ > overlap. I'm not seeing why they'd be linked at all in any way. Lockdown is clearly useful without Secure Boot (and I intend to deploy it that way for various things), but I still don't understand why you feel that the common case of booting a kernel from a boot chain that's widely trusted derives no benefit from it being harder to subvert that kernel into subverting that boot chain. For cases where you're self-signing and feel happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n and everyone's happy?