linux-kernel - Re: [PATCH] x86: Fix export for mcount and __fentry_

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: <20161024191743.rsd74w2vev5efcar@pd.tnic>
Date:   Mon, 24 Oct 2016 21:17:43 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Al Viro <viro@...IV.linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Gabriel C <nix.or.die@...il.com>
Subject: Re: [PATCH] x86: Fix export for mcount and __fentry__

On Mon, Oct 24, 2016 at 03:01:48PM -0400, Steven Rostedt wrote:
> Commit 784d5699eddc5 ("x86: move exports to actual definitions") removed the
> EXPORT_SYMBOL(__fentry__) and EXPORT_SYMBOL(mcount) from x8664_ksyms_64.c,
> and added EXPORT_SYMBOL(function_hook) in mcount_64.S instead. The problem
> is that function_hook isn't a function at all, but a macro that is defined
> as either mcount or __fentry__ depending on the support from gcc.
> 
> Originally, I thought this was a macro issue, like what __stringify()
> is used for. But the problem is a bit deeper. The Makefile.build has
> some magic that does post processing of files to create the CRC
> bindings. It does some searches for EXPORT_SYMBOL() and because it
> finds a macro name and not the actual functions, this causes
> function_hook not to be converted into mcount or __fentry__ and they
> are missed.
> 
> Instead of adding more magic to Makefile.build, just add
> EXPORT_SYMBOL() for mcount and __fentry__ where the ifdef is used.
> Since this is assembly and not C, it doesn't require being set after
> the function is defined.
> 
> Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

Tested-by: Borislav Petkov <bp@...e.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.