Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1503956ybp; Fri, 11 Oct 2019 15:33:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqxv6UK9KrWLbYwIHDKbD6HKYLH0t9vbvegRRLZVxXjlLJ/OBlDPk6u8EhNW7aRQCI3WrqSo X-Received: by 2002:a17:906:6a15:: with SMTP id o21mr16008078ejr.79.1570833227423; Fri, 11 Oct 2019 15:33:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570833227; cv=none; d=google.com; s=arc-20160816; b=OkDrWSNShQyaMOCuoAa66a8qsws29SKL9kvNDqzN/+LFZGXrM5cF1df+Z+frrO5Pyx ufO4CH1yYxTEkPqSKolHgwqqqE89fWW9oB/D1qtDitHnV8/X3+A6ONF3UOz3queyyVGz n3hLhZPE4AbyBaGgrtMv+sbYW7t1XAO29UaKrSqCGeKiV+itHSi+KVftuN8S+u3GDa/8 E/LrOxgEwK2Y+LDwXkzS0StmkrrCag1nG6qvUeC3TJJA5u6FGeCByIRXMA8Y3UqoBufj vJUdxXgZ8cKjUd0PbvMEu1sck2+ryq51m2MZdhR13Z0UPjlXgKgshpS1i5aZ2+2Btf4o 2fBQ== 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:in-reply-to:date :references:subject:cc:to:from; bh=C7qUTIYZPz3IpGN+QNFLhzkzCzNFm2p6kcJQJ1IQi24=; b=pUzV7EMSSyPgbEFLPzwMK4AsrxHyWHMCTGgJAj53qwpllYwWnjvXuOHc/yKRY+8PXk Y5wnLssXXwvXfYvtSlvahsh873N+uef5hVJLe1ziDCQSkFKTM/+qGqOkTUIr9eYO5sLy 1dIa6IvmbM8uKhuDCIlfuHAEsd/JmS8EowB9pL1wc5Sxx6RpvVGlcLFKD+Iiyd0q0+YY zSjllNL07egg4iQ47tBaTe+mTGDZyQafaRqOpNuC5pqcOUTmHNfoj/elpoALdwHEncEx m8T2LNpAQRBq3rZUy/2CHTcdButMitebepRj+aTigaJB0fuAK/MRZ5C72Bg8Qs5garMt 6jqg== 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 i18si6153748ejb.145.2019.10.11.15.33.16; Fri, 11 Oct 2019 15:33:47 -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 S1729304AbfJKVq1 (ORCPT + 99 others); Fri, 11 Oct 2019 17:46:27 -0400 Received: from albireo.enyo.de ([37.24.231.21]:44962 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728719AbfJKVq1 (ORCPT ); Fri, 11 Oct 2019 17:46:27 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iJ2js-0005ne-Ji; Fri, 11 Oct 2019 21:46:20 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1iJ2js-0002M3-Fz; Fri, 11 Oct 2019 23:46:20 +0200 From: Florian Weimer To: Steven Rostedt Cc: Linus Torvalds , LKML , Matthew Garrett , James Morris James Morris , LSM List , Linux API , Ben Hutchings , Al Viro Subject: Re: [PATCH] tracefs: Do not allocate and free proxy_ops for lockdown References: <20191011135458.7399da44@gandalf.local.home> <20191011143610.21bcd9c0@gandalf.local.home> Date: Fri, 11 Oct 2019 23:46:20 +0200 In-Reply-To: <20191011143610.21bcd9c0@gandalf.local.home> (Steven Rostedt's message of "Fri, 11 Oct 2019 14:36:10 -0400") Message-ID: <87tv8f9cr7.fsf@mid.deneb.enyo.de> 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 * Steven Rostedt: > Once locked down is set, can it ever be undone without rebooting? I think this is the original intent with such patches, yes. But then reality interferes and people add some escape hatch, so that it's possible again to load arbitrary kernel modules. And for servers, you can't have a meaningful physical presence check, so you end up with a lot of complexity for something that offers absolutely zero gains in security. The other practical issue is that general-purpose Linux distributions cannot prevent kernel downgrades, so even if there's a cryptographically signed chain from the firmware to the kernel, you can boot last year's kernel, use a root-to-ring-0 exploit to disable its particular implementation of lockdown, and then kexec the real kernel with lockdown disabled. I'm sure that kernel lockdown has applications somewhere, but for general-purpose distributions (who usually want to support third-party kernel modules), it's an endless source of problems that wouldn't exist without it.