lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210226183309.0edcc54d@gandalf.local.home>
Date:   Fri, 26 Feb 2021 18:33:09 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jacob Wen <jian.w.wen@...cle.com>
Subject: Re: [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers
 from trace events

On Fri, 26 Feb 2021 14:21:00 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > The second patch handles strings "%s" [..]  
> 
> Doing this at runtime really feels like the wrong thing to do.
> 
> It won't even protect us from what happened - people like me and
> Andrew won't even run those tracepoints in the first place, so we
> won't notice.
> 
> It really would be much better in every respect to have this done by
> checkpatch, I think.

They are not mutually exclusive. We could have both. One thing that's nice
about this patch is that it removes the possibility of a real bug. That is,
it will catch the dereferencing of a string that is not valid, WARN about
it, but it wont try to dereference it (outside of the
strcpy_from_kernel_nofault()). And hopefully the warning and lack of data
they want, will have this get caught during development.

Also, there's cases that %s is allowed to reference data that I don't know
if checkpatch would be able to differentiate.

As for the other pointer dereferences (the first patch), those get caught
at boot up if they are compiled in. That is, you don't need to have the
events enabled. The boot up code will do the verification on all events
that are loaded (allyesconfig will catch all of them, which I need to try
to boot with this code).

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ