| Message ID | 151024883613.28329.14808632296386937974.stgit@warthog.procyon.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 9 Nov 2017, David Howells wrote: > 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. > > 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. I fail to see how this fits into the secure boot security model, could you please explain? Secure boot is about having a constant proof / verification that the code you're running in ring0 can be trusted (IOW is the one that has been signed and verified by the whole boot chain). Checking execution patterns doesn't seem to fit at all. Thanks,
Jiri Kosina <jikos@kernel.org> wrote: > > 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. > > I fail to see how this fits into the secure boot security model, could you > please explain? The idea is to prevent cryptographic data for filesystems and other things from being read out of the kernel memory as well as to prevent unauthorised modification of kernel memory. > Secure boot is about having a constant proof / verification that the code > you're running in ring0 can be trusted (IOW is the one that has been > signed and verified by the whole boot chain). > > Checking execution patterns doesn't seem to fit at all. I'll defer this question to Alexei since he suggested I needed to deal with this too. David -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 10 Nov 2017, David Howells wrote: > > I fail to see how this fits into the secure boot security model, could you > > please explain? > > The idea is to prevent cryptographic data for filesystems and other things > from being read out of the kernel memory as well as to prevent unauthorised > modification of kernel memory. Then it would make sense to actually lock down dumping of registers / function arguments (kprobes can currently do that, ftrace eventually could as well I guess), but disabling the whole ftrace altogether seems like a totally unnecessary overkill. > > Secure boot is about having a constant proof / verification that the code > > you're running in ring0 can be trusted (IOW is the one that has been > > signed and verified by the whole boot chain). > > > > Checking execution patterns doesn't seem to fit at all. > > I'll defer this question to Alexei since he suggested I needed to deal > with this too. Thanks.
Jiri Kosina <jikos@kernel.org> wrote: > > The idea is to prevent cryptographic data for filesystems and other things > > from being read out of the kernel memory as well as to prevent unauthorised > > modification of kernel memory. > > Then it would make sense to actually lock down dumping of registers / > function arguments (kprobes can currently do that, ftrace eventually could > as well I guess), but disabling the whole ftrace altogether seems like a > totally unnecessary overkill. That would be fine by me. I have a patch that locks down kprobes in this series. Steven says that ftrace might acquire the ability to dump registers in the future. David -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 10 Nov 2017, David Howells wrote: > That would be fine by me. I have a patch that locks down kprobes in this > series. Which AFAICS renders locking down ftrace as-is unnecessary ... > Steven says that ftrace might acquire the ability to dump registers in > the future. ... and even if that happens, locking down only that particular feature of ftrace would be needed. Thanks,
Okay, I've dropped the ftrace lockdown patch for the moment from my git branch. David -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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. 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@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> --- kernel/trace/ftrace.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html