linux-kernel - Re: [PATCH v2 2/2] kernel/trace: Remove function callback casts

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: <20200724134811.01704cbf@oasis.local.home>
Date:   Fri, 24 Jul 2020 13:48:11 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Oscar Carter <oscar.carter@....com>
Cc:     Ingo Molnar <mingo@...hat.com>, Kees Cook <keescook@...omium.org>,
        linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
        Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH v2 2/2] kernel/trace: Remove function callback casts

On Fri, 24 Jul 2020 13:40:20 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Fri, 24 Jul 2020 13:36:56 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > Which BTW, is supported by the following architectures:

> >   x86  

Ah, you can lose support on x86 if you don't enable DYNAMIC_FTRACE,
which is stupid to do. I only enabled disabling of DYNAMIC_FTRACE on
x86 to test it, as not all architectures have it, and I currently only
test on x86.

Without DYNAMIC_FTRACE enabled, you *always* call into the ftrace
infrastructure for *every* function. This adds something like 15 to 20%
overhead to the kernel. Did I say it was stupid to do so?

If you are going through all this work because some randconfig causes
this warning because it enables CONFIG_FUNCTION_TRACER but without
DYNAMIC_FTRACE enabled, then I strongly suggest you start spending your
time elsewhere, because it will be a big NAK on my part to add all this
intrusive code for a config used only for debugging the non
DYNAMIC_FTRACE case.

-- Steve