Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3095100yba; Sun, 28 Apr 2019 17:08:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqw+0QgIL0EptLXK+FOhDNujEU8mGBsjhLGl+vMOQmf/EjGVkqFpF0fyZ7fy5MEV/e5xPx+P X-Received: by 2002:a17:902:6b82:: with SMTP id p2mr1553782plk.99.1556496483629; Sun, 28 Apr 2019 17:08:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556496483; cv=none; d=google.com; s=arc-20160816; b=Qo8NqL9aZYTRmM2KslXQ09LqyTU8rAfqacRKK3Mmpg1XFerhBTLxhPRRxdYCip63+L +yqb/NIpTjsynOFbwNtrw3RniIdk6Ka5llz25IuoQkCtzD3ROfBFxdMiDnfkbhROX6Cl f/Jcn4oHaXfckEGp/d3utEa/1+mMUdg4xST/eN/J9G+bc0WiaJqxJJqGAOtwqq/GRRpj Ul7kF8QdVqv6q62Au0k/9/D+zYz9djR2Hz8So3OXacrQbIS6c4SfVJNIN2J9Lf6Fx0+a E8WKU/7930oYtKHABrSQpYGbY3VOhEL79gfg+5JDe+581kZ9/3IwnVREB8dyuMgUHnEF T96g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=n2mvnFGe7DhWnAVJ4HPTWEsItuKdoQBnBqAP6kIcYug=; b=hna5TkgyxXrCJ6OXkXslrkkJnPWhig89qJEWCgvarRW2CnHybLybYsCsBKc7TpuUPT EDNa+yCe9hrTTCxwmMg6Np3HdDTspg5BKkiz8aT+uRUMSx7wLVi9wYKTijQ+KauvKeJM b9VFLicMbfJEuVP7SO5IC9CY3nBLchiHxP0R5vINo6xRLNlkrkvnRCuTU2DvWrbvjKFn EW5pvz6aaE7OHckep85yffsQXEgGcOebbuRSXh9y4KJxLqHwFp9TjCtlpYyl6RfFu6BG Gdoby4xO3V96GQdP0WsHzy0VC0ma6H6hsHerSYIyoKiJMVMdoW1a1nSW4043eC/HyKRb MR+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=Or6uEcGq; 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 h14si30558234pgl.426.2019.04.28.17.07.48; Sun, 28 Apr 2019 17:08:03 -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=@axtens.net header.s=google header.b=Or6uEcGq; 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 S1726597AbfD2AHA (ORCPT + 99 others); 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-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