linux-kernel - Re: [RFC] perf: Delayed userspace unwind (Was: [PATCH v3 00/10] x86: ORC unwinder)

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] [day] [month] [year] [list]

Message-ID: <20170729092812.GC6524@worktop.programming.kicks-ass.net>
Date:   Sat, 29 Jul 2017 11:28:12 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andres Freund <andres@...razel.de>, X86 ML <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        live-patching@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>, Jiri Slaby <jslaby@...e.cz>,
        "H. Peter Anvin" <hpa@...or.com>, Mike Galbraith <efault@....de>,
        Jiri Olsa <jolsa@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...radead.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: Re: [RFC] perf: Delayed userspace unwind (Was: [PATCH v3 00/10] x86:
 ORC unwinder)

On Fri, Jul 28, 2017 at 08:35:16PM -0700, Andy Lutomirski wrote:

> I haven't checked task_work specifically, but a bunch of the exit work
> is permitted to sleep, which is potentially useful.

Yes.

> If this becomes successful enough that we could eventually deprecate
> the old code, I wonder if copy_from_user_nmi() could go away? :)

So we still use that for things like the PEBS IP fixup for older CPUs.
That needs to read the userspace code.

Also, since all this is optional on userspace asking for the new format,
we will probably (forever) need to support userspace not asking for it.

> > +        if (!work->func) {
> > +            work->func = perf_callchain_work;
> > +            /*
> > +             * We cannot do set_notify_resume() from NMI context,
> > +             * also, knowing we are already in an interrupted
> > +             * context and will pass return to userspace, we can
> > +             * simply set TIF_NOTIFY_RESUME.
> > +             */
> > +            task_work_add(current, work, false);
> > +            set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
> 
> There's a more or leas unavoidable window in which this won't be
> noticed, which could plausibly confuse userspace.  It might be
> possible to figure out a way for an NMI to tell if it lands in this
> window, but it would be a bit tricky.

Correct, I have been thinking on how to do that but haven't found
anything particularly nice yet.

> Also, is the task_work code prepared to handle task_work_add during
> exit?

That is one I hadn't thought of, but basically task_work_add() will fail
if the task is too far gone. At that point we should fallback to the
'old' behaviour and simply include the information in the kernel SAMPLE
record.