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] [day] [month] [year] [list]
Message-ID: <20200217165714.1080cfd2@gandalf.local.home>
Date:   Mon, 17 Feb 2020 16:57:14 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Jann Horn <jannh@...gle.com>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jason Baron <jbaron@...mai.com>, Jiri Kosina <jkosina@...e.cz>,
        David Laight <David.Laight@...lab.com>,
        Borislav Petkov <bp@...en8.de>,
        Julia Cartwright <julia@...com>, Jessica Yu <jeyu@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Nadav Amit <namit@...are.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Edward Cree <ecree@...arflare.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: [PATCH v3 0/6] Static calls

On Mon, 17 Feb 2020 22:10:27 +0100
Jann Horn <jannh@...gle.com> wrote:

> On Thu, Jan 10, 2019 at 9:52 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > On Thu, Jan 10, 2019 at 09:30:23PM +0100, Peter Zijlstra wrote:  
> > > On Wed, Jan 09, 2019 at 04:59:35PM -0600, Josh Poimboeuf wrote:  
> > > > With this version, I stopped trying to use text_poke_bp(), and instead
> > > > went with a different approach: if the call site destination doesn't
> > > > cross a cacheline boundary, just do an atomic write.  Otherwise, keep
> > > > using the trampoline indefinitely.  
> > >  
> > > > - Get rid of the use of text_poke_bp(), in favor of atomic writes.
> > > >   Out-of-line calls will be promoted to inline only if the call sites
> > > >   don't cross cache line boundaries. [Linus/Andy]  
> > >
> > > Can we perserve why text_poke_bp() didn't work? I seem to have forgotten
> > > again. The problem was poking the return address onto the stack from the
> > > int3 handler, or something along those lines?  
> >
> > Right, emulating a call instruction from the #BP handler is ugly,
> > because you have to somehow grow the stack to make room for the return
> > address.  Personally I liked the idea of shifting the iret frame by 16
> > bytes in the #DB entry code, but others hated it.
> >
> > So many bad-but-not-completely-unacceptable options to choose from.  
> 
> Silly suggestion from someone who has skimmed the thread:
> 
> Wouldn't a retpoline-style trampoline solve this without needing
> memory allocations? Let the interrupt handler stash the destination in
> a percpu variable and clear IF in regs->flags. Something like:

Linus actually suggested something similar, but for ftrace, but after
implementing it, it was hard to get right, and caused havoc with
utilities like lockdep, and also shadow stacks.

See this thread:

  https://lore.kernel.org/linux-kselftest/CAHk-=wh5OpheSU8Em_Q3Hg8qw_JtoijxOdPtHru6d+5K8TWM=A@mail.gmail.com/


 -- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ