linux-kernel - Re: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to aid Intel PT tracing

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: <76a91fb3-0f4e-c55f-3176-3ad9a996e936@intel.com>
Date:   Fri, 8 Feb 2019 10:53:41 +0200
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...nel.org>, Andi Kleen <ak@...ux.intel.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>, Song Liu <songliubraving@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to
 aid Intel PT tracing

On 7/02/19 10:02 PM, Peter Zijlstra wrote:
> On Thu, Feb 07, 2019 at 01:19:01PM +0200, Adrian Hunter wrote:
>> Subject to memory pressure and other limits, retain executable code, such
>> as JIT-compiled bpf, in memory instead of freeing it immediately it is no
>> longer needed for execution.
>>
>> While perf is primarily aimed at statistical analysis, tools like Intel
>> PT can aim to provide a trace of exactly what happened. As such, corner
>> cases that can be overlooked statistically need to be addressed. For
>> example, there is a gap where JIT-compiled bpf can be freed from memory
>> before a tracer has a chance to read it out through the bpf syscall.
>> While that can be ignored statistically, it contributes to a death by
>> 1000 cuts for tracers attempting to assemble exactly what happened. This is
>> a bit gratuitous given that retaining the executable code is relatively
>> simple, and the amount of memory involved relatively small. The retained
>> executable code is then available in memory images such as /proc/kcore.
>>
>> This facility could perhaps be extended also to init sections.
>>
>> Note that this patch is compile tested only and, at present, is missing
>> the ability to retain symbols.
> 
> You don't need the symbols; you already have them through
> PERF_RECORD_KSYMBOL.

And you intend to use that for module loading/unloading also?

> 
> Also; afaict this patch guarantees exactly nothing. It registers a
> shrinker which will (given enough memory pressure) happily free your
> text before we get around to copying it out.

No, there is a minimum size (default 0) which is not subject to the shrinker.

> 
> Did you read this proposal?

Please cc me on anything affecting Intel PT decoding.

> 
>   https://lkml.kernel.org/r/20190109101808.GG1900@hirez.programming.kicks-ass.net
> 
> (also: s/KCORE_QC/KCORE_QS/ for quiescent state)
> 
> That would create an RCU like interface to /proc/kcore and give you the
> guarantees you need, while also allowing the memory to get freed once
> you've obtained a copy.

So, open /proc/kcore and it pins all executable code in memory?

Do you intend to extend that to module / module init unloads?