Received: by 10.213.65.68 with SMTP id h4csp31301imn; Tue, 3 Apr 2018 14:53:03 -0700 (PDT) X-Google-Smtp-Source: AIpwx49tSqyFVgxlANA7giSZR75esnPXvDaoPWE2dokAwPsg+YwNy4k3uLJt6RNVouIzlBWsf+7/ X-Received: by 2002:a17:902:b602:: with SMTP id b2-v6mr16026356pls.11.1522792383021; Tue, 03 Apr 2018 14:53:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522792382; cv=none; d=google.com; s=arc-20160816; b=IjwaNfTjIzs3Ivkg49tqess63SRy0d3qIi+O//BW+TGPamjp/Nn5G1BbQxgOSybFki kQcVCiCy6zIR+0NlRTLkyC1NjiiBEiT4wi+r5f1r6Vb3JLYzTJqepismHlTiCJ4ZWLI/ VgLnD1iuVVZeWnitNXDvHsYxW+zUcN8CQpIEcB8zBjPrKuAMQ8kxm//msie/2R8TexaD W8Yr1dtgCVUADNKON82cMZWw5ZNF6uABi/oeY3gMPi+Ppvlrb5MMzAMUQxBaJgeubJCH 5LCy5/6mNIhVhKKFUK09YbWK7xpug9jPi9iXUtL/rOLhuYr2U8Zr/C7a9shQk3RM2DTV qM0Q== 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:dmarc-filter :arc-authentication-results; bh=eJAGs+q24wDEtuTV8VlO+PD80MU5KG7d2nHwAtRgOzs=; b=vXTAtgv++nfUxQtS4bLSQdyhfIjRm+uk9vzz9jKwRipHQKTAYTePm/MT7sJeEgQboS ABfIkaBNXsmBtQBeQwXpoJiVUyvdPAUlSNXZKM85WUocq1qdK4a4Mxt/YVl3L0ZMjKTa fwVFotfAz6WvLpR00vRmrlGkQeOX91WZbH8YsQLbkU/FB3QryG+qYVRosJTz6Nxl8MNd /WFx5IwqipZj2dhrODVZDtYwEVvC6zgT3VLwZa85BXJhJ1aUnixFAIP+Wgpg0+Yfjmux dnz4T0yx0mQn6Syf4xp/ctYn9vu67uGoM4Wk5S41PESRvSisMc0B02BOLPS/TboweFln PdZA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c15si2568949pgu.312.2018.04.03.14.52.49; Tue, 03 Apr 2018 14:53:02 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753766AbeDCVvr (ORCPT + 99 others); Tue, 3 Apr 2018 17:51:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:47684 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753367AbeDCVvo (ORCPT ); Tue, 3 Apr 2018 17:51:44 -0400 Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3A03721837 for ; Tue, 3 Apr 2018 21:51:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A03721837 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org Received: by mail-io0-f180.google.com with SMTP id e79so23846917ioi.7 for ; Tue, 03 Apr 2018 14:51:44 -0700 (PDT) X-Gm-Message-State: ALQs6tCx4TtDN8qrfHC3zQ5vLXoyfn2Mpcd6eUXjOF+jl+siP9dZ8KHx q/agHOMxanoC77vaSW/CDJEcRWriJ/tFKrJDqJTveA== X-Received: by 10.107.146.67 with SMTP id u64mr12691319iod.144.1522792303508; Tue, 03 Apr 2018 14:51:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.137.70 with HTTP; Tue, 3 Apr 2018 14:51:23 -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: Andy Lutomirski Date: Tue, 3 Apr 2018 14:51:23 -0700 X-Gmail-Original-Message-ID: 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 , Linus Torvalds , 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 12:29 PM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski wrote: >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote: >> > A kernel that allows users arbitrary access to ring 0 is just an >> > overfeatured bootloader. Why would you want secure boot in that case? > >> To get a chain of trust. I can provision a system with some public >> keys, stored in UEFI authenticated variables, such that the system >> will only boot a signed image. That signed image, can, in turn, load >> a signed (or hashed or otherwise verfified) kernel and a verified >> initramfs. The initramfs can run a full system from a verified (using >> dm-verity or similar) filesystem, for example. Now it's very hard to >> persistently attack this system. Chromium OS does something very much >> like this, except that it doesn't use UEFI as far as I know. So does >> iOS, and so do some Android versions. None of this requires lockdown, >> or even a separation between usermode and kernelmode, to work >> correctly. One could even do this on an MMU-less system if one really >> cared to. More usefully, someone probably has done this using a >> unikernel. > > That's only viable if you're the only person with the ability to sign stuff > for your machine - the moment there are generic distributions that your > machine trusts, an attacker can use one as a bootloader to compromise your > trust chain. If you removed "as a bootloader", then I agree with that sentence. Can someone please explain why the UEFI crowd cares so much about "as a bootloader"? Once I'm able to install an OS (Linux kernel + bootloader, Windows embedded doodad, OpenBSD, whatever) on your machine, I can use your peripherals, read your data, write your data, see your keystrokes, use your network connection, re-flash your BIOS (at least as well as any OS can), run VMs, and generally own your system. Somehow you all seem fine with all of this, except that the fact that I can chainload something else gives UEFI people the willies. Can someone explain why?