linux-kernel - Re: [RFC PATCH 00/17] perf: Detached events

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]

Date:   Wed, 13 Sep 2017 14:54:02 +0300
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        acme@...hat.com, kirill.shutemov@...ux.intel.com, rric@...nel.org
Subject: Re: [RFC PATCH 00/17] perf: Detached events

Borislav Petkov <bp@...en8.de> writes:

> On Tue, Sep 05, 2017 at 04:30:09PM +0300, Alexander Shishkin wrote:
>> Detached events: a new flag to the perf syscall makes a 'detached' event,
>> which exists after its file descriptor is released. Not all detached events
>> are per-thread AUX events: this tries to take into account the need for
>> system-wide persistent events too.
>
> Nice, thanks!

Forgot to mention that I did hack the tracepoint support into the
tooling as well to make sure it's a workable idea.

>> (2) Need to be able to kill those events, so they need to be accessible
>> after they are created.
>> Event files: detached events exist as files in tracefs (at the moment), can
>> be opened/mmaped/read/removed.
>
> I guess I'll see when I continue reading but I remember us doing ioctls
> on the event fd.

Iirc that was for re-attaching to the event to make it 'normal' before
closing.

>> (6) Ring buffer memory accounting needs to take this new arrangement into
>> account: one user can use up at most NR_CPUS * buffer_size memory at any
>> given point in time.
>> Only account the first such event and undo the accounting when the last
>> event is gone.
>
> ... and I guess we probably shouldn't allow the user to create too many
> events and shoot herself in the OOM-foot.

Well, they are still limited by the RLIMIT_MEMLOCK and perf_event_mlock
sysctl for the total amount of memory that can be pinned for the ring
buffers at any given time, so that should be fine.

>> (7) We'll also need to supply all the things that the [PT] decoder normally
>> finds out via sysfs attributes, like clock ratios, capabilities, etc so that
>> it also finds its way into the core dump file.
>> "PMU info" structure is appended to the user page.
>> 
>> I've also hack the perf tool to support all this, all these things can be
>> found at [1]. I'm not posting the tooling patches though, them being
>> thoroughly ugly and proof-of-concept. In short, perf record will create
>> detached events with '--detached' and afterwards will open detached events
>> via their path in tracefs.
>
> Sounds nice. I'd need to test all that just so I can be able to create
> detached RAS events (which are tracepoints) with it.

Thanks, let me know how it goes.

Regards,
--
Alex