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:   Tue, 18 Oct 2022 10:21:00 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Mark Rutland <mark.rutland@....com>,
        Kees Cook <keescook@...omium.org>,
        Sami Tolvanen <samitolvanen@...gle.com>
Subject: Re: [PATCH] ftrace,kcfi: Separate ftrace_stub() and
 ftrace_stub_graph()

On Tue, 18 Oct 2022 14:35:15 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> Different function signatures means they needs to be different
> functions; otherwise CFI gets upset.

This is due to this commit:

commit b83b43ffc6e4b514ca034a0fbdee01322e2f7022
Author: Steven Rostedt (VMware) <rostedt@...dmis.org>
Date:   Tue Oct 15 09:00:55 2019 -0400

    fgraph: Fix function type mismatches of ftrace_graph_return using ftrace_stub
    
    The C compiler is allowing more checks to make sure that function pointers
    are assigned to the correct prototype function. Unfortunately, the function
    graph tracer uses a special name with its assigned ftrace_graph_return
    function pointer that maps to a stub function used by the function tracer
    (ftrace_stub). The ftrace_graph_return variable is compared to the
    ftrace_stub in some archs to know if the function graph tracer is enabled or
    not. This means we can not just simply create a new function stub that
    compares it without modifying all the archs.
    
    Instead, have the linker script create a function_graph_stub that maps to
    ftrace_stub, and this way we can define the prototype for it to match the
    prototype of ftrace_graph_return, and make the compiler checks all happy!


Perhaps its time to just modify all the archs and get rid of that hack.

Ideally, all the archs should be switched over to the FTRACE_WITH_ARGS and
we can get rid of all of this. But that may be asking for too many ponies.

At the very least, perhaps we should just make all the archs define a
ftrace_stub_graph that need it and add a new CONFIG_HAVE.. that allows us to
remove some of this from the core code.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ