linux-kernel - Re: Summary of discussion following LPC2023 sframe talk

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:   Fri, 1 Dec 2023 11:08:41 -0800
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        rostedt <rostedt@...dmis.org>,
        "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
        Indu Bhagat <indu.bhagat@...cle.com>,
        "carlos@...hat.com" <carlos@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "Jose E. Marchesi" <jose.marchesi@...cle.com>,
        Mark Rutland <mark.rutland@....com>,
        Brian Robbins <brianrob@...rosoft.com>,
        Diamon discuss <diamon-discuss@...ts.linuxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Summary of discussion following LPC2023 sframe talk

On Wed, Nov 15, 2023 at 04:49:12PM +0100, Peter Zijlstra wrote:
> > - JITs:
> > 
> >   - There are two approaches to skip over JITted code stacks:
> > 
> >     - If the jitted code has frame pointers, then use this.
> > 
> >     - If we figure out that some JITs do not have frame pointers, then
> >       we would need to design a new kernel ABI that would allow JITs
> >       to express sframe-alike information. This will need to be designed
> >       with the input of JIT communities because some of them are likely
> >       not psABI compliant (e.g. lua has a separate stack).
> 
> Why a new interface? They can use the same prctl() as above. Here text,
> there sframe.

Our thinking was that a syscall defeats the point of "just in time".

> >   - When we have a good understanding of the JIT requirements in terms
> >     of frame description content, the other element that would need to
> >     be solved is how to allow JITs to emit frame data in a data structure
> >     that can expand. We may need something like a reserved memory area, with
> >     a counter of the number of elements which is used to synchronize communication
> >     between the JITs (producer) and kernel (consumer).
> 
> Again, huh?! Expand? Typical JIT has the normal epoch like approach to
> text generation, have N>1 text windows, JIT into one until full, once
> full, copy all still active crap into second window, induce grace period
> and wipe first window, rince-repeat.
> 
> Just have a sframe thing per window and expand the definition of 'full'
> to be either text of sframe window is full and everything should just
> work, no?

Yes, assuming the JIT doesn't mind doing a syscall.
 
> >   - We may have to create frame description areas which content are specific to given
> >     JITs. For instance, the frame descriptions for a lua JIT on x86-64 may not follow
> >     the x86-64 regular psABI.
> > 
> >   - As an initial stage, we can focus on handling the sframe section for executable
> >     and shared objects, and use frame pointers to skip over JITted code if available.
> >     The goal here is to show the usefulness of this kind of information so we get
> >     the interest/collaboration needed to get the relevant input from JIT communities
> >     as we design the proper ABI for handling JIT frames.
> 
> As per: https://realpython.com/python312-perf-profiler/
> 
> There is some 'demand' for all this, might be useful to contact some JIT
> authors and have them detail their needs or something.

If there's no sframe then we can just fall back to frame pointers like
ORC does.  And that article recommends enabling frame pointers for
python.

Between that and prctl(), it may be enough.

-- 
Josh