linux-kernel - Re: [PATCH v2 0/4] Reference count checker and related fixes

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: <Yffx+2uarK5Y15TF@kernel.org>
Date:   Mon, 31 Jan 2022 11:28:11 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Ian Rogers <irogers@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Darren Hart <dvhart@...radead.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        André Almeida <andrealmeid@...labora.com>,
        James Clark <james.clark@....com>,
        John Garry <john.garry@...wei.com>,
        Riccardo Mancini <rickyman7@...il.com>,
        Yury Norov <yury.norov@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jin Yao <yao.jin@...ux.intel.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Leo Yan <leo.yan@...aro.org>, Andi Kleen <ak@...ux.intel.com>,
        Thomas Richter <tmricht@...ux.ibm.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Shunsuke Nakamura <nakamura.shun@...itsu.com>,
        Song Liu <song@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Miaoqian Lin <linmq006@...il.com>,
        Stephen Brennan <stephen.s.brennan@...cle.com>,
        Kajol Jain <kjain@...ux.ibm.com>,
        Alexey Bayduraev <alexey.v.bayduraev@...ux.intel.com>,
        German Gomez <german.gomez@....com>,
        linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        Eric Dumazet <edumazet@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        masami.hiramatsu.pt@...achi.com, eranian@...gle.com
Subject: Re: [PATCH v2 0/4] Reference count checker and related fixes

Em Sun, Jan 30, 2022 at 05:04:18PM +0900, Masami Hiramatsu escreveu:
> On Fri, 28 Jan 2022 16:59:13 -0300 Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > I went back to that discussion and saw this part where I brainstormed
> > about doing all this in unmodified binaries:

> > https://lore.kernel.org/all/20151209134138.GB15864@kernel.org/

> > Even Alexei chimed in and replied to that thinking it was doable:

> > https://lore.kernel.org/all/20151210033139.GA10056@ast-mbp.thefacebook.com/#t

> > And nowadays we have much better BPF infrastructure, much faster probes,
> > etc.

> Yeah I think now we (will) have faster user-event[1] too. :)

> [1] https://lore.kernel.org/all/20220118204326.2169-1-beaub@linux.microsoft.com/T/#u

> So instead of allocating an indirect object on get(), we also can define
> an event and send it to the kernel, and run a BPF to analyze it.
> Note that this will *NOT* be able to detect the "use-after-put" unless
> we automatically trace the all object field access ;-)

Humm, reading https://blog.janestreet.com/magic-trace/:

"I spent a bunch of time looking for a better solution and eventually I
found a really satisfying one in the perf_event_open docs. It turns out
that perf_event_open can use hardware breakpoints and notify you when a
memory address is executed or accessed."

I.e. after the last put we could automagically add a:

  mem:<addr>[/len][:access]                          [Hardware breakpoint]

But there are only HBP_NUM hardware breakpoints (4 on x86)... So some
sort of scheduling would be needed, or after last put add it then, leave
it there for some time, then stop tracking it, reusing it for some other
object, etc. We would be able to catch some of the problems sometimes.

For things that do use-after-free straight away we would get some of
these and fix it, making this tunable (the time to track a object after
it is last put) should be possible.

> Hm, apart from this topic, isn't it good to introduce user-space trace
> event( macro)s in perf tools? :-)

Yeah, this seems to be an interesting case for that.

- Arnaldo