[RFC][PATCH] Lock down ftrace
Steven Rostedt
rostedt at goodmis.org
Thu Nov 9 18:03:29 UTC 2017
On Thu, 09 Nov 2017 16:42:12 +0000
David Howells <dhowells at redhat.com> 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 <dhowells at redhat.com>
> 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 <alexei.starovoitov at gmail.com>
> Signed-off-by: David Howells <dhowells at redhat.com>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive
mailing list