linux-kernel - Re: [PATCH 4/6] objtool: Replace STACK_FRAME_NON

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:   Wed, 27 Feb 2019 16:30:08 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Julien Thierry <julien.thierry@....com>,
        Will Deacon <will.deacon@....com>,
        Ingo Molnar <mingo@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        James Morse <james.morse@....com>, valentin.schneider@....com,
        Brian Gerst <brgerst@...il.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] objtool: Replace STACK_FRAME_NON_STANDARD annotation

On Wed, Feb 27, 2019 at 4:21 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Mon, Feb 25, 2019 at 10:11:24AM -0600, Josh Poimboeuf wrote:
> > On Mon, Feb 25, 2019 at 01:43:34PM +0100, Peter Zijlstra wrote:
>
> > > -#define STACK_FRAME_NON_STANDARD(func) \
> > > -   static void __used __section(.discard.func_stack_frame_non_standard) \
> > > -           *__func_stack_frame_non_standard_##func = func
> > > +#define STACK_FRAME_NON_STANDARD(func)                                     \
> > > +   asm (".pushsection .discard.nonstd_frame_strtab, \"S\", @3\n\t" \
> > > +        "999: .ascii \"" #func "\"\n\t"                            \
> > > +        "     .byte 0\n\t"                                         \
> > > +        ".popsection\n\t"                                          \
> > > +        ".pushsection .discard.nonstd_frame\n\t"                   \
> > > +        ".long 999b - .\n\t"                                       \
> > > +        ".popsection\n\t")
> > > +
> >
> > I don't think this will work in the case where GCC does an IPA
> > optimization and renames the function (e.g., renames func to
> > func.isra.1234), right?  That might be a deal breaker...
>
> Or; as has been found by 0day; the whole function gets inlined and
> the symbol no longer exists at all.
>
> That's curable with a noinline, but all things considered, I think we
> should go back to the old horrible scheme. Andy?

Ugh, I guess.  I'm wondering just how atrocious the generated code is.

Just as a thought experiment, here are some other options:

1. Make a tiny GCC plugin that parses a special attribute on function
declarations and emits a record that describes that attribute into the
object file for each referenced symbol that comes from that
declaration.  (I know nothing about GCC internals, so I don't know how
hard this would be.)

2. Fiddle with the function names.  Turn a function called foo() into
__uaccess_safe_foo() and also emit a weak alias from that to foo.
This is probably every bit as bad as taking the address.

3. Take advantage of the fact that only static functions are (for now)
subject to this IPA stuff.  So take the address of a static function
or just declare that calling a static function is uaccess safe.

--Andy