From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753437AbdKISDd (ORCPT ); Thu, 9 Nov 2017 13:03:33 -0500 Received: from mail.kernel.org ([198.145.29.99]:50764 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753175AbdKISDc (ORCPT ); Thu, 9 Nov 2017 13:03:32 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 336A1218EB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Thu, 9 Nov 2017 13:03:29 -0500 From: Steven Rostedt To: David Howells Cc: mingo@redhat.com, alexei.starovoitov@gmail.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] Lock down ftrace Message-ID: <20171109130329.3de3f41a@gandalf.local.home> In-Reply-To: <11100.1510245732@warthog.procyon.org.uk> References: <11100.1510245732@warthog.procyon.org.uk> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 09 Nov 2017 16:42:12 +0000 David Howells wrote: > Hi, > > I (may) need to lock down ftrace under secure boot conditions as part of the > patch series that can be found here: > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down > > Can you tell me that if the attached patch is sufficient to the cause? > > Thanks, > David > --- > commit 3fb4590c0ad0a751b2090c489df79193510e6aaa > Author: David Howells > Date: Wed Nov 8 15:41:02 2017 +0000 > > Lock down ftrace > > Disallow the use of ftrace when the kernel is locked down. This patch > turns off ftrace_enabled late in the kernel boot so that the selftest can > still be potentially be run. > > The sysctl that controls ftrace_enables is also disallowed when the kernel > is locked down. If the lockdown is lifted, then the sysctl can be used to > reenable ftrace - if ftrace was compiled with CONFIG_DYNAMIC_FTRACE, that > is; if it wasn't then it won't be possible to reenable it. Actually, I see it being enabled with DYNAMIC_FTRACE not set. Calling into sysctl and enabling ftrace_enable, will allow the ftrace_trace_function to be set to something other than ftrace_stub again, allowing for static function tracing to run too. > > This prevents crypto data theft by analysis of execution patterns, and, if > in future ftrace also logs the register contents at the time, will prevent > data theft by that mechanism also. > > Reported-by: Alexei Starovoitov > Signed-off-by: David Howells > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index 6abfafd7f173..9c7135963d80 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -6508,6 +6508,9 @@ ftrace_enable_sysctl(struct ctl_table *table, int write, > { > int ret = -ENODEV; > > + if (kernel_is_locked_down("Use of ftrace")) > + return -EPERM; > + > mutex_lock(&ftrace_lock); > > if (unlikely(ftrace_disabled)) > @@ -6896,3 +6899,22 @@ void ftrace_graph_exit_task(struct task_struct *t) > kfree(ret_stack); > } > #endif > + > +#ifdef CONFIG_LOCK_DOWN_KERNEL > +static int __init ftrace_lock_down(void) > +{ > + mutex_lock(&ftrace_lock); > + > + if (!ftrace_disabled && ftrace_enabled && > + kernel_is_locked_down("Use of ftrace")) { > + ftrace_enabled = false; > + last_ftrace_enabled = false; > + ftrace_trace_function = ftrace_stub; > + ftrace_shutdown_sysctl(); > + } > + > + mutex_unlock(&ftrace_lock); > + return 0; > +} > +late_initcall(ftrace_lock_down); > +#endif Looks fine to me. We discussed this offline, and this appears to implement what we finally decided would be sufficient. -- Steve