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