linux-kernel - Re: [RFC v2 0/6] x86: dynamic indirect branch promotion

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: <306d38fb-7ce6-a3ec-a351-6c117559ebaa@intel.com>
Date:   Tue, 8 Jan 2019 12:01:11 +0200
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Andi Kleen <ak@...ux.intel.com>, Nadav Amit <namit@...are.com>,
        Ingo Molnar <mingo@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Edward Cree <ecree@...arflare.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Nadav Amit <nadav.amit@...il.com>, X86 ML <x86@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        songliubraving@...com
Subject: Re: [RFC v2 0/6] x86: dynamic indirect branch promotion

On 8/01/19 11:25 AM, Peter Zijlstra wrote:
> On Tue, Jan 08, 2019 at 09:47:18AM +0200, Adrian Hunter wrote:
>> On 7/01/19 6:32 PM, Peter Zijlstra wrote:
>>> On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote:
>>>> Nadav Amit <namit@...are.com> writes:
>>>>>
>>>>> - Do we use periodic learning or not? Josh suggested to reconfigure the
>>>>>   branches whenever a new target is found. However, I do not know at
>>>>>   this time how to do learning efficiently, without making learning much
>>>>>   more expensive.
>>>>
>>>> FWIW frequent patching will likely completely break perf Processor Trace
>>>> decoding, which needs a somewhat stable kernel text image to decode the
>>>> traces generated by the CPU. Right now it relies on kcore dumped after
>>>> the trace usually being stable because jumplabel changes happen only
>>>> infrequently. But if you start patching frequently this assumption will
>>>> break.
>>>>
>>>> You would either need a way to turn this off, or provide
>>>> updates for every change to the trace, so that the decoder can
>>>> keep track.
>>>
>>> I'm thining it would be entirely possible to create and feed text_poke
>>> events into the regular (!aux) buffer which can be timestamp correlated
>>> to the PT data.
>>
>> To rebuild kernel text from such events would require a starting point.
>> What is the starting point?  The problem with kcore is that people can
>> deconfig it without realising it is needed to enable the tracing of kernel
>> self-modifying code.  It would be nice if it was all tied together, so that
>> if someone selects the ability to trace kernel self-modifying code, then all
>> the bits needed are also selected.  Perhaps we should expose another ELF
>> image that contains only kernel executable code, and take the opportunity to
>> put the symbols in it also.
> 
> Meh; you always need a magic combo of CONFIG symbols to make stuff work.
> We don't even have a CONFIG symbol for PT, so if you really care you
> should probably start there.
> 
> If you want symbols; what stops us from exposing kallsyms in kcore as
> is?
> 
>> Also what about BPF jitted code?  Will it always fit in an event?  I was
>> thinking of trying to add a way to prevent temporarily the unload of modules
>> or jitted code, which would be a good-enough solution for now.
> 
> We're working on BPF and kallsym events, those should, esp. when
> combined with kcore, allow you to extract the actual instructions.

The problem is that the jitted code gets freed from memory, which is why I
suggested the ability to pin it for a while.