Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 09:27:10 -0700 Kees Cook wrote: > On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote: > > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > >> If you are concerned about attack surface, I could make it a bit

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 09:27:10 -0700 Kees Cook wrote: > On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote: > > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > >> If you are concerned about attack surface, I could make it a bit more > >> difficult to tweak by malicious

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote: > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: >> If you are concerned about attack surface, I could make it a bit more >> difficult to tweak by malicious software. What about the patch below? >> It

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote: > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: >> If you are concerned about attack surface, I could make it a bit more >> difficult to tweak by malicious software. What about the patch below? >> It would be much more

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 09:49:27 +0200 Peter Zijlstra wrote: > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > > If you are concerned about attack surface, I could make it a bit more > > difficult to tweak by malicious software. What about the patch below? > >

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 09:49:27 +0200 Peter Zijlstra wrote: > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > > If you are concerned about attack surface, I could make it a bit more > > difficult to tweak by malicious software. What about the patch below? > > It would be much more

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > If you are concerned about attack surface, I could make it a bit more > difficult to tweak by malicious software. What about the patch below? > It would be much more difficult to modify this knob from an attack > vector. Not if you

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > If you are concerned about attack surface, I could make it a bit more > difficult to tweak by malicious software. What about the patch below? > It would be much more difficult to modify this knob from an attack > vector. Not if you

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 07:43:49 +1000 "Tobin C. Harding" wrote: > > static noinline_for_stack > > char *restricted_pointer(char *buf, char *end, const void *ptr, > > @@ -1962,6 +1963,10 @@ char *pointer(const char *fmt, char *buf, char *end, > > void *ptr, > > return

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 07:43:49 +1000 "Tobin C. Harding" wrote: > > static noinline_for_stack > > char *restricted_pointer(char *buf, char *end, const void *ptr, > > @@ -1962,6 +1963,10 @@ char *pointer(const char *fmt, char *buf, char *end, > > void *ptr, > > return

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > On Tue, 3 Apr 2018 13:07:58 -0700 > Kees Cook wrote: > > > On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote: > > > Both trace_debug is set and kptr_restrict is set to zero in the

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > On Tue, 3 Apr 2018 13:07:58 -0700 > Kees Cook wrote: > > > On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote: > > > Both trace_debug is set and kptr_restrict is set to zero in the same > > > code that produces the above

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, 3 Apr 2018 13:07:58 -0700 Kees Cook wrote: > On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote: > > Both trace_debug is set and kptr_restrict is set to zero in the same > > code that produces the above banner. This will allow

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, 3 Apr 2018 13:07:58 -0700 Kees Cook wrote: > On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote: > > Both trace_debug is set and kptr_restrict is set to zero in the same > > code that produces the above banner. This will allow trace_printk() to > > not be affected by security code,

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote: > Both trace_debug is set and kptr_restrict is set to zero in the same > code that produces the above banner. This will allow trace_printk() to > not be affected by security code, as trace_printk() should never be run >

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote: > Both trace_debug is set and kptr_restrict is set to zero in the same > code that produces the above banner. This will allow trace_printk() to > not be affected by security code, as trace_printk() should never be run > on a machine that

[RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

While debugging an issue I needed to see if the pointers were being processed correctly with trace_printk() and after using "%p" and triggering my bug and trace output, I was disappointed that all my pointers were random garbage and didn't produce anything useful for me. I had to rewrite all the

[RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

While debugging an issue I needed to see if the pointers were being processed correctly with trace_printk() and after using "%p" and triggering my bug and trace output, I was disappointed that all my pointers were random garbage and didn't produce anything useful for me. I had to rewrite all the