Received: by 10.213.65.68 with SMTP id h4csp127440imn; Tue, 3 Apr 2018 17:04:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/P3xhzEUkd+ugyL1GzR3MSemjrC67ObPhVx3P0HdtZqaDV3KHQiCTq62RwWPIQwpD+b2rL X-Received: by 10.98.87.150 with SMTP id i22mr5769748pfj.119.1522800262434; Tue, 03 Apr 2018 17:04:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522800262; cv=none; d=google.com; s=arc-20160816; b=JFragVzcjQwkJdtDGm0FsHS9c9joQmk4F2NZZ3vCa02X5bvNCUnGSrmaE3taKiW+z1 vcYcXCo8Z9zc716+JeDupd/7URVIL3HJ76gbCjIyjct1RSlOrUmaQQawU4dRoTpIWjMw wlimhOwvVEVfZfDPsjlpwPWUvYPzIRnpyD/DGPOHhM5NTbpBDYTXY/FZc13ZbtCvJvU/ 5W8yJj9N1S9ILag3TECfehUw6qNHsQ+Cjlk5wgrmRnF9XzmOr1hBu0tKmLe0I8211G7k G2AwXhiaqdR9MSAI7NTJqO72YyBtnciY3Id9DVyPJLuw6Y8ibhl1cITlHCKJ+OU03MOW YWTg== 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:dkim-signature:dkim-signature :arc-authentication-results; bh=aMsj5EKWr5B6VzMhide4jMF7IypW+V1l1NnzfSO93XU=; b=lVOM3rbk+y/UwZWCnGgr385j8xGWldM8SHt7ssP+9M/Uo6VGHYeYXZi+UdCKNnMY4X Ht+bBKcrC8drJgH9nMuCFqL9oGrLm5XlGatQYYWCDJvyPqTrQpsSZIuCpN20LkSdH51U jqaQxZz381sJx8GDfBdBXMynZQZ4E15sjEni4ubGODyEi6xClj9nuvKQ5+1elXeGasbN xvBHGqP8fblVi14vV0psTkBP6NfTUu6YEkCwlpqLl/vHLr9vlzRhlPqKharbszggww8N 9eSuIoaF4NdUn+J4jYVyqt3Y9Xdy3UbV8E7l+6YGEDswH7N3ASkbgXupQ8tu/s/W2P8v SKtQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Ld26bkXG; dkim=fail header.i=@linux-foundation.org header.s=google header.b=SbJH5NPP; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l6si3096928pfj.26.2018.04.03.17.04.08; Tue, 03 Apr 2018 17:04:22 -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=@gmail.com header.s=20161025 header.b=Ld26bkXG; dkim=fail header.i=@linux-foundation.org header.s=google header.b=SbJH5NPP; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755992AbeDDACv (ORCPT + 99 others); Tue, 3 Apr 2018 20:02:51 -0400 Received: from mail-io0-f179.google.com ([209.85.223.179]:43176 "EHLO mail-io0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754252AbeDDACs (ORCPT ); Tue, 3 Apr 2018 20:02:48 -0400 Received: by mail-io0-f179.google.com with SMTP id q84so24122605iod.10; Tue, 03 Apr 2018 17:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aMsj5EKWr5B6VzMhide4jMF7IypW+V1l1NnzfSO93XU=; b=Ld26bkXGwgZtLYelxFma5UvpvNpGML+qkgtIvN8NPrOehk0b4mu0jKbPRPTJk8U3eO tBCx0DU7NoTJNYL2Zuq9qKik4ZAkkhW4DXhWbal8qL+4eogppj2N+G4smKLLGfIT2Z+m 4s6OZ7gyUPzQdPIeZVVRV8II1VyK39wxkoeUYFebPiw+Oz3iuzJhn64K2zUSVvPmg8c6 v4TqMPmIs5N1qD1JjHTlYN+BV0CuFXz9hf3KV4uzIfru7er7CW7zYH6lRoRUP7JHsmpn GN8R1ol0FyPCHdbCmM0sHzmxLyQYZSsDphF/hQQo+eJiiC/g26D1448Uvgyg6A4ztWvK idUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aMsj5EKWr5B6VzMhide4jMF7IypW+V1l1NnzfSO93XU=; b=SbJH5NPPuR5m3ZtkhI0q5AbvUREnuTBWrdMfjmCwFU4TVn0zWCz105tg0RvGSi0WaE kJGdLn+xj8PzGMUbIYL4GRABFHbbFU8Ja0fWCbsa5+Sc8DWafGHtEvTKjmMQvY0muCTZ AQy12nJfl0vtOgzG14yeJFDg38xBFiU9rSNRA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aMsj5EKWr5B6VzMhide4jMF7IypW+V1l1NnzfSO93XU=; b=NIRzkx3fb/OFKKWvpHo73av9yID07X0ElBPJwWboSNuRoDfXZ+rc9mv7an3pg3TyTE IAHezx+zagYat/P9DYlzxt9RZy/66e+OM7foO1nr7cDBO0SsVpkRpxeX8vJZOOfxMHaR YU+YyDzoLD5D5o2Smacqom8z0m2VGXwoCxHF3qJAgdCMMgld+OheHY3y3omZC9VpbD3f zbmeylbq2UbCcOgU4tzPBAvHH+vMqpa+PpD6B0ZB5ZP83kwJHxAX9tzqCPWIS4lq1Nr0 28jyw1nBGLtY68x29uYVxFSYdRMjKM192KHnz8X6xKin2iw+21O0xoTYYX4I8d+cOaSC ZxsA== X-Gm-Message-State: AElRT7H7Khr7TeB3vRq36i1pgqSLvDrZgMEddSnQd7qXMSYM2l3d6dqW pDAVj2bttwOPoYY/bN/gmyMGv3L5by0hlhOc7JM= X-Received: by 10.107.182.214 with SMTP id g205mr15384300iof.203.1522800166978; Tue, 03 Apr 2018 17:02:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.95.15 with HTTP; Tue, 3 Apr 2018 17:02:46 -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: Linus Torvalds Date: Tue, 3 Apr 2018 17:02:46 -0700 X-Google-Sender-Auth: eDqYmoq99RbdZDXbar6h841eSxc Message-ID: Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Matthew Garrett Cc: Andrew Lutomirski , David Howells , Ard Biesheuvel , James Morris , Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , Justin Forbes , 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 4:47 PM, Matthew Garrett wrote: >> Another way of looking at this: if lockdown is a good idea to enable >> when you booted using secure boot, then why isn't it a good idea when >> you *didn't* boot using secure boot? > > Because it's then trivial to circumvent and the restrictions aren't worth > the benefit. Bullshit. If there those restrictions cause problems, they need to be fixed regardless. In fact, from a debuggability standpoint, you want to find the problems early, on those kernel development machines that had secure boot explicitly turned off because it's such a pain. And if they can't be fixed, then the user is going to disable lockdown regardless of how he booted the machine. In no situation is "depending on how you booted" a good choice. Either you can enable it or you can't. If you can, good. And if you can't, it has nothing to do with secure boot. Linus