linux-kernel - Re: Process-wide watchpoints

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: <20201112103125.GV2628@hirez.programming.kicks-ass.net>
Date:   Thu, 12 Nov 2020 11:31:25 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Will Deacon <will@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Matt Morehouse <mascasa@...gle.com>
Subject: Re: Process-wide watchpoints

On Thu, Nov 12, 2020 at 08:46:23AM +0100, Dmitry Vyukov wrote:

> for sampling race detection),
> number of threads in the process can be up to, say, ~~10K and the
> watchpoint is intended to be set for a very brief period of time
> (~~few ms).

Performance is a consideration here, doing lots of IPIs in such a short
window, on potentially large machines is a DoS risk.

> This can be done today with both perf_event_open and ptrace.
> However, the problem is that both APIs work on a single thread level
> (? perf_event_open can be inherited by children, but not for existing
> siblings). So doing this would require iterating over, say, 10K

One way would be to create the event before the process starts spawning
threads and keeping it disabled. Then every thread will inherit it, but
it'll be inactive.

> I see at least one potential problem: what do we do if some sibling
> thread already has all 4 watchpoints consumed?

That would be immediately avoided by this, since it will have the
watchpoint reserved per inheriting the event.

Then you can do ioctl(PERF_EVENT_IOC_{MODIFY_ATTRIBUTES,ENABLE,DISABLE})
to update the watch location and enable/disable it. This _will_ indeed
result in a shitload of IPIs if the threads are active, but it should
work.