On Wed, 4 Apr 2018 12:04:42 -0700
Linus Torvalds wrote:
>
> So at the *very* least this would need to be percpu logic, but even
> that is honestly broken since an NMI might come in and want to printk
> too.
>
> Why don't you just use %px? That avoids all of these hacks.
Just need to remember
On Wed, Apr 4, 2018 at 10:13 AM, Steven Rostedt wrote:
>
> Something like this will even prevent modules from disabling the printk
> hash...
That still seems broken.
The *natural* thing to do would seem to be to tie the hash to the
printk state, kind of like the percpu buffers that safe_printk()
On Wed, 4 Apr 2018 11:34:55 +0900
Sergey Senozhatsky wrote:
> On (04/03/18 18:03), Steven Rostedt wrote:
> >
> > > he'd want you to change all the trace_printk()s to %px with
> > > justifications, though.
> >
> > What trace_printk()s do you want to change? They are throw away
> > functions.
On (04/03/18 18:03), Steven Rostedt wrote:
>
> > he'd want you to change all the trace_printk()s to %px with
> > justifications, though.
>
> What trace_printk()s do you want to change? They are throw away
> functions. trace_printk() is not something that stays in the kernel.
> It's added during d
On Tue, 3 Apr 2018 14:43:43 -0700
Kees Cook wrote:
> > A static_key is added called "trace_debug" and if it is set, then %p will
> > not be hashed.
>
> Hrm, well, using a static key does make it weirder for an attacker to enable.
> :)
Not just weirder, much more difficult. static_keys are re
On Tue, Apr 3, 2018 at 2:31 PM, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> 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
> p
6 matches
Mail list logo
