Received: by 10.213.65.68 with SMTP id h4csp13157imn; Tue, 3 Apr 2018 14:28:17 -0700 (PDT) X-Google-Smtp-Source: AIpwx48aKBlJsBNnkN1UWRVdD5wYavrTK6AYpL9UomJ+htEvVhEzX0D1SIHl09Z7JyJQleaVmdh9 X-Received: by 10.101.76.77 with SMTP id l13mr10164388pgr.192.1522790897108; Tue, 03 Apr 2018 14:28:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522790897; cv=none; d=google.com; s=arc-20160816; b=PA+IcEadHngtBTrFtVGbZxTcm2ceUxGuBK6gVIIH+vP5LgNDHK6m5T1lupUXWaYRP0 n6TtVXCRlxc88Dc71/XTs+MsK9G9BH+OZ5eyDU4CHQXRXp2/suTkIPFZ3eZo9sFM02IE eHU7au7bkVN3TkX1ockKQ5Gq7hylOlHahFCwCZwbnzB9qvajMR0+oVXqS32JmKysJVvc 6JPYYvAk+Y1BRMT2NCnXnpWEqbvlcSJ+eyVXs35zfJZJIe5HSB2iQnaH8VvpaYpmMlo1 nOVxihYVpwtlpYP/UCR/NfUeSoFYNldfsX9NLm40Y6LHKlowqV41x9qBDH9xApjedsGP yKUg== 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=cjFcmcG4KCVy091zZzvgqWC9W7dlZjFiAUXCA3XgUfw=; b=NpEe/KmAMk29wOwbZ01hpLodCHEi0DZs+liH0/lD5loTdT23pwS/+bescHAG0EvOdr S0+mSRNzszMo7Eo3pOc9uxYuucN6mukUjgr+7v2GF/a2aUNT81au1xxe282HBiDjLd9i qv9aIvQ72SbKviRt82Xqcd0LOj4uyBs36GgL5C9lAU3KeMBHvxK4o7VXZiBdFvdYSUvi w+ENaocqxa8sq+UUgktQR7VVcBZETJXbBCzif2TzEJW7gBv3Lymt9RtOiK3tX9gm5QV9 rdtk8w0ZSuqxxQBGht9WyFwHI+ASyx8HHtJdsR+MsQlhOG0KXeeo7TJw97EvFbLNbu2e oP1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=QWRy9TNL; dkim=fail header.i=@linux-foundation.org header.s=google header.b=WtTl43Vq; 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 l3-v6si3892461pld.638.2018.04.03.14.28.02; Tue, 03 Apr 2018 14:28:17 -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=QWRy9TNL; dkim=fail header.i=@linux-foundation.org header.s=google header.b=WtTl43Vq; 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 S1753499AbeDCV0x (ORCPT + 99 others); Tue, 3 Apr 2018 17:26:53 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:53986 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752495AbeDCV0u (ORCPT ); Tue, 3 Apr 2018 17:26:50 -0400 Received: by mail-it0-f65.google.com with SMTP id m134-v6so25277682itb.3; Tue, 03 Apr 2018 14:26:49 -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=cjFcmcG4KCVy091zZzvgqWC9W7dlZjFiAUXCA3XgUfw=; b=QWRy9TNLUGSjeb3I+UGpyvMIKElTsMO28YaPv5HTCHOLoVaay3q3VqY5h2O0B/dU1L PJPtMYHHWDDQLJDImA28vYrDCBHFZjbYbRWZjRlLL7bvJmSPIHut9BEBhhwYsK0/OUs+ XsRvvhK2oq3+bLMm+uAcKOcNQLc4TOt7jsGd7qjzQTrztdXyJwhstjTEPUGLp0tYv0sG FI7jIzrXo6zGQk+Ms2F423Ka78AWt/4N9dIhfp79yPreaofer6a2pkLbTbnlOiRoipgo YoYrx8R3fx60M0FPmMVmeqfTVDbZvJV0lrTpLKBSCLk3pVCDdV4hoox0O1YFG6YQ/VVD Dvgw== 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=cjFcmcG4KCVy091zZzvgqWC9W7dlZjFiAUXCA3XgUfw=; b=WtTl43VqsxiIjcMEfgNt0iEZCHSiRfpQCs2PNhZqj1dhVTaN32C+GVovr+1Dm35Las ASW75DdCKkbR2XPjmsHYW8hF+KjLP0E/iSZ/vvhm1co7y8UxAUDLwqzZJKMqbsbLqBNK DMEvFidXJr9a22HO26dQDEO2oIaAIydSKCZUU= 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=cjFcmcG4KCVy091zZzvgqWC9W7dlZjFiAUXCA3XgUfw=; b=JzWjef6UqZfS/9MP9ZTDt0R/xjNG6ggmKaWet+EEDk+mvtMz/z4i67saBQzQRt6jEw 9hY1PaEQ8K7JzQhJtqN/VvUOsBMV+O9BU2q0lNriVoGgGG5C0Fk8dW7kjsMqWAm9ZNpx CS6hnRI9sTJc5t1oON4oQ1WGQLv05P7g9dQmx8HggwoPYRhhoBFlcVuAPbon97MW38UM F+nnHwCOhsm/ziC1SsJHRVRJQ+lht04seYpgciCooz8YMqKi1s5pYCxF+q5r493bXRMb sp7lRIqofSyW9IqCAPhbn55NJEiKxtCpZwgPWMB1h6AXhPB4oAR5bYTVOD8gZ33rmO4I sNoA== X-Gm-Message-State: ALQs6tBfFlgdJVP3WG0o037bpj862hyxgQAKTR32Vsru7xFF5ansTwHu pfEe4rhZzdkpw7pxDXZniWtTg7ENG7Ehi9w3vmw= X-Received: by 2002:a24:5b02:: with SMTP id g2-v6mr7042970itb.100.1522790809045; Tue, 03 Apr 2018 14:26:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.95.15 with HTTP; Tue, 3 Apr 2018 14:26:48 -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> From: Linus Torvalds Date: Tue, 3 Apr 2018 14:26:48 -0700 X-Google-Sender-Auth: adbfI3QnP-JQqEchQZuz8W_phGg 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 , jforbes@redhat.com, linux-man@vger.kernel.org, jlee@suse.com, 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 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. In fact, I tend to trust it more than some random vendor key. You should too. Your whole argument is FUNDAMENTALLY garbage. It's the Disney kind of garbage. It was garbage back then, and it's garbage now. It is also garbage for a simple technical reason: secure boot can be hard to turn off. Sometimes "turn off" means "you just have to add your own keys". 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. Seriously. You sound like you're parroting some party line, not like you are answering the actual question. So again: why do you conflate the two issues? 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? Linus