Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1553092
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] perf: protect group_leader from races that cause ctx |
| Date | 2017-01-06 21:40 +0100 |
| Message-ID | <sWJsS-75B-27@gated-at.bofh.it> (permalink) |
| References | <sWpua-1ii-13@gated-at.bofh.it> <sWzaa-8fH-19@gated-at.bofh.it> <sWCB3-2sU-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Jan 6, 2017 at 5:14 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Fri, Jan 06, 2017 at 10:32:51AM +0100, Peter Zijlstra wrote: >> On Thu, Jan 05, 2017 at 03:14:29PM -0800, Kees Cook wrote: >> > From: John Dias <joaodias@google.com> >> > >> > When moving a group_leader perf event from a software-context to >> > a hardware-context, there's a race in checking and updating that >> > context. The existing locking solution doesn't work; note that it tries >> > to grab a lock inside the group_leader's context object, which you can >> > only get at by going through a pointer that should be protected from these >> > races. If two threads trigger this operation simultaneously, the refcount >> > of 'perf_event_context' will fall to zero and the object may be freed. >> > >> > To avoid that problem, and to produce a simple solution, we can just >> > use a lock per group_leader to protect all checks on the group_leader's >> > context. The new lock is grabbed and released when no context locks are >> > held. >> >> This Changelog really stinks. I'll go try and reverse engineer the thing >> :-( Sorry! I tried to merge John's changelog with details from the original internal bug report. I guess I failed. :P > So the fundamental problem is a race of two sys_perf_event_open() calls > trying to move the same (software) group, nothing else, the rest of the > text above is misdirection and side effects. > > And instead of applying the existing locking rules for this exact > scenario, it invents extra locking :-( > > Ok so I came up with the following, compile tested only, since no > reproducer and being fairly grumpy for having to spend entirely too much > time reconstructing the problem. John, are you able to test this solution? IIUC, you've got a reproducer handy? Thanks for digging into this Peter! > [...] > Reported-by: Kees Cook <keescook@chromium.org> I was just relaying a fix. I noted the original reporter in the first patch, how they asked to be credited: Reported-by: Di Shen (@returnsme) of KeenLab (@keen_lab), Tencent -Kees -- Kees Cook Nexus Security
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] perf: protect group_leader from races that cause ctx Kees Cook <keescook@chromium.org> - 2017-01-06 00:20 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx Peter Zijlstra <peterz@infradead.org> - 2017-01-06 10:40 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx Peter Zijlstra <peterz@infradead.org> - 2017-01-06 14:20 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx Kees Cook <keescook@chromium.org> - 2017-01-06 21:40 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx John Dias <joaodias@google.com> - 2017-01-07 17:30 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx Kees Cook <keescook@chromium.org> - 2017-01-10 00:20 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx Peter Zijlstra <peterz@infradead.org> - 2017-01-10 09:50 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx Ingo Molnar <mingo@kernel.org> - 2017-01-10 11:20 +0100
Re: [PATCH] perf: protect group_leader from races that cause ctx Kees Cook <keescook@chromium.org> - 2017-01-11 01:00 +0100
[tip:perf/urgent] perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race tip-bot for Peter Zijlstra <tipbot@zytor.com> - 2017-01-14 13:30 +0100
csiph-web