linux-kernel - Re: [PATCH v4 1/2] function_graph: Support recording and printing the return value of function

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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 19 Mar 2023 12:14:22 +0800
From:   Donglin Peng <pengdonglin@...gfor.com.cn>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        mhiramat@...nel.org, mark.rutland@....com, will@...nel.org,
        catalin.marinas@....com, palmer@...belt.com,
        paul.walmsley@...ive.com, tglx@...utronix.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, mingo@...hat.com,
        xiehuan09@...il.com, dinghui@...gfor.com.cn,
        huangcun@...gfor.com.cn, dolinux.peng@...il.com,
        linux-trace-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/2] function_graph: Support recording and printing the
 return value of function

On 2023/3/19 0:40, Steven Rostedt wrote:
> On Fri, 17 Mar 2023 10:49:49 +0800
> Donglin Peng <pengdonglin@...gfor.com.cn> wrote:
> 
>>> So, really it depends what size of return value we want to report.
>>> Also, please bear in mind that where a function returns a 32-bit
>>> value, that will be in r0, and r1 will be whatever happened to be
>>> in it at function exit - there's no defined value for r1.
>>>    
>>
>> Thank you. I will document this as a limitation of fgraph return value.
>> It can just cover most cases at present and I think the r0 is enough.
> 
> One thing we could possibly do here is to use BTF or objtool to denote
> the return value of each function and use 2 bits of the ftrace
> rec->flags to state that it is:
> 
> 0 - void
> 1 - 1 word size return
> 2 - 2 word size return

Yeah, the BTF contains details of the function return type. However the
direct search cost is a bit high, we may parse it to fill the 
dyn_ftrace.flags.

> 
> I believe we can get access to the function's rec via the return call
> (or add that access) and pass both words to the return function, and
> then the return callback can use this lookup to determine what values
> are useful or not.

Yeah, we can obtain the function address via ret_stack in the function
ftrace_pop_return_trace, then pass the address to lookup_rec to
find the dyn_ftrace.

> 
> In any case, I would suggest passing both regs to the callback, and for
> now just ignore the second reg until we can come up with a way to
> differentiate each function.
> 

Yeah, I will modify it to pass two regs in v5.

> -- Steve