linux-kernel - Re: [PATCH] samples/ftrace: mark my

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: <20201116161819.040408dd@gandalf.local.home>
Date:   Mon, 16 Nov 2020 16:18:19 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Sami Tolvanen <samitolvanen@...gle.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Colin Ian King <colin.king@...onical.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] samples/ftrace: mark my_tramp[12]? global

On Mon, 16 Nov 2020 13:10:57 -0800
Sami Tolvanen <samitolvanen@...gle.com> wrote:

> Clang doesn't warn about this as we're building a module, it just
> generates a reference to a non-existing global "my_tramp" symbol,
> because the one defined in inline assembly has a local binding:
> 
> $ readelf --symbols --wide ftrace-direct.lto.o | grep my_tramp
>     16: 0000000000000000    13 FUNC    LOCAL  DEFAULT    1 my_tramp
>     33: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND my_tramp
>     42: 0000000000000000     8 FUNC    GLOBAL HIDDEN     8 my_tramp.cfi_jt
> 
> This would prevent the module from loading, which modpost catches:
> 
> ERROR: modpost: "my_tramp" [samples/ftrace/ftrace-direct.ko] undefined!
> 
> > From user space, I'm just using the following file:  
> 
> As this error happens only with Control-Flow Integrity, we need to
> take the address of the "test" function to force the compiler to
> generate a jump table entry for it. Here's a slightly tweaked
> stand-alone reproducer:
> 
> https://godbolt.org/z/GnzjE4

Thanks, we don't need to look more into this. It was mostly my curiosity to
find a way to have the compiler know about a function declared statically
in inline assembly. Maybe I'm asking for too much ;-)

I'll take your original patch. Does it need to go to stable, or is this not
that big of an issue to allow it to be added in the next merge window?

-- Steve