From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A74C0C43219 for ; Mon, 29 Apr 2019 00:07:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B4962067D for ; Mon, 29 Apr 2019 00:07:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="Or6uEcGq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726700AbfD2AHA (ORCPT ); Sun, 28 Apr 2019 20:07:00 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:40107 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726296AbfD2AG7 (ORCPT ); Sun, 28 Apr 2019 20:06:59 -0400 Received: by mail-pf1-f196.google.com with SMTP id u17so470739pfn.7 for ; Sun, 28 Apr 2019 17:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=n2mvnFGe7DhWnAVJ4HPTWEsItuKdoQBnBqAP6kIcYug=; b=Or6uEcGq20/dbV741dpgRcmnluoZolSsauu907Q2n5IqtHesTqLypagpN4KylfV4J4 gV/Ri1WN8QiMSpSFwMNVrtg+g50Mh9dq9f59O5tPGvKm4CoKzYz808goOti/dswLGmR1 AYMHlHdbG1/yE0hzyy72pnjLNc6uo7AC6CMfw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=n2mvnFGe7DhWnAVJ4HPTWEsItuKdoQBnBqAP6kIcYug=; b=mcusVgBNSVshBhIu1dTFBxLMa3yQNbXHpb4pXL8haUY1FDPJJWVAKJXLIJQKbwscFQ uY776IVKJGtXzVjwXsQ/3bht4sUoEP+6knP5vE5jOWPgFPkssx0b04Xytp5QhJJEtEbN 0Orxx146qFoxqCdTHaSbpCEqqIWAQjRDnP/6jkmJOHJewyxD1d+dcPoY75XU+c18Wtf8 MumXJvLOi/g/Cht72a12gOkUiUTQ6msDJuSmEFcxn6Fu65NRzVjdjGoCgFH3leGIotxR M630h/ROR9MGv6bUVIIdZb/zK2LOazgMQfKeGtiCJJYV+58mkhxJex/Cl7kixeyQxOai BgKQ== X-Gm-Message-State: APjAAAW17qHHhJS7zT32WISga//LX2mgJDWapkGEEkf06skz50ai/DPY pc3eGoyChtntR/Yud4hQdd0KXg== X-Google-Smtp-Source: APXvYqwb6MwKjVD4beBIgVSrqvnOCys+S049kGs7qQXovjqAUY28iQ+jdtiBGffI7iAuh/EIjCR1vg== X-Received: by 2002:a63:4714:: with SMTP id u20mr47465141pga.316.1556496419070; Sun, 28 Apr 2019 17:06:59 -0700 (PDT) Received: from localhost (ppp121-45-207-92.bras1.cbr1.internode.on.net. [121.45.207.92]) by smtp.gmail.com with ESMTPSA id w23sm44714029pgj.72.2019.04.28.17.06.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 28 Apr 2019 17:06:57 -0700 (PDT) From: Daniel Axtens To: Matthew Garrett , Andrew Donnellan Cc: James Morris , LSM List , Linux Kernel Mailing List , David Howells , Linux API , Andy Lutomirski , linuxppc-dev , Michael Ellerman , cmr Subject: Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image In-Reply-To: References: <20190404003249.14356-1-matthewgarrett@google.com> <20190404003249.14356-2-matthewgarrett@google.com> <059c523e-926c-24ee-0935-198031712145@au1.ibm.com> Date: Mon, 29 Apr 2019 10:06:51 +1000 Message-ID: <87wojdy8ro.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Matthew Garrett writes: > On Tue, Apr 16, 2019 at 1:40 AM Andrew Donnellan > wrote: >> I'm thinking about whether we should lock down the powerpc xmon debug >> monitor - intuitively, I think the answer is yes if for no other reason >> than Least Astonishment, when lockdown is enabled you probably don't >> expect xmon to keep letting you access kernel memory. > > The original patchset contained a sysrq hotkey to allow physically > present users to disable lockdown, so I'm not super concerned about > this case - I could definitely be convinced otherwise, though. So currently (and I'm pretty new to this as I've only recently rejoined IBM) we aren't considering access to the console to be sufficient to assert physical presence on bare-metal server-class Power machines. The short argument for this is that with IPMI and BMCs, a server's console isn't what it used to be. Our console is also a bit different to x86: we don't generally have bios configuration screens on the console. In your example, a sysrq key would allow you to disable lockdown after the system has booted. On Power though, we use Linux as a bootloader (Petitboot: https://github.com/open-power/petitboot) so being able to disable lockdown there allows an IPMI-connected user to prevent a signed kernel being loaded in the first place. I don't know if this is _actually_ worse, but it certainly feels worse. There are of course some arguments against our approach. I'm aware of some of them. I'm also very open to being told that not equating console access with physical access is fundamentally silly or broken and that we should rethink things. Regards, Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94B85C43219 for ; Mon, 29 Apr 2019 00:08:35 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B900E20656 for ; Mon, 29 Apr 2019 00:08:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="Or6uEcGq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B900E20656 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 44slPD0mlKzDqKP for ; Mon, 29 Apr 2019 10:08:32 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=axtens.net (client-ip=2607:f8b0:4864:20::541; helo=mail-pg1-x541.google.com; envelope-from=dja@axtens.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=axtens.net header.i=@axtens.net header.b="Or6uEcGq"; dkim-atps=neutral Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 44slMW0dVlzDqNF for ; Mon, 29 Apr 2019 10:07:02 +1000 (AEST) Received: by mail-pg1-x541.google.com with SMTP id i21so840244pgi.12 for ; Sun, 28 Apr 2019 17:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=n2mvnFGe7DhWnAVJ4HPTWEsItuKdoQBnBqAP6kIcYug=; b=Or6uEcGq20/dbV741dpgRcmnluoZolSsauu907Q2n5IqtHesTqLypagpN4KylfV4J4 gV/Ri1WN8QiMSpSFwMNVrtg+g50Mh9dq9f59O5tPGvKm4CoKzYz808goOti/dswLGmR1 AYMHlHdbG1/yE0hzyy72pnjLNc6uo7AC6CMfw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=n2mvnFGe7DhWnAVJ4HPTWEsItuKdoQBnBqAP6kIcYug=; b=Ozcb41vbtvqlTxcwldI8PgrpBN4PUFIy8oLINLzv1aOqwqH1TsiSYIQ0myHdy3pc5/ cXVA2hfwubhzBo/i2Px1MNm/KEswaB0AJPiogJpshe/KLIlRzpqbAvR6WdgTf5IUHCQb pBRbCDm4cWeS9kr4EMJo22j0drohZSxGtiQ4Z6P64xWcC4yFR7LQB4W0vvXB1TdM2h4a /KkU/thNB8lPIUZORp/OORkUsPWWD+D9mpVRBIGeXRE0UyUG5Kl0+/23Gh9M8q1KRdjF /gSzqQZB5DRBAxR0eEYf/Y2LjW1GKUNTuazRsOF/+c7/lyuA+YYv4ih0VZ/i49u0sm/7 Jimg== X-Gm-Message-State: APjAAAVpd4E7doGh74QMyHWoJtUzY9Z2dQGjpp8IEdeFskLO5xdJnXQ0 l9o/lqIUQILfSYt51MlCh9FvIg== X-Google-Smtp-Source: APXvYqwb6MwKjVD4beBIgVSrqvnOCys+S049kGs7qQXovjqAUY28iQ+jdtiBGffI7iAuh/EIjCR1vg== X-Received: by 2002:a63:4714:: with SMTP id u20mr47465141pga.316.1556496419070; Sun, 28 Apr 2019 17:06:59 -0700 (PDT) Received: from localhost (ppp121-45-207-92.bras1.cbr1.internode.on.net. [121.45.207.92]) by smtp.gmail.com with ESMTPSA id w23sm44714029pgj.72.2019.04.28.17.06.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 28 Apr 2019 17:06:57 -0700 (PDT) From: Daniel Axtens To: Matthew Garrett , Andrew Donnellan Subject: Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image In-Reply-To: References: <20190404003249.14356-1-matthewgarrett@google.com> <20190404003249.14356-2-matthewgarrett@google.com> <059c523e-926c-24ee-0935-198031712145@au1.ibm.com> Date: Mon, 29 Apr 2019 10:06:51 +1000 Message-ID: <87wojdy8ro.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux API , cmr , James Morris , Linux Kernel Mailing List , David Howells , LSM List , Andy Lutomirski , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Matthew Garrett writes: > On Tue, Apr 16, 2019 at 1:40 AM Andrew Donnellan > wrote: >> I'm thinking about whether we should lock down the powerpc xmon debug >> monitor - intuitively, I think the answer is yes if for no other reason >> than Least Astonishment, when lockdown is enabled you probably don't >> expect xmon to keep letting you access kernel memory. > > The original patchset contained a sysrq hotkey to allow physically > present users to disable lockdown, so I'm not super concerned about > this case - I could definitely be convinced otherwise, though. So currently (and I'm pretty new to this as I've only recently rejoined IBM) we aren't considering access to the console to be sufficient to assert physical presence on bare-metal server-class Power machines. The short argument for this is that with IPMI and BMCs, a server's console isn't what it used to be. Our console is also a bit different to x86: we don't generally have bios configuration screens on the console. In your example, a sysrq key would allow you to disable lockdown after the system has booted. On Power though, we use Linux as a bootloader (Petitboot: https://github.com/open-power/petitboot) so being able to disable lockdown there allows an IPMI-connected user to prevent a signed kernel being loaded in the first place. I don't know if this is _actually_ worse, but it certainly feels worse. There are of course some arguments against our approach. I'm aware of some of them. I'm also very open to being told that not equating console access with physical access is fundamentally silly or broken and that we should rethink things. Regards, Daniel