I should have marked this for stable. The commit it fixes (see Fixes tag) is in 5.4, and it appears this has yet to make it to 5.4 yet.
-- Steve
On Wed, Dec 04, 2019 at 09:05:02PM -0500, Steven Rostedt wrote:
From: "Steven Rostedt (VMware)" rostedt@goodmis.org
If lockdown is disabling tracing on boot up, it prevents the tracing files from even bering created. But when that happens, there's several places that will give a warning that the files were not created as that is usually a sign of a bug.
Add in strategic locations where a check is made to see if tracing is disabled by lockdown, and if it is, do not go further, and fail silently (but print that tracing is disabled by lockdown, without doing a WARN_ON()).
Cc: Matthew Garrett mjg59@google.com Fixes: 17911ff38aa5 ("tracing: Add locked_down checks to the open calls of files created for tracefs") Signed-off-by: Steven Rostedt (VMware) rostedt@goodmis.org
kernel/trace/ring_buffer.c | 6 ++++++ kernel/trace/trace.c | 17 +++++++++++++++++ 2 files changed, 23 insertions(+)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 66358d66c933..4bf050fcfe3b 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -11,6 +11,7 @@ #include <linux/trace_seq.h> #include <linux/spinlock.h> #include <linux/irq_work.h> +#include <linux/security.h> #include <linux/uaccess.h> #include <linux/hardirq.h> #include <linux/kthread.h> /* for self test */ @@ -5068,6 +5069,11 @@ static __init int test_ringbuffer(void) int cpu; int ret = 0;
- if (security_locked_down(LOCKDOWN_TRACEFS)) {
pr_warning("Lockdown is enabled, skipping ring buffer tests\n");
return 0;
- }
- pr_info("Running ring buffer tests...\n");
buffer = ring_buffer_alloc(RB_TEST_BUFFER_SIZE, RB_FL_OVERWRITE); diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 02a23a6e5e00..23459d53d576 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -1888,6 +1888,12 @@ int __init register_tracer(struct tracer *type) return -1; }
- if (security_locked_down(LOCKDOWN_TRACEFS)) {
pr_warning("Can not register tracer %s due to lockdown\n",
type->name);
return -EPERM;
- }
- mutex_lock(&trace_types_lock);
tracing_selftest_running = true; @@ -8789,6 +8795,11 @@ struct dentry *tracing_init_dentry(void) { struct trace_array *tr = &global_trace;
- if (security_locked_down(LOCKDOWN_TRACEFS)) {
pr_warning("Tracing disabled due to lockdown\n");
return ERR_PTR(-EPERM);
- }
- /* The top level trace array uses NULL as parent */ if (tr->dir) return NULL;
@@ -9231,6 +9242,12 @@ __init static int tracer_alloc_buffers(void) int ring_buf_size; int ret = -ENOMEM;
- if (security_locked_down(LOCKDOWN_TRACEFS)) {
pr_warning("Tracing disabled due to lockdown\n");
return -EPERM;
- }
- /*
- Make sure we don't accidently add more trace options
- than we have bits for.
-- 2.24.0
On Fri, Jan 10, 2020 at 11:31:05AM -0500, Steven Rostedt wrote:
I should have marked this for stable. The commit it fixes (see Fixes tag) is in 5.4, and it appears this has yet to make it to 5.4 yet.
-- Steve
On Wed, Dec 04, 2019 at 09:05:02PM -0500, Steven Rostedt wrote:
From: "Steven Rostedt (VMware)" rostedt@goodmis.org
If lockdown is disabling tracing on boot up, it prevents the tracing files from even bering created. But when that happens, there's several places that will give a warning that the files were not created as that is usually a sign of a bug.
Add in strategic locations where a check is made to see if tracing is disabled by lockdown, and if it is, do not go further, and fail silently (but print that tracing is disabled by lockdown, without doing a WARN_ON()).
Cc: Matthew Garrett mjg59@google.com Fixes: 17911ff38aa5 ("tracing: Add locked_down checks to the open calls of files created for tracefs") Signed-off-by: Steven Rostedt (VMware) rostedt@goodmis.org
Relying only on the Fixes: tag to get things picked up by stable is a sure way to get it on the "slow, and maybe eventually, hopefully, it might make it into stable" path :)
I have over 1000 patches right now in that "bucket" that need to be checked to see if they are relevant for stable backporting, just since 5.4 was released. I have automated a lot of it, but still, they require manual review.
I'll go queue this up now, as it's simplest just to ask us to take it after it hits Linus's tree :)
thanks,
greg k-h
On Fri, 10 Jan 2020 17:54:04 +0100 Greg KH greg@kroah.com wrote:
Relying only on the Fixes: tag to get things picked up by stable is a sure way to get it on the "slow, and maybe eventually, hopefully, it might make it into stable" path :)
I've been numbed by all the AUTOSEL patches, where I tend to think Fixes is becoming enough. That said, this particular patch, I thought was going in the same release as what it fixed, which is why I never added stable to it. :-/
I have over 1000 patches right now in that "bucket" that need to be checked to see if they are relevant for stable backporting, just since 5.4 was released. I have automated a lot of it, but still, they require manual review.
I'll go queue this up now, as it's simplest just to ask us to take it after it hits Linus's tree :)
Again, I thought the AUTOSEL would pick it up, as it seems to pick other patches I don't intend on going to stable quickly ;-)
-- Steve
linux-stable-mirror@lists.linaro.org