linux-kernel - Re: [PATCH v5 perf, bpf-next 3/7] perf, bpf: introduce PERF_RECORD_BPF

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: <10039e93-a0a5-a712-4051-20f5c5d79fab@fb.com>
Date:   Tue, 8 Jan 2019 20:56:54 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Song Liu <songliubraving@...com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "acme@...nel.org" <acme@...nel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v5 perf, bpf-next 3/7] perf, bpf: introduce
 PERF_RECORD_BPF_EVENT

On 1/8/19 10:41 AM, Peter Zijlstra wrote:
> On Thu, Dec 20, 2018 at 10:29:00AM -0800, Song Liu wrote:
>> @@ -986,9 +987,35 @@ enum perf_event_type {
>>   	 */
>>   	PERF_RECORD_KSYMBOL			= 17,
>>   
>> +	/*
>> +	 * Record bpf events:
>> +	 *  enum perf_bpf_event_type {
>> +	 *	PERF_BPF_EVENT_UNKNOWN		= 0,
>> +	 *	PERF_BPF_EVENT_PROG_LOAD	= 1,
>> +	 *	PERF_BPF_EVENT_PROG_UNLOAD	= 2,
>> +	 *  };
>> +	 *
>> +	 * struct {
>> +	 *	struct perf_event_header	header;
>> +	 *	u16				type;
>> +	 *	u16				flags;
>> +	 *	u32				id;
>> +	 *	u8				tag[BPF_TAG_SIZE];
>> +	 *	struct sample_id		sample_id;
>> +	 * };
>> +	 */
>> +	PERF_RECORD_BPF_EVENT			= 18,
>> +
> 
> Elsewhere today, I raised the point that by the time (however short
> interval) userspace gets around to reading this event, the actual
> program could be gone again.
> 
> In this case the program has been with us for a very short period
> indeed; but it could still have generated some samples or otherwise
> generated trace data.
> 
> It was suggested to allow pinning modules/programs to avoid this
> situation, but that of course has other undesirable effects, such as a
> trivial DoS.
> 
> A truly horrible hack would be to include an open filedesc in the event
> that needs closing to release the resource, but I'm sorry for even
> suggesting that **shudder**.
> 
> Do we have any sane ideas?

I think we should miss such ultra short lived progs.
If perf record is slower than some user doing for(;;) {load prog; 
unload;} than it's a good thing.
I frankly don't think it's practically possible to miss a prog.
perf ring buffer is way faster than prog load/unload.
Even when all scheduling artifacts of perf user space are factored in.
Doing barriers is DoS-able.
Sending FD via ring buffer is not possible.
If there was a non-shudder solution to this we could do it,
but all complications pointing out that this is not a problem
worth solving.
At least since right now none of us see a clean fix I propose
to move ahead with what we have and address it later if better ideas
come up. We've been missing short lived progs and prog notifications
all this time and users complain. That is the problem to address.